- By刘立博
- 2023-01-29 12:41:34
- 454人已阅读
Pod结构
一个包含多个容器的Pod中包含一个用来拉取文件的程序和一个web服务器,均使用持久卷作为容器间的共享存储
Kubernetes集群中Pod主要有两种用法
(1)运行单个容器的Pod,在这种情况下,可以将Pod看作单个容器的包装器,并且Kubernetes直接管理Pod,而不是容器
一个栗子:创建NGINX POD
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: my-nginx
spec:
containers:
- image: nginx
name: my-nginx
(2)启动Pod
kubectl apply -f nginx-pod
Kubectl get po
(3)通过describe查看Pod信息
kubectl describe pod my-nginx
(2)运行多个协同工作的容器Pod,Pod可能形成单个内聚的服务单元,一个容器将文件从共享卷提供给公众,而另一个单独的SideCar容器则刷新或更新这些文件,Pod将这些容器和存储资源打包为一个可管理的实体
一个栗子:使用Job创建一个Pod,打印信息后退出
(1)编写配置文件
apiVersion: batch/v1
kind: Job
metadata:
name: my-hello
spec:
completions: 5
template:
spec:
containers:
- name: my-hello
image: nginx
command: ['sh','-c','echo "hello,Kubernetes" && sleep 10']
restartPolicy: OnFailure
(2)启动Pod、测试
kubectl apply -f hello
kubectl get po
(3)查看Pod阶段信息
kubectl get po -w
POD的生命周期
和一个独立的应用容器一样,Pod页呗认为是相对临时性的实体,Pod会被创建、赋予唯一标识、调度到节点并在被调度到其他节点或删除之前一直在这个节点上运行
容器阶段
Pending:Pod已被Kubernetes系统接受,但有一个或者多个容器尚未创建或运行,此阶段包括等待Pod倍调度的事件和通过网络下载镜像的时间
Running:Pod已经绑定到了某个节点,Pod中所有容器都被创建,至少有一个容器仍在运行,或者处于启动或重启状态
Succeed:Pod中所有容器都已成功终止,并且不会再重启
Failed:Pod中所有容器都已终止,并且至少有一个容器是失败终止,也就是说容器以非0状态退出或者被系统终止
Unknown:因为某些原因无法取得Pod状态,这种情况通常是因为与Pod所在主机通信失败
容器状态
一旦调度器将Pod分配给某个节点,kubelet就通过容器运行时开始为Pod创建容器,容器状态有三种:Waiting、Running、Terminated
Waiting:处于Waiting状态的容器仍在运行他完成启动所需要的操作,例如,从某个容器镜像仓库拉取容器镜像,或者想容器应用Secret数据等,当你使用kubectl来查询包含waiting状态的容器Pod时,你也会看到一个Reason字段,其中给出容器处于等待状态的原因
Running:Running状态表明容器正在执行状态并且没有问题发生,如果配置了PostStart回调,那么该回调已经执行完成,如果你使用kubectl来查询包含Running状态的Pod,你也会看到关于容器进入Running状态的信息
Terminated:处于Terminated状态的容器为正常结束或失败的容器,可以查看容器进入此状态的时间、退出代码已经起止时间
一个栗子:在启动和结束阶段输出信息
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: life-nginx
spec:
containers:
- name: life-nginx
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
(2)启动Pod
kubectl apply -f life
(3)进入容器,查看信息
可见,在postStart阶段,已正确执行了配置的command
exec -it life-nginx sh
cat /usr/share/message
创建包含Init容器的Pod
理解Init容器:每个Pod中可以包含多个容器,应用运行在这些容器里面,同时Pod页可以有一个或多个先于应用容器启动的Init容器
Init容器与普通容器类似,除了以下几点:
(1)他们总是运行至普通容器完成
(2)必须在普通容器启动前成功完成
一个栗子:定义一个具有init容器的Pod,当init-container执行完成后,app-container才会启动
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: myapp
labels:
app: myapp
spec:
containers:
- name: myapp
image: busybox:1.28
command: ['sh','-c', 'date && sleep 3600']
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80
initContainers:
- name: init-container
image: busybox:1.28
command: ['sh','-c', 'date && sleep 10']
(2)查看Pod信息
可见,当init容器启动完成后,myapp容器才会启动
kubectl get po -w
使用探针检查Pod的健康性
探针的作用:探针是由Kubelet对容器执行的定期诊断,要执行诊断,kubelet调用由容器实现的Handler,目前有三种类型的处理程序:
(1)execAction:在容器内执行命令,如果正确完成则诊断为成功
(2)TCPSocketAction:对容器IP地址上指定的端口执行TCP检查,如果端口打开则诊断为成功
(3)HTTPGETAction:对容器IP地址上指定端口和路径执行HTTP请求,如果响应状态码大于等于200且小于400则认为成功
一个栗子:使用探针检测容器健康性
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: liveness-http
labels:
test: liveness
spec:
containers:
- name: liveness
image: mirrorgooglecontainers/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
(2)监控容器状态
可见,当没有响应探针的时,kubenetes判断容器不健康,自动重启容器
kubectl get po -w
为容器设置启动时要执行的命令和参数
创建Pod时设置命令及参数
创建Pod时,可以为其设置启动时要执行的命令与参数,命令填写在command字段下,参数填写在args字段下
一个栗子:设置Pod执行的命令与参数
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: command-demo
labels:
purpose: demonstarte-command
spec:
containers:
- name: command-demo-container
image: debian
command: ["printenv"]
args: ["HOSTNAME","KUBERNETES_PORT"]
restartPolicy: OnFailure
为容器定义相互依赖的环境变量
当创建一个Pod时,可以为运行在Pod中的容器设置相互依赖的环境变量,设置相互依赖的环境变量,可以在配置清单文件env的value中使用
一个栗子:定义容器环境变量
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: dependent-envars-demo
spec:
containers:
- name: dependent-envars-demo
image: debian
env:
- name: SERVICE_PORT
value: "80"
- name: SERVICE_IP
value: "127.0.0.1"
restartPolicy: OnFailure
用节点亲和性把Pod分配到节点
(1)列出当前集群中节点以及标签
kubectl get nodes --show-labels
(2)为节点添加标签
kubectl label nodes node2 servertype=liulibo
一个栗子:将Pod部署在servertype等于liulibo的节点上
根据上面的两个命令为节点打上标签后,即可通过这个栗子将Pod运行在指定的节点
(1)编写配置文件
apiVersion: v1
kind: Pod
metadata:
name: my-nginx
spec:
containers:
- image: nginx
name: my-nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: servertype
operator: In
values:
- liulibo
(2)启动容器
kubectl apply -f selector
kubectl describe pod my-nginx