Accessing Kubernetes Using Expose API and User Interface Using Sidecar Pattern

Written by careerdrill | Published 2020/05/05
Tech Story Tags: kubernetes | microservices | sidecar | design-patterns | cloud-computing | open-source | k8s | orchestration

TLDR Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management. It manages by objects like pods, services, replica set, deployment, volume, namespace, and configurations. Microservices deployment design patterns can be used for deploying the containerized application. The sidecar design pattern allows adding another container in the parent pod. The service calls each other and avoids the network latency between the service calls. The Microservices design pattern prefers to use Service instance per Container. So, the application easily scales or maintains the availability without affecting the other services.via the TL;DR App

Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management.
Kubernetes support multiple container run times like Docker, containerd, CRI-O and more.

Kubernetes 

Kubernetes manages the container life cycle and makes sure the number of defined replications running on the cluster. It defines the set of building blocks using the configuration files. The user can define the number of CPU, RAM, persistent volumes, memory, domain naming system and more resources. The Kubernetes manages by objects like pods, services, replica set, deployment, volume, namespace, and configurations.
If the container crashes due to application failure, Kubernetes restart the Pods based on the defined policy. The pods are the high level of abstraction of containerized applications. The replica set manages the number of instances of given pods. The Kubernetes runes the defined number of pods. The user must define the application using deployment and should not define and run the pods directly. The volumes used to store persistent data. The containerized application does not persist in the data. The data loss once the container shutdown due to the application lifecycle or due to errors or application crashes.

Microservice deployment design pattern

The Microservices deployment design patterns can be used for deploying the containerized application. The Micro-services design supports the following deployment models
  • Multiple service instances per host
  • Service instance per host
  • Service instance per VM
  • Service instance per Container
  • Serverless deployment
  • Service deployment platform
The multiple service instance per host mostly uses in the legacy applications and tightly coupled between the services. The service calls each other and avoids the network latency between the service calls. The containerized application development provides many benefits including the lifecycle management and monitoring, etc. the VM provides another level of abstraction and less flexible compare to the containerized application. The containerized application defines the hardware and other requirements dynamically using the configuration files. Serverless deployment can be used in different uses cases.
The Microservices design pattern prefers to use Service instance per Container. So, the application easily scales or maintains the availability without affecting the other services. If the service fails, the application can easily decouple the problem and fix the services.
The Kubernetes service helps to expose the services outside the Kubernetes network using the service object.

Sidecar Design Pattern

The sidecar container is attached to a parent container and provides supporting features for the application. The sidecar design pattern allows adding another container in the parent pod. The parent and child containers can use different technologies or frameworks. It can be scale separately. The child container application depends on the parent container’s overall lifecycle of your main application.
The sidecar application can be used in the following use cases.
  • Monitor the parent application
  • Log aggregation and send the logs to a centralized application without affecting the main application performance
  • Expose the User interface and Application Programming Interface (API)
  • Configuration
  • Proxy to remote service design pattern

Development requirement 

The application can be exposed using the host address and port number. The application might require exposing both API and User interface at the same time.
The service access using the ingress host ( ex
user-manager.careerdrill.net
). The application uses a different path with the same port number. The network exposes the same port number and uses the same firewall rules. The user interface can be accessed using the base root path and API access using the base root path with /api. The nodeport exposes the service on each Node’s IP at a static port.

Design

Source Code

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: user-manager
  labels:
    app: user-manager
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - user-manager.careerdrill.net
  rules:
    - host: user-manager.careerdrill.net
      http:
        paths:
        - path: /
          backend:
            serviceName: user-manager
            servicePort: 9443
        - path: /api
          backend:
            serviceName: user-rest
            servicePort: 9443
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: user-manager
data:
  USER_URL: "http://careerdrill.com"
  MAX_BYTES: "50000"

k8s.yaml

---
kind: Service
apiVersion: v1
metadata:
  name: user-manager
  labels:
    app: user-manager
spec:
  ports:
    - name: http
      port: 9443
      targetPort: 8000
      protocol: TCP
  selector:
    app: user-manager
  type: NodePort
---
kind: Service
apiVersion: v1
metadata:
  name: user-rest
  labels:
    app: user-manager
spec:
  ports:
    - name: rest-http-port
      port: 9443
      targetPort: 8087
      protocol: TCP
  selector:
    app: user-manager
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: user-manager
  labels:
    app: user-manager
spec:
  minReadySeconds: 20
  replicas: 1
  revisionHistoryLimit: 0

Reference


Published by HackerNoon on 2020/05/05