目录
基本概念
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: {}