[Kubernetes series] This article will take you through the K8S application pod node

Hits: 0

K8S application pod node

Target

In this section, I will learn with you about pod nodes in [Kubernetes] applications

  • Learn about Kubernetes Pods.
  • Learn about Kubernetes worker nodes.
  • Troubleshoot deployed apps.

1. Kubernetes Pods

In the previous section, we learned together how to create an application using kubectl . Here we revisit it together.

  1. Start the minikube cluster

start minikube

  1. Open the Kubernetes Dashboard

minikube dashboard

In the dashboard, we find the pods node and open it

1.1. What do pods in Kubernetes do?

A Pod is an abstraction from Kubernetes that represents a set of one or more application containers (such as [Docker] ), and some shared resources for those containers. These resources include:

  • shared storage, as a volume
  • network, as the unique cluster IP address
  • Information about how each container runs, such as the container image version or specific ports to use.

Pods model the ” logic host ” of an application and can contain relatively tightly coupled containers of different applications. For example, a Pod might contain both a container with a Node.js application and a different container serving data to be published by a Node.js web server. Containers in a Pod share IP addresses and ports, are always co-located and co-scheduled, and run in a shared context on the same worker node.

Pods are atomic units on the Kubernetes platform . When we create a Deployment on Kubernetes , the Deployment creates a Pod containing the container in it (instead of creating the container directly). Each Pod is bound to the worker node that schedules it, and remains there until terminated (according to restart policy) or deleted. If a worker node fails, the same pods are scheduled on other available worker nodes in the cluster.

Through the running program, we can see all the information of pods very intuitively in the web interface.

2. Working Node

First, let’s take a look at a picture:

Through this official picture, combined with the display content of the pods node in our own application, have you also discovered something?

Every pod runs on worker nodes . Worker nodes are machines in Kubernetes that participate in computations and can be virtual machines or physical machines, depending on the cluster. Each worker node is managed by the master node. Worker nodes can have multiple pods, and the Kubernetes master automatically handles scheduling pods on worker nodes in the cluster. The automatic scheduling of the master node takes into account the available resources on each worker node.

Every Kubernetes worker node must contain Kubelets and containers :

  • Kubelet, responsible for the process of communication between Kubernetes master and worker nodes; it manages Pods and containers running on machines.
  • A container runtime, such as Docker, is responsible for pulling container images from repositories, unpacking containers, and running applications.

3. Troubleshooting

The Kubectl command we have been using before to get information about the application, so how do we view the environment information of the deployed project? Of course, still use Kubectl related commands.

3.1. Common kubectl commands

Let’s take a look at some of the most common kubectl commands:

  • kubectl get – list resources
  • kubectl describe – Displays detailed information about a resource
  • kubectl logs – prints logs of pods and their containers
  • kubectl exec – execute a command on a container in a pod

3.2. Visual interface

In addition to using the above kubectl command to view and troubleshoot application failures, the Kubernetes dashboard (Dashboard) also provides us with the most intuitive display.

Click the application name to enter the details page

  • Metadata – Metadata

  • Resource information – Resource information

  • Conditions – Conditions

  • Controlled by – Controller

  • Persistent Volume Claims – Resource Volume

  • Events – Events

  • container state

4. Pod resource details

Seeing this, everyone must have some confusion. Can we view the entire pods resource more intuitively and make some modifications? Let’s take a look at a picture together:

  1. View pods logs.
  2. Rerun compile and load resources in the pod.
  3. Pod resource editing, where you can modify the current pod resource is similar.
  4. delete the current pod resource

pod resource details

