[Cloud] 3.Kuberdnetes Pod deploy

There are several deployable objects (Obejct ) in Kubernetes, but the smallest unit among them is a Pod . This Pod has an individual IP and can be configured as one container or multiple containers and volumes inside the Pod as shown in the figure. The recommendation is to configure one container per Pod. The reason is that, as MSA (Micro Service Architecture), if multiple containers exist in a Pod, it becomes difficult to collect logs by process or handle monitoring failures through monitoring.

​

반응형

Containers in a Pod all have the same IP. Pods can be scaled in/out depending on the situation in the Kubernetes cluster, and new pods are automatically created when a failure occurs, so IP changes occur frequently. In this case, if a service is provided by exposing the IP of the Pod to the outside, there may be a problem with the service due to the frequently changed IP. So, it is recommended to create a Service object in front of the Pod and configure it in a structure where all service requests are delivered to the Pod through the service object

​

Now let's deploy the Pod via YAML file. First, create a Pod directory under the Test directory, create a Pod.yaml file in that directory, enter the same content as the old one, and save it.

root@master-VirtualBox:~/test# mkdir Pod root@master-VirtualBox:~/test#cd Pod root@master-VirtualBox:~/test#vi Pod.yaml apiVersion: v1 kind: Pod ==> define deployed object metadata: labels: run: my-nginx name: my-nginx namespace: default spec: containers: - image: nginx:1.14.1 imagePullPolicy: Always name: my-nginx ports: - containerPort: 80 protocol: TCP ​

Now, let's deploy to Node using the created Pod.yaml file and look up the information.

root@master-VirtualBox:~/test/Pod# kubectl apply -f Pod.yaml ==> deployed Pod object pod root@master-VirtualBox:~/test/Pod# kubectl get pod ==> retrieve deployed pod information NAME READY STATUS RESTARTS AGE my-nginx 0/1 ContainerCreating 0 10s root@master-VirtualBox:~/test/Pod# root@master-VirtualBox:~/test/Pod# root@master-VirtualBox:~/test/Pod# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES my-nginx 1/1 Running 0 21s 172.16.168.198 worknode1-virtualbox <none> <none> root@master-VirtualBox:~/test/Pod# root@master-VirtualBox:~/test/Pod# root@master-VirtualBox:~/test/Pod# kubectl describe pod my-nginx  Name: my-nginx Namespace: default Priority: 0 Node: worknode1-virtualbox/192.168.1.5 Start Time: Mon, 01 Aug 2022 10:27:18 +0900 Labels: run=my-nginx Annotations: cni.projectcalico.org/podIP: 172.16.168.198/32 cni.projectcalico.org/podIPs: 172.16.168.198/32 Status: Running IP: 172.16.168.198 IPs: IP: 172.16.168.198 Containers: my-nginx: Container ID: containerd://7226da65d1387a927040dcdc899d7e269771536d420f423944ca195f42b9f17e Image: nginx:1.14.1 Image ID: docker.io/library/nginx@sha256:32fdf92b4e986e109e4db0865758020cb0c3b70d6ba80d02fe87bad5cc3dc228 Port: 80/TCP Host Port: 0/TCP State: Running Started: Mon, 01 Aug 2022 10:27:33 +0900 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dgp5c (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-dgp5c: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 63s default-scheduler Successfully assigned default/my-nginx to worknode1-virtualbox Normal Pulling 63s kubelet Pulling image "nginx:1.14.1" Normal Pulled 48s kubelet Successfully pulled image "nginx:1.14.1" in 14.381250558s Normal Created 48s kubelet Created container my-nginx Normal Started 48s kubelet Started container my-nginx root@master-VirtualBox:~/test/Pod# ​

Now we have deployed the Pod. Then, let's find out about the state of this Pod. Pod has 5 states as shown in the figure below.

• Pending: The state before the container is started in the Pod.
• Running: The state of the container running in the pod
• Succeeded: All containers in the Pod are normally terminated.
• Failed: One or more containers in the Pod are abnormally terminated. Unknown: When the state of the Pod is unknown

​

Let's take a look at the state of the Pod we just created. The status is Running, and the container is running normally.

root@master-VirtualBox:~/test/Pod# kubectl get pod NAME READY STATUS RESTARTS AGE my-nginx 1/1 Running 0 12m

​

Now, let's see how this distribution process works through the pictures. If you run the container with the kubectl command, the procedure goes through the process as shown in the figure below.

source of picture: Kubernetis in action

The picture above shows how docker images are created. If there is an image you want to run in the local storage, the download process is skipped. Let's take a look at one of the settings in the yaml file..

apiVersion: v1 kind: Pod metadata: labels: run: my-nginx name: my-nginx namespace: default spec: containers: - image: nginx:1.14.1 imagePullPolicy: Always name: my-nginx ports: - containerPort: 80 protocol: TCP

among above parameters, 

you can use the red imagePullPolicy parameter to set whether to download or omit the image. The values ​​that can be set and the operation method are as follows

 

• Always : Execute download of image from registry at every deployment
• Never:When deploying, use the image that exists in Node without downloading the image from the registry. An error occurs if the image does not exist in the node
• IfNotPresent : If the images to be deployed with default settings exist in Node, image download is skipped.

Two accounts are used for access, authentication, and authorization from the Kubernetes cluster to the API server. User account: The account used for user authority and authentication when accessing the API server through the kubectl command. Service account: The account used to access the API server from the process in the container in the cluster. ​ These accounts are defined in the yaml file, and default values ​​are used unless otherwise specified. Then, we will query the service account information through the yaml file and kubectl command.

apiVersion: v1 kind: Pod metadata: ... spec: containers: - image: nginx ... restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default ==>  serviceAccountName: default ​ root@master-VirtualBox:~/test/Pod# kubectl get service ==>  serviceaccounts services

​