An article to understand the advanced features of K8S

K8S Advanced Features

There are some advanced features in K8S that are worth understanding, such as elastic scaling of applications (see above), rolling updates (see above), configuration management, storage volumes, gateway routing , etc.

Before understanding these advanced features, it is necessary to look at some core concepts of K8S:

ReplicaSet

A ReplicaSet ensures that a specified number of Pod replicas are running at any time. Typically used to ensure the availability of a given number of identical Pods. It is recommended to use Deployment to manage ReplicaSet instead of using it directly.

ConfigMap

ConfigMap is an API object used to save non-confidential data into key-value pairs. When used, Pods can use it as environment variables, command line parameters, or configuration files in storage volumes. Use ConfigMap to separate your configuration data from your application code.

Volume

Volume refers to the storage volume, which contains the data directory accessible by the containers in the Pod. The files in the container are temporarily stored on the disk. When the container crashes, the files will be lost. At the same time, the files cannot be shared among multiple Pods. These two problems can be solved by using storage volumes.
Commonly used storage volumes are as follows:

• configMap: The configMap volume provides a way to inject configuration data into the Pod. The data stored in the ConfigMap object can be referenced by a volume of type configMap and then used by the containerized application running in the Pod.
• emptyDir: The emptyDir volume can be used to store cache data. When a Pod is dispatched to a Node, an emptyDir volume is created and the volume exists while the Pod runs on the Node. When the Pod is deleted from the node, the data in the emptyDir volume will also be permanently deleted.
• hostPath: A hostPath volume can mount files or directories on the host node file system into your Pod. The host in Minikube refers to the virtual machine where Minikube is located.
• local: A local volume represents a mounted local device, such as a disk, partition, or directory. Local volumes can only be used as statically created persistent volumes and do not yet support dynamic configuration.
• nfs: nfs volumes can mount NFS (Network File System) into your Pod.
• persistentVolumeClaim: The persistentVolumeClaim volume is used to mount a persistent volume (PersistentVolume) into a Pod. A persistent volume (PV) is a piece of storage in a cluster that can be provisioned in advance by an administrator or dynamically provisioned using a storage class. A persistent volume is a cluster resource similar to a node.
  

Ingress

Ingress can implement domain name-based access similar to Nginx through K8S's Ingress resources, thereby achieving load balancing access to Pods.

Install Ingress

Go to the page https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml, copy the contents, and save them to a file ingress-controller.yaml on the k8s master machine. The image address in it needs to be modified. You can directly use the following yaml content:

Download address (no points required): Download address

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  -apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  -apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  -apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  -apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  -apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      -patch
  -apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  -apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  -apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  -apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  -apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      hostNetwork: true
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: siriuszg/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                -NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

---

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx

---

Check whether the installation is successful

kubectl get pods -n ingress-nginx -o wide

Configure ingress access rules (similar to configuring nginx proxy forwarding configuration) to let ingress forward the domain name tomcat.core.com to the backend tomcat-service-yaml service. Create a new file ingress-tomcat.yaml with the following content:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: web-ingress
spec:
 rules:
 - host: tomcat.core.com # Forwarding domain name http:
    paths:
    - path: /
      backend: 
       serviceName: tomcat-service-yaml
       servicePort: 80 # service port 

View the effective ingress rules:

kubectl get ing

Configure the host on the access machine, master directory: /etc/hosts, add the following host in the host (the machine ip deployed by ingress corresponds to the domain name to be accessed)

192.168.159.131 tomcat.core.com
or 192.168.159.132 tomcat.core.com

After configuration, visit http://tomcat.core.com/ directly in the client browser to access tomcat normally.

Advanced Features

Configuration Management

ConfigMap allows you to separate configuration files from image files to make containerized applications portable. Next, we demonstrate how to inject the properties of ConfigMap into the environment variables of Pod.

Add the configuration file nginx-config.yaml to create a ConfigMap. The ConfigMap name is nginx-config, and the storage information is placed under the data node:

apiVersion: v1
kind: ConfigMap
metadata: 
 name: nginx-config
 namespace: default
data:
 nginx-env:test

Apply the nginx-config.yaml file to create a ConfigMap:

kubectl create -f nginx-config.yaml

Get all ConfigMaps:

kubectl get configmap

View the contents of ConfigMap in yaml format:

kubectl get configmaps nginx-config -o yaml

Add the configuration file nginx-deployment.yaml to create a Deployment, deploy an nginx service, and reference the properties in the ConfigMap in the Nginx environment variables:

apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      env:
       - name: NGINX_ENV # Set environment variables in Nginx valueFrom:
          configMapKeyRef:
           name: nginx-config # Set the name of ConfigMap key: nginx-env # The key to be taken

Apply the configuration file to create a Deployment:

kubectl apply -f nginx-deployment.yaml

After the creation is successful, check the environment variables in the Pod and find that the NGINX_ENV variable has been injected;

kubectl get pod -o wide

kubectl exec -it nginx-deployment-5ff74658b6-rlft8 --sh
# Enter the container console and execute the following command ECHO $NGINX_ENV

Storage Volume Usage

Through storage volumes, we can mount external data into containers for access by applications in the container, so that even if the container crashes, the data can still exist.

