m4d3bug's blog

DevSecOps

0%

深入剖析K8s筆記(Pod的對象們)

Posted on Edited on In
3.4k 3 mins.

0x00 引言

编写yaml时很容易遇到的一个问题：什么属性属于Pod对象，而什么又属于Container对象？

0x01 Pod类

一言以蔽之，只需把Pod看成“机器”、“虚拟机”。就很容易把调度、网络、存储以及安全相关属性，归类为Pod级。

第一类对象

Pod“外在属性”对象。也就是“外貌”级别的node、host类对象。随便举例三个

nodeSelector

用于绑定Pod和Node的字段。

1
2
3
4
5
6
apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd   #Pod始终保持和携带“disktype: ssd”的node保持亲昵。

nodeName

一般由调度器负责填写，或手动指定“骗过”调度器，达到测试调试的目的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# kubectl get pods two-containers -o yaml ｜grep nodeName
apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    creationTimestamp: "2022-01-30T16:56:32Z"
    ...
  spec:
    containers:
    - image: nginx
      ...
    - args:
      ...
    dnsPolicy: ClusterFirst
    enableServiceLinks: true
    nodeName: storage-k3sw4.m4d3bug.com #<------------
    ...

hostAliases

直接定义Pod里的hosts

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...
1
2
3
4
5
6
7
# cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

第二类对象

Pod“内在属性”对象。也就是“经脉”级别的namespace类对象。随便举例两个

shareProcessNamespace

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true #Pod内共享PID Namespace, 使得你可以再shell容器里检查到nginx
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true #保持stdin开启
    tty: true #调用接受标准输入，方便attach

容器里去检查一下是否共享正常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# kubectl attach -it nginx -c shell
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 1A:89:15:C2:8F:CB  
          inet addr:10.42.2.167  Bcast:10.42.2.255  Mask:255.255.255.0
          inet6 addr: fe80::1889:15ff:fec2:8fcb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6845 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10250592 (9.7 MiB)  TX bytes:451381 (440.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    7 root      0:00 nginx: master process nginx -g daemon off;
   37 101       0:00 nginx: worker process
   38 101       0:00 nginx: worker process
   39 101       0:00 nginx: worker process
   40 101       0:00 nginx: worker process
   41 root      0:00 sh
   48 root      0:00 ps ax

hostNetwork

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true #共享宿主机网络，直接使用宿主机网络
  hostIPC: true #共享宿主机IPC，IPC通信
  hostPID: true #共享宿主机PID，看到宿主机运行进程
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

0x02 Container类

ImagePullPolicy

官网有很详细的说明，默认情况下为Always，Never或IfNotPresent则不会主动拉取，或不存在时拉取。

Lifecycle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart: #容器启动后立刻执行的操作，在容器ENTRYPOINT后执行，不一定等到完成后
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop: #杀死前执行的命令，先阻塞杀死hook进程后执行杀死。实现容器优雅退出。
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

0x03 Status类

Status类并不是严格意义上Pod和Container类之外的API对象，它更多的是体现Pod的当前状态，它是除了metadata和spec部分之外的重要字段，其中pod.status.phase是Pod的当前状态。

Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。

Running。这个状态下，Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。

Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。

Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。

Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

0x04 总结

本文简单阐述了几种Pod常见的对象，简单阐述了它们的作用范围，类别。

Welcome to my other publishing channels