kind: Pod
apiVersion: v1
metadata:
  name: hello-node-6b89d599b9-jdg2k
  generateName: hello-node-6b89d599b9-
  namespace: default
  uid: 52ca897e-8cf5-469c-a221-b19d1f5f8dfc
  resourceVersion: '1984'
  creationTimestamp: '2022-07-01T06:36:04Z'
  labels:
    app: hello-node
    pod-template-hash: 6b89d599b9
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: hello-node-6b89d599b9
      uid: 6fff5c66-6897-47f0-b531-c7f8c6d2acb3
      controller: true
      blockOwnerDeletion: true
  managedFields:
    - manager: kube-controller-manager
      operation: Update
      apiVersion: v1
      time: '2022-07-01T06:36:04Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:generateName: {}
          f:labels:
            .: {}
            f:app: {}
            f:pod-template-hash: {}
          f:ownerReferences:
            .: {}
            k:{"uid":"6fff5c66-6897-47f0-b531-c7f8c6d2acb3"}: {}
        f:spec:
          f:containers:
            k:{"name":"echoserver"}:
              .: {}
              f:image: {}
              f:imagePullPolicy: {}
              f:name: {}
              f:resources: {}
              f:terminationMessagePath: {}
              f:terminationMessagePolicy: {}
          f:dnsPolicy: {}
          f:enableServiceLinks: {}
          f:restartPolicy: {}
          f:schedulerName: {}
          f:securityContext: {}
          f:terminationGracePeriodSeconds: {}
    - manager: Go-http-client
      operation: Update
      apiVersion: v1
      time: '2022-07-01T06:36:05Z'
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          f:conditions:
            k:{"type":"ContainersReady"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
            k:{"type":"Initialized"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
            k:{"type":"Ready"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
          f:containerStatuses: {}
          f:hostIP: {}
          f:phase: {}
          f:podIP: {}
          f:podIPs:
            .: {}
            k:{"ip":"172.17.0.3"}:
              .: {}
              f:ip: {}
          f:startTime: {}
      subresource: status
spec:
  volumes:
    - name: kube-api-access-79cmb
      projected:
        sources:
          - serviceAccountToken:
              expirationSeconds: 3607
              path: token
          - configMap:
              name: kube-root-ca.crt
              items:
                - key: ca.crt
                  path: ca.crt
          - downwardAPI:
              items:
                - path: namespace
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.namespace
        defaultMode: 420
  containers:
    - name: echoserver
      image: k8s.gcr.io/echoserver:1.4
      resources: {}
      volumeMounts:
        - name: kube-api-access-79cmb
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
  restartPolicy: Always
  terminationGracePeriodSeconds: 30
  dnsPolicy: ClusterFirst
  serviceAccountName: default
  serviceAccount: default
  nodeName: minikube
  securityContext: {}
  schedulerName: default-scheduler
  tolerations:
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
  priority: 0
  enableServiceLinks: true
  preemptionPolicy: PreemptLowerPriority
status:
  phase: Running
  conditions:
    - type: Initialized
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2022-07-01T06:36:04Z'
    - type: Ready
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2022-07-01T06:36:05Z'
    - type: ContainersReady
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2022-07-01T06:36:05Z'
    - type: PodScheduled
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2022-07-01T06:36:04Z'
  hostIP: 192.168.49.2
  podIP: 172.17.0.3
  podIPs:
    - ip: 172.17.0.3
  startTime: '2022-07-01T06:36:04Z'
  containerStatuses:
    - name: echoserver
      state:
        running:
          startedAt: '2022-07-01T06:36:04Z'
      lastState: {}
      ready: true
      restartCount: 0
      image: k8s.gcr.io/echoserver:1.4
      imageID: >-
        docker-pullable://k8s.gcr.io/echoserver@sha256:5d99aa1120524c801bc8c1a7077e8f5ec122ba16b6dda1a5d3826057f67b9bcb
      containerID: >-
        docker://ad3680651ec9494578d3217606d040e1ce5469eb8ba7644f8efa4d8c0d5e8411
      started: true
  qosClass: BestEffort

Summarize

The content of this section is relatively simple, but it is very important. It still takes a little time to do a detailed verification of learning and understanding.
So the content of this section is over here. In the next section, we will learn how to expose Pod to the outside for communication and interaction.

You may also like...

Leave a Reply

Your email address will not be published.