Remember that when we used Docker to deploy Nginx before, we mounted Nginx's html, logs, and conf directories from the outside into the container;

docker run -p 80:80 --name nginx \
-v /mydata/nginx/html:/usr/share/nginx/html \
-v /mydata/nginx/logs:/var/log/nginx \
-v /mydata/nginx/conf:/etc/nginx \
-d nginx:1.10

Minikube can be considered as a virtual machine. We can access it using Minikube's ssh command

minikube ssh

There is a docker user in Minikube by default. Let’s reset its password first.

sudo passwd docker

Create mydata directory in Minikube

mkdir /home/docker/mydata

We need to copy the nginx directory to Minikube to mount the directory. Note that the docker user can only modify files in the /home/docker directory. We copy the files using the scp command.

scp -r /home/macro/mydata/nginx [email protected]:/home/docker/mydata/nginx

Add the configuration file nginx-volume-deployment.yaml to create a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-volume-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      volumeMounts:
       - mountPath: /usr/share/nginx/html
         name: html-volume
       -mountPath: /var/logs/nginx
         name: logs-volume
       - mountPath: /etc/nginx
         name: conf-volume
   volumes:
    - name: html-volume
      hostPath:
       path: /home/docker/mydata/nginx/html
       type: Directory
    - name: logs-volume
      hostPath:
       path: /home/docker/mydata/nginx/logs
       type: Directory
    - name: conf-volume
      hostPath:
       path: /home/docker/mydata/nginx/conf
       type: Directory

Apply the configuration file to create a Deployment

kubectl apply -f nginx-volume-deployment.yaml

Add the configuration file nginx-service.yaml to create the Service

apiVersion: v1
kind: Service
metadata: 
 name: nginx-service
spec:
 type: NodePort
 selector:
  app: nginx
 ports:
 - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080

Check the Service access port

kubectl get services

Access the Nginx homepage information through the CURL command.

Summarize

Service is the core of K8S service. It shields service details and exposes service interfaces to the outside in a unified manner, truly achieving "microservices" . For example, one of our services A has three backups deployed, that is, three Pods. For users, they only need to pay attention to the entrance of one Service, and do not need to worry about which Pod to request. The advantages are very obvious: on the one hand, external users do not need to be aware of the IP changes caused by the unexpected crash of the service on the Pod and K8S re-pulling the Pod. External users also do not need to be aware of the IP changes caused by the Pod replacement due to the upgrade or change of the service. On the other hand, the Service can also perform traffic load balancing.

However, Service is mainly responsible for the network topology within the K8S cluster. So how can the outside of the cluster access the inside of the cluster? At this time, Ingress is needed. The explanation in the official document is:

Ingress is an API object that manages external access to services in a cluster. The typical access method is HTTP.

ngress can provide load balancing, SSL termination, and name-based virtual hosting.

Translation: Ingress is the access layer of the entire K8S cluster, complex cluster internal and external communications.

The network topology diagram of Ingress and Service is as follows:

kubectl troubleshooting service issues

How to troubleshoot a service deployment failure on K8S?

Use this command:

kubectl describe ${RESOURCE} ${NAME}

Scroll to the end and see the Events section, which will display the key logs of K8S in the process of deploying this service.

Generally speaking, most deployment failures can be located through kubectl describe pod ${POD_NAME}. Of course, specific problems still require specific analysis.

How to troubleshoot abnormal services deployed on K8S?

If the service is deployed successfully and the status is running, you need to enter the container inside the Pod to view your service logs:

View the logs printed by a container inside the Pod:

kubectl log ${POD_NAME} ‐c ${CONTAINER_NAME}.

Enter a container inside the Pod:

kubectl exec ‐it [options] ${POD_NAME} ‐c ${CONTAINER_NAME} [args]

The purpose of this command is to execute docker exec xxx through kubectl to enter the container instance. After that, users check the logs of their own services to locate the problem.

Has K8S really abandoned Docker?

Docker is a very popular container technology. There have been many articles saying that it has been abandoned by K8S and replaced by another container technology, containerd! In fact, containerd is just the underlying container runtime separated from Docker. It is no different from Docker in usage. It is very simple to transition from Docker to containerd, and there is basically no threshold. Just change the docker in the previous Docker command to crictl and it will be basically done. They are both produced by the same company and have the same usage. So no matter whether K8S abandons Docker or not, it has basically no impact on our developers!

K8S CRI

K8S released CRI (Container Runtime Interface), which unified the container runtime interface. Any container runtime that supports CRI can be used as the underlying container runtime of K8S.

Why does K8S abandon Docker as the container runtime and use containerd?

If you use Docker as the K8S container runtime, kubelet needs to call Docker through dockershim first, and then call containerd through Docker.

If you use containerd as the K8S container runtime, since containerd has a built-in CRI plug-in, kubelet can call containerd directly.
Using containerd not only improves performance (the call chain becomes shorter), but also reduces resource usage (Docker is not a pure container runtime and has a lot of other features).

Of course, in the future, Docker may directly implement the K8S CRI interface to be compatible with the underlying usage of K8S.

This is the end of this article about the advanced features of K8S. For more relevant content about the advanced features of K8S, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!