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