Pod基本概念

Pod是Kubernetes集群中最基本的资源对象。每个Pod由一个或多个业务容器和一个根容器(Pause容器)组成。

Kubernetes为每个Pod分配了唯一的IP，即Pod IP，Pod里的多个容器共享这个IP。

1kubectl get pods -o wide --all-namespaces | grep dashboard
2kube-system   kubernetes-dashboard-3109525988-5vnpv   1/1       Running   1          7h        10.244.0.8       cent0

实际上一个Pod内的多个容器共享相同的网络命名空间、IP、端口，也就是说这些容器之间能通过localhost来通信，此外这些容器还可以共享相同存储卷。

通过使用虚拟二层网络技术(如flannel)，Kubernetes集群底层网络支持一个Pod内容器和另外一个Node上Pod内容器之间的TCP/IP通信。

关于Pod的yaml详细定义参考resources-reference Pod v1。 Pod创建成功后，就会被持久化到etcd中，Master节点会把Pod调度到某个具体的Node上，并由该Node上的kubelet进程启动相关的Docker容器。 如果Pod中的容器停止时，Kubernetes会重新启动这个Pod，Pod所在Node节点宕机，则这个Node上的所有Pod会被调度到其他Node上。

1apiVersion: v1
2kind: Pod
3metadata:
4  name: pod-example
5spec:
6  containers:
7  - image: ubuntu:trusty
8    command: ["echo"]
9    args: ["Hello World"]

计算资源限额

可以为Pod内容器设置计算资源限额。 Kubernetes当前支持对CPU核的数量和内存大小两种资源设置限额。

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: frontend
 5spec:
 6  containers:
 7  - name: db
 8    image: mysql
 9    resources:
10      requests:
11        memory: "64Mi"
12        cpu: "250m"
13      limits:
14        memory: "128Mi"
15        cpu: "500m"
16  - name: wp
17    image: wordpress
18    resources:
19      requests:
20        memory: "64Mi"
21        cpu: "250m"
22      limits:
23        memory: "128Mi"
24        cpu: "500m"

spec.containers.resources.requests表示该资源的最小申请量，即Pod容器启动时必须满足的，spec.containers.resources.limits表示该资源最大允许的数量，当Pod内容器使用超过这个量时会被Kubernetes杀掉并重启。 上面的定义mysql容器申请0.25个CPU及64MB内存，运行过程中不超过0.5个CPU和128MB内存。

容器健康检查

Pod通过LivenessProbe和ReadinessProbe两种探针来检查容器的健康状态：

  • LivenessProbe 用于判断容器是否健康，如果LivenessProbe探测到容器不健康，kubelet将删除该容器并根据容器的重启策略做相应的处理。如果容器不包含LivenessProbe，则kubelet认为该容器的LivenessProbe探针永远返回success。
  • ReadinessProbe 用于判断容器是否启动完成且准备接收请求。如果该探针探测到失败，则Endpoint Controller将会从Service的Endpoint中删除包含该容器Pod的条目。

Kubelet定期调用容器中的LivenessProbe针来检查容器的健康状态。

关于探针的配置参考这里Configuring Liveness and Readiness Probes。

如HttpGetAction探针：

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  labels:
 5    test: liveness
 6  name: liveness-http
 7spec:
 8  containers:
 9
10  - name: liveness
11
12    args:
13    - /server
14
15    image: gcr.io/google_containers/liveness
16
17    livenessProbe:
18      httpGet:
19        path: /healthz
20        port: 8080
21        httpHeaders:
22          - name: X-Custom-Header
23            value: Awesome
24      initialDelaySeconds: 3
25      periodSeconds: 3

静态Pod

静态Pod是一种特殊的Pod，由kubelet进程直接管理，仅存在于特定Node上。 静态Pod不会被存储到Kubernetes集群的持久化存储etcd中，而是被保存在某个具体Node上的某个目录中的文件内。

静态Pod的定义文件的存储位置可以在启动kubelet时通过–pod-manifest-path=参数指定。 Kubelet进程会定时扫描这个目录，根据该目录中的.yaml和.json文件进行创建。静态Pod无法通过kube-apiserver直接管理。 使用ps命令在Master节点上查看kubelet进程:

1ps -ef | grep kubelet
2root      2093     1  6 18:27 ?        00:08:31 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local

可以看到--pod-manifest-path=/etc/kubernetes/manifests

1cd /etc/kubernetes/manifests
2ls
3etcd.json  kube-apiserver.json  kube-controller-manager.json  kube-scheduler.json

可以看到使用kubeadm init创建的Kubernetes集群，Master节点上的etcd, kube-apiserver, kube-controller-manager， kube-scheduler这些Pod都是静态Pod。

参考