Kubernetes Pod详解

目录

• 基本概念
• pod资源配额
• 容器的健康检查

基本概念

Pod是kubernetes集群中最基本的资源对象。每个pod由一个或多个业务容器和一个根容器（Pause容器）组成。Kubernetes为每个pod分配唯一的ip，pod内的所有容器共享这个Ip。

可以通过如下操作查看pods：

kubectl get pods -o wide --all-namespaces

NAME                                    READY     STATUS    RESTARTS   AGE       IP           NODE
missionlive-dz11-com-1622786470-2sk1r   1/1       Running   0          12h       172.17.2.3   ops-k8s-node-252

可以通过如下操作查看详细的Pod信息：

kubectl describe po missionlive-dz11-com-1622786470-2sk1r 

Name:		missionlive-dz11-com-1622786470-2sk1r
Namespace:	default
Node:		ops-k8s-node-252/10.1.61.252
Start Time:	Mon, 03 Jul 2017 10:30:21 +0800
Labels:		envrion=live
		name=missionlive-dz11-com
		pod-template-hash=1622786470
Status:		Running
IP:		172.17.2.3
Controllers:	ReplicaSet/missionlive-dz11-com-1622786470
Containers:
  missionlive-dz11-com:
    Container ID:	docker://bf2af6beca7192273a7fb62a150d065564802b2a761fa3715f827cf822f9a021
    Image:		dk-reg.op.douyuyuba.com/library/missionlive:latest
    Image ID:		docker-pullable://dk-reg.op.douyuyuba.com/library/missionlive@sha256:2004b8fb41c0e326b9e0816f786dbbe696cf6908e255170a97b0372c9d42888e
    Port:		80/TCP
    State:		Running
      Started:		Mon, 03 Jul 2017 10:30:27 +0800
    Ready:		True
    Restart Count:	0
    Volume Mounts:
      /usr/local/ngx_openresty/nginx/conf/vhost from nginx-conf (rw)
    Environment Variables:
      memory_limit:	<set to the key 'memory_limit' of config map 'missionlive-1'>
      msgserver:	<set to the key 'msgserver' of config map 'missionlive-1'>
      post_max_size:	<set to the key 'post_max_size' of config map 'missionlive-1'>
      str_ip:		<set to the key 'str_ip' of config map 'missionlive-1'>
Conditions:
  Type		Status
  Initialized 	True
  Ready 	True
  PodScheduled 	True
Volumes:
  nginx-conf:
    Type:	ConfigMap (a volume populated by a ConfigMap)
    Name:	missionlive-2
QoS Class:	BestEffort
Tolerations:	<none>
No events.

通过使用二层虚拟网络技术（如flannel），kubernetes集群底层网络支持一个Pod容器和另外一个node上的pod内容器之间的tcp/ip通信。

下面是一个pod的示例文件test-pod.yml：

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - image: docker.io/busybox
      command:
        - "echo"
      args:
        - "hello world"

执行kubect create -f test-pod.yml完成pod的创建。

pod创建成功以后，就会被持久化到etcd中，master节点会把pod调度到某个具体的node上，并由该node上的kubelet进程启动相关的docker容器。如果Pod中的容器停止时，kubernetes会重新启动这个Pod，pod所在node节点宕机，则这个Node上的所有pod会被调度到其他 node上。

pod资源配额

Kubernetes可以为Pod设置资源配额，目前支持对cpu核的数量和内存大小两种资源设置限额。

示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
    - name: db
      image: mysql
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "250m"
    - name: wordpress
      image: workdpress
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

spec.containers.resources.requests表示该资源的最小申请量，即pod容器启动时必须要满足的。

spec.containers.resources.limits表示该资源的最大允许数量，当pod内容器使用超过这个量时，该Pod会被kubernetes杀掉并重启。

上面定义mysql容器申请0.25个cpu及64MB内存，运行过程中不超过0.5个cpu和128MB内存

需要说明的是，要使用pod的配额功能，需要在kubernetes的apiserver的配置文件里启用ResourceQuota插件。示例：

KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"

容器的健康检查

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

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

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

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

下面给出一个HttpGetAction探针的示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:

  - name: liveness

    args:
    - /server

    image: gcr.io/google_containers/liveness

    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
          - name: X-Custom-Header
            value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

静态pod

最后简单说一说静态pod。什么是静态pod？我们知道在k8s的整个体系中，实际上实际控制pod启停的组件只有一个，那就是kubelet。kubelet的运行方式 有两种，一种是通过与kubernetes的master节点连接，接受任务并执行。另外一种则是可以作为一个独立组件运行。监听某个目录中的yml文件，当发现变化，就执行yml文件，我们可以在这个目录中定义启动Pod的yml文件，这样不需要master端，kubelet也会自行启动pod，但通过这方式启动的pod没法被master端调度。只能在当前的kubelet主机节点上运行，这种pod就被称作静态pod。另外多说一句，其实在最新版本的kubernetes中，使用kubeadm初始化集群的方式就是借助了这种方式 将master作为容器运行在kubelet管理的静态pod中。

下面是一个kubelet监听本地目录的启动参数示例：

/usr/bin/kubelet --cgroup-driver=systemd --max-pods=30 --allow-privileged=true --pod-infra-container-image=dk-reg.op.douyuyuba.com/kubernetes/pause-amd64:3.0 --pod-manifest-path=/etc/kubernetes/manifests --logtostderr=true --v=2 --address=10.1.61.129 --hostname-override=10.1.61.129

在上面的示例中，kubelet不用连接master，它只需要监听/etc/kuernetes/manifests目录即可。/etc/kubernetes/mainfests目录定义的一个yml文件示例如下：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: etcd
    tier: control-plane
  name: etcd
  namespace: kube-system
spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=http://127.0.0.1:2379
    - --data-dir=/var/lib/etcd
    - --listen-client-urls=http://127.0.0.1:2379
    image: dk-reg.op.douyuyuba.com/kubernetes/etcd-amd64:3.0.17
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /health
        port: 2379
        scheme: HTTP
      initialDelaySeconds: 15
      timeoutSeconds: 15
    name: etcd
    resources: {}
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd
    - mountPath: /etc/localtime
      name: localtime

  hostNetwork: true
  volumes:
  - hostPath:
      path: /data/etcd
    name: etcd
  - hostPath:
      path: /etc/localtime
    name: localtime

status: {}

参考：http://blog.frognew.com/2017/01/kubernetes-pods.html