标签：digest ipc 模式 life ann 种类 port 无法 文档
目录
Pod是kubernetes中你可以创建和部署的最?也是最简的单位。 ?个Pod代表着集群中运?的?个进程。
Pod中封装着应?的容器（有的情况下是好?个容器） ， 存储、 独?的?络IP， 管理容器如何运?的策略选项。 Pod代
表着部署的?个单位： kubernetes中应?的?个实例， 可能由?个或者多个容器组合在?起共享资源。
在Kubrenetes集群中Pod有如下两种使??式：
每个Pod都是应?的?个实例。 如果你想平?扩展应?的话（运?多个实例） ， 你应该运?多个Pod， 每个Pod都是?个应?实例。 在Kubernetes中， 这通常被称为replication。
Pod中可以同时运行多个进程（作为容器运行）协同工作。同一个Pod中的容器会自动的分配到同一个 node 上。同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。
注意在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件，如下图所示：
（图片来源于网络）
Pod中可以共享两种资源：网络和存储。
Pod也可以?于垂直应?栈（例如LAMP） ， 这样使?的主要动机是为了?持共同调度和协调管理应?程序， 例如：
为什么不直接在?个容器中运?多个应?程序呢？
1、透明，让Pod中的容器对基础设施可?， 以便基础设施能够为这些容器提供服务， 例如进程管理和资源监控。 这可以为?户带来极?的便利。
2、解耦软件依赖。 每个容器都可以进?版本管理， 独?的编译和发布。 未来kubernetes甚?可能?持单个容器的在线升级。
3、使??便。 ?户不必运???的进程管理器， 还要担?错误信号传播等。
4、效率。 因为由基础架构提供更多的职责， 所以容器可以变得更加轻量级。
Pod在设计?持就不是作为持久化实体的。 在调度失败、 节点故障、 缺少资源或者节点维护的状态下都会死掉会被驱逐。
通常， ?户不需要?动直接创建Pod， ?是应该使?controller（例如Deployments） ， 即使是在创建单个Pod的情况下。 Controller可以提供集群级别的?愈功能、 复制和升级管理。
Pod原语有利于：
因为Pod作为在集群的节点上运?的进程， 所以在不再需要的时候能够优雅的终?掉是?分必要的（?起使?发送KILL信号这种暴?的?式） 。 ?户需要能够放松删除请求， 并且知道它们何时会被终?， 是否被正确的删除。 ?户想终?程序时发送删除pod的请求， 在pod可以被强制删除前会有?个宽限期， 会发送?个TERM请求到每个容器的主进程。 ?旦超时， 将向主进程发送KILL信号并从API server中删除。 如果kubelet或者container manager在等待进程终?的过程中重启， 在重启后仍然会重试完整的宽限期。
示例流程如下：
删除宽限期默认是30秒。 kubectl delete 命令?持 —grace-period=
Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个咸鱼应用容器启动的Init容器。
Init容器与普通容器很像，除了一下亮点：
如果 Pod 的 Init 容器失败， Kubernetes 会不断地重启该 Pod， 直到 Init 容器成功为?。 然?， 如果 Pod 对应的restartPolicy 为 Never， 它不会重新启动。
Pause容器，又叫Infra容器。我们检查node节点的时候会发现每个node上都运行了很多的pause容器，例如如下。
[root@node02 ~]# docker ps |grep pause
db1f4da98626 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 24 hours ago Up 24 hours k8s_POD_myapp-9b4987d5-djdr9_default_995067e0-5124-11e9-80a7-000c295ec349_0
e344da31cee8 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 24 hours ago Up 24 hours k8s_POD_client-f5cdb799f-pklmc_default_25f4bf9b-5121-11e9-80a7-000c295ec349_0
de5e811fa5fa registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 28 hours ago Up 28 hours k8s_POD_nginx-deploy-84cbfc56b6-tcssz_default_10003a4a-5104-11e9-80a7-000c295ec349_0
3f7d179b79b9 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 30 hours ago Up 30 hours k8s_POD_kube-flannel-ds-amd64-gwbql_kube-system_0f2de1c5-506c-11e9-80a7-000c295ec349_1
cc07e6411d32 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 30 hours ago Up 30 hours k8s_POD_kube-proxy-cz2rf_kube-system_1f58e488-5068-11e9-80a7-000c295ec349_1kubernetes中的pause容器主要为每个业务容器提供以下功能：
[root@node02 ~]# docker run --name pause -d -p 8880:80 xiaobai20201/pause:3.1
Unable to find image 'xiaobai20201/pause:3.1' locally
3.1: Pulling from xiaobai20201/pause
Digest: sha256:59eec8837a4d942cc19a52b8c09ea75121acc38114a2c68b98983ce9356b8610
Status: Downloaded newer image for xiaobai20201/pause:3.1
d4078dc99bec81167c8d288c2b44485d407780913eee88458986d5bb3750c509然后再运??个nginx容器， nginx将为 localhost:2368 创建?个代理。
[root@node02 ~]# vim nginx.conf
error_log stderr;
events { worker_connections 1024; }
http {
access_log /dev/stdout combined;
server {
listen 80 default_server;
server_name example.com www.example.com;
location / {
proxy_pass http://127.0.0.1:2368;
}
}
}
[root@node02 ~]# docker run -d --name nginx -v `pwd`/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx
然后为ghost创建一个容器应用，这是一款博客软件。
[root@node02 ~]# docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost现在访问http://10.0.0.12:8880/ 就可以看到ghost博客的界面了
解析
pause容器将内部的80端?映射到宿主机的8880端?， pause容器在宿主机上设置好了?络namespace后， nginx容器加?到该?络namespace中， 我们看到nginx容器启动的时候指定了 --net=container:pause ， ghost容器同样加?到了该?络namespace中， 这样三个容器就共享了?络， 互相之间就可以使? localhost 直接通信， --ipc=contianer:pause --pid=container:pause 就是三个容器处于同?个namespace中， init进程为 pause ， 这时我们进?到ghost容器中查看进程情况。
Pod的status信息保存在PodStatus中定义，有一个phase字段
Pod的相位(phase)是Pod在其生命周期中的简单宏观概述，该阶段并不是对容器或Pod的总和汇总，也不是为了作为综合状态机。
Pod香味的数量和含义是严格指定的。除了文档中列举的状态外，不应该再假定Pod有其他phase值。
下面是phase可能的值：
Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 type 字段和一个 status 字段。type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。status 字段是一个字符串，可能的值有 True、False 和 Unknown。
在pod生命周期中可以做的一些事情。主容器启动前可以完成初始化容器，初始化容器可以有多个，他们是串行执行的，执行完成后就推出了，在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作，在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在程序启动后可以做两类检测 liveness probe（存活性探测） 和 readness probe（就绪性探测）
探针是由 kubelet 对容器执?的定期诊断。 要执?诊断， kubelet 调?由容器实现的 Handler。 有三种类型的处理程序：
Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：
解析
[root@master ~]# kubectl explain pods.spec.containers.livenessProbe.
KIND: Pod
VERSION: v1
exec <Object> #命令式探针
failureThreshold <integer> #探测失败次数，超过该次数才算失败，默认是3
periodSeconds <integer> #探测间隔时间，默认10s
successThreshold <integer> #探测成功的最少次数，默认是1，即探测成功1次就算是成功
tcpSocket <Object> #检测端口的探测
initialDelaySeconds #初始化延迟探测，第一次探测的时候，因为主程序未必启动完成
timeoutSeconds <integer> # 探测超时的秒数 默认1s
httpGet <Object> #http请求探测exec探针举例
[root@master manifests]# vim liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/healthy;sleep 30;rm -f /tmp/healthy;sleep 600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/healthy"]
initialDelaySecond: 1
periodSecond: 3
#运行并查看pod
[root@master manifests]# kubectl apply -f liveness-exec.yaml
pod/liveness-exec-pod created
[root@master manifests]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 25h
liveness-exec-pod 1/1 Running 0 5s
myapp-9b4987d5-47sjj 1/1 Running 0 25h
myapp-9b4987d5-684q9 1/1 Running 0 25h
myapp-9b4987d5-djdr9 1/1 Running 0 25h
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 29h
pod-demo 2/2 Running 4 4h33m
liveness-exec-pod 1/1 Running 1 87s
#重启次数变成1上面的资源清单中定义了一个Pod对象，基于busybox镜像启动一个运行“touch /tmp/healthy；sleep 30；rm -f /tmp/healthy；sleep 600”命令的容器，此命令在容器启动时创建/tmp/healthy文件，并于60秒之后将其删除。存活性探针运行“test -e /tmp/healthy”命令检查/tmp/healthy文件的存在性，若文件存在则返回状态码0，表示成功通过测试。
httpGet探测举例
[root@master manifests]# vim liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
#创建Pod并查看
[root@master manifests]# kubectl create -f liveness-httpget.yaml
pod/liveness-httpget-pod created
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 26h
liveness-exec-pod 1/1 Running 8 20m
liveness-httpget-pod 1/1 Running 0 8s
myapp-9b4987d5-47sjj 1/1 Running 0 25h
myapp-9b4987d5-684q9 1/1 Running 0 25h
myapp-9b4987d5-djdr9 1/1 Running 1 25h
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 29h
pod-demo 2/2 Running 4 4h53m
#手动进入容器删除index.html文件，再监控pod状态
[root@master manifests]# kubectl exec -it liveness-httpget-pod -- /bin/sh
/ # rm -f /usr/share/nginx/html/index.html
#查看pod
^C[root@master manifests]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 26h
liveness-exec-pod 0/1 CrashLoopBackOff 9 24m
liveness-httpget-pod 1/1 Running 1 3m41s
myapp-9b4987d5-47sjj 1/1 Running 0 25h
myapp-9b4987d5-684q9 1/1 Running 0 25h
myapp-9b4987d5-djdr9 1/1 Running 1 25h
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 29h
pod-demo 2/2 Running 4 4h57m
#发现liveness-httpget-pod已经重启了一次
TCP探测举例
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness-tcp
name: liveness-tcp
spec:
containers:
- name: liveness-tcp-demo
image: nginx:1.12-alpine
ports:
- name: http
containerPort: 80
livenessProbe:
tcpSocket:
port: http[root@master manifests]# vim readness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: http
path: /index.html
initialDelaySecond: 1
periodSeconds: 3此时pod运行正常，进入容器删除首页文件后观察pod状态
[root@master manifests]# kubectl exec -it readiness-httpget-pod -- /bin/sh
/ # rm -f /usr/share/nginx/html/index.html
[root@master manifests]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 26h
myapp-9b4987d5-47sjj 1/1 Running 0 26h
myapp-9b4987d5-684q9 1/1 Running 0 26h
myapp-9b4987d5-djdr9 1/1 Running 1 26h
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 30h
pod-demo 2/2 Running 5 5h27m
readiness-httpget-pod 0/1 Running 0 115s重写写入index.html文件后继续观察pod
/ # echo ad >/usr/share/nginx/html/index.html
^C[root@master manifests]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
client-f5cdb799f-pklmc 1/1 Running 0 26h
myapp-9b4987d5-47sjj 1/1 Running 0 26h
myapp-9b4987d5-684q9 1/1 Running 0 26h
myapp-9b4987d5-djdr9 1/1 Running 1 26h
nginx-deploy-84cbfc56b6-tcssz 1/1 Running 0 30h
pod-demo 2/2 Running 5 5h29m
readiness-httpget-pod 1/1 Running 0 3m54s如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。
如果希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy 为 Always 或 OnFailure。
如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。
如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。
请注意，如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。
定义容器启动后和终止前立即执行的动作
解析
[root@master ~]# kubectl explain pods.spec.containers.lifecycle.
postStart <Object> #启动后
- exec
- httpGet
- tcpSocket
preStop <Object> #终止前
- exec
- httpGet
- tcpSocketpostStart举例
[root@master manifests]# vim poststart-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: poststart-pod
namespace: default
spec:
containers:
- name: busybox-httpd
image: busybox
imagePullPolicy: IfNotPresent
lifecycle:
postStart:
exec:
command: ["mkdir","-p","/tmp/share"]
command: ["/bin/sh","-c","sleep 3600"]
#进入容器查看是否有/tmp/share目录
[root@master manifests]# kubectl exec -it poststart-pod -- /bin/sh
/ # ls -l /tmp
total 0
drwxr-xr-x 2 root root 6 Mar 29 09:19 sharehttps://www.cnblogs.com/linuxk
马永亮. Kubernetes进阶实战 (云计算与虚拟化技术丛书)
Kubernetes-handbook-jimmysong-20181218
标签：digest ipc 模式 life ann 种类 port 无法 文档
原文地址：https://www.cnblogs.com/wlbl/p/10652890.html
