docker调度的是容器,在k8s集群中,最小的调度单元是Pod(豆荚)
为什么引入Pod
- 与容器引擎解耦 Docker、Rkt。平台设计与引擎的具体的实现解耦
- 多容器共享网络|存储|进程 空间, 支持的业务场景更加灵活
使用yaml格式定义Pod
myblog/pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
- name: mysql
image: mysql:5.7
args:
- --character-set-server=utf8mb4
- --collation-server=utf8mb4_unicode_ci
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "myblog"
版本说明
资源类型与apiVersion对照表
快速获得资源和版本
$ kubectl explain pod
$ kubectl explain Pod.apiVersion
创建和访问Pod
## 创建namespace, namespace是逻辑上的资源池
$ kubectl create namespace luffy
## 使用指定文件创建Pod
$ kubectl create -f pod.yaml
## 查看pod,可以简写po
## 所有的操作都需要指定namespace,如果是在default命名空间下,则可以省略
$ kubectl -n luffy get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
myblog 2/2 Running 0 3m 10.244.1.146 k8s-slave1
## 回顾流程
## 使用Pod Ip访问服务,3306和8002
$ curl 10.244.1.146:8002/blog/index/
## 进入容器,执行初始化, 不必到对应的主机执行docker exec
$ kubectl -n luffy exec -ti myblog -c myblog bash
/ # env
/ # python3 manage.py migrate
$ kubectl -n luffy exec -ti myblog -c mysql bash
/ # mysql -p123456
## 再次访问服务,3306和8002
$ curl 10.244.1.146:8002/blog/index/
Infra容器
登录k8s-slave1节点
$ docker ps -a |grep myblog ## 发现有三个容器
# 其中包含mysql和myblog程序以及Infra容器
# 为了实现Pod内部的容器可以通过localhost通信,每个Pod都会启动Infra容器,然后Pod内部的其他容器的网络空间会共享该Infra容器的网络空间(Docker网络的container模式),Infra容器只需要hang住网络空间,不需要额外的功能,因此资源消耗极低。
## 登录master节点,查看pod内部的容器ip均相同,为pod ip
$ kubectl -n luffy exec -ti myblog -c myblog bash
/ # ifconfig
$ kubectl -n luffy exec -ti myblog -c mysql bash
/ # ifconfig
pod容器命名: k8s_
查看pod详细信息
# 查看pod调度节点及pod_ip
$ kubectl -n luffy get pods -o wide
# 查看完整的yaml
$ kubectl -n luffy get po myblog -o yaml
# 查看pod的明细信息及事件
$ kubectl -n luffy describe pod myblog
#进入Pod内的容器
$ kubectl -n <namespace> exec <pod_name> -c <container_name> -ti /bin/sh
#查看Pod内容器日志,显示标准或者错误输出日志
$ kubectl -n <namespace> logs -f <pod_name> -c <container_name>
更新服务版本
$ kubectl apply -f demo-pod.yaml
删除Pod服务
#根据文件删除
$ kubectl delete -f demo-pod.yaml
#根据pod_name删除
$ kubectl -n <namespace> delete pod <pod_name>
Pod数据持久化
若删除了Pod,由于mysql的数据都在容器内部,会造成数据丢失,因此需要数据进行持久化。 - 定点使用hostpath挂载,nodeSelector定点
myblog/pod-with-volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
volumes:
- name: mysql-data
hostPath:
path: /opt/mysql/data
nodeSelector: # 使用节点选择器将Pod调度到指定label的节点
component: mysql
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
- name: mysql
image: mysql:5.7
args:
- --character-set-server=utf8mb4
- --collation-server=utf8mb4_unicode_ci
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "myblog"
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
- 执行创建
## 若存在旧的同名服务,先删除掉,后创建
$ kubectl -n luffy delete pod myblog
## 创建
$ kubectl create -f pod-with-volume.yaml
## 此时pod状态Pending
$ kubectl -n luffy get po
NAME READY STATUS RESTARTS AGE
myblog 0/2 Pending 0 32s
## 查看原因,提示调度失败,因为节点不满足node selector
$ kubectl -n luffy describe po myblog
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 12s (x2 over 12s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.
## 为节点打标签
$ kubectl label node k8s-slave1 component=mysql
## 再次查看,已经运行成功
$ kubectl -n luffy get po
NAME READY STATUS RESTARTS AGE IP NODE
myblog 2/2 Running 0 3m54s 10.244.1.150 k8s-slave1
## 到k8s-slave1节点,查看/opt/mysql/data
$ ll /opt/mysql/data/
total 188484
-rw-r----- 1 polkitd input 56 Mar 29 09:20 auto.cnf
-rw------- 1 polkitd input 1676 Mar 29 09:20 ca-key.pem
-rw-r--r-- 1 polkitd input 1112 Mar 29 09:20 ca.pem
drwxr-x--- 2 polkitd input 8192 Mar 29 09:20 sys
...
## 执行migrate,创建数据库表,然后删掉pod,再次创建后验证数据是否存在
$ kubectl -n luffy exec -ti myblog python3 manage.py migrate
## 访问服务,正常
$ curl 10.244.1.150:8002/blog/index/
## 删除pod
$ kubectl delete -f pod-with-volume.yaml
## 再次创建Pod
$ kubectl create -f pod-with-volume.yaml
## 查看pod ip并访问服务
$ kubectl -n luffy get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE
myblog 2/2 Running 0 7s 10.244.1.151 k8s-slave1
## 未重新做migrate,服务正常
$ curl 10.244.1.151:8002/blog/index/
- 使用PV+PVC连接分布式存储解决方案
- ceph
- glusterfs
- nfs
服务健康检查
检测容器服务是否健康的手段,若不健康,会根据设置的重启策略(restartPolicy)进行操作,两种检测机制可以分别单独设置,若不设置,默认认为Pod是健康的。
两种机制:
- LivenessProbe探针 存活性探测:用于判断容器是否存活,即Pod是否为running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的重启策略是否重启,如果一个容器不包含LivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。
...
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 10 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
...
- ReadinessProbe探针 可用性探测:用于判断容器是否正常提供服务,即容器的Ready是否为True,是否可以接收请求,如果ReadinessProbe探测失败,则容器的Ready将为False, Endpoint Controller 控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除,不再将任何请求调度此Pod上,直到下次探测成功。(剔除此pod不参与接收请求不会将流量转发给此Pod)
...
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 10
...
三种类型:
- exec:通过执行命令来检查服务是否正常,返回值为0则表示容器健康
...
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
...
-
httpGet方式:通过发送http请求检查服务是否正常,返回200-399状态码则表明容器健康
-
tcpSocket:通过容器的IP和Port执行TCP检查,如果能够建立TCP连接,则表明容器健康
...
livenessProbe:
tcpSocket:
port: 8002
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 10 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
...
- 完整文件 myblog/pod-with-healthcheck.yaml
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 10 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 10
- initialDelaySeconds:容器启动后第一次执行探测是需要等待多少秒。
- periodSeconds:执行探测的频率。默认是10秒,最小1秒。
- timeoutSeconds:探测超时时间。默认1秒,最小1秒。
- successThreshold:探测失败后,最少连续探测成功多少次才被认定为成功。默认是1。
- failureThreshold:探测成功后,最少连续探测失败多少次 才被认定为失败。默认是3,最小值是1。
K8S将在Pod开始启动10s(initialDelaySeconds)后利用HTTP访问8002端口的/blog/index/,如果超过2s或者返回码不在200~399内,则健康检查失败
重启策略
*Pod的重启策略(RestartPolicy)应用于Pod内的所有容器,并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时,kubelet将根据RestartPolicy的设置来进行相应的操作。 Pod的重启策略包括Always、OnFailure和Never,默认值为Always。 * - Always:当容器进程退出后,由kubelet自动重启该容器; - OnFailure:当容器终止运行且退出码不为0时,由kubelet自动重启该容器; - Never:不论容器运行状态如何,kubelet都不会重启该容器。
重启示例
apiVersion: v1
kind: Pod
metadata:
name: test-restart-policy
spec:
restartPolicy: Always
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 10
- 使用默认的重启策略,即 restartPolicy: Always ,无论容器是否是正常退出,都会自动重启容器
- 使用OnFailure的策略时
- 如果把exit 1,去掉,即让容器的进程正常退出的话,则不会重启
- 只有非正常退出状态才会重启
- 使用Never时,退出了就不再重启
可以看出,若容器正常退出,Pod的状态会是Completed,非正常退出,状态为CrashLoopBackOff
镜像拉取策略
spec:
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
imagePullPolicy: IfNotPresent
设置镜像的拉取策略,默认为IfNotPresent - Always,总是拉取镜像,即使本地有镜像也从仓库拉取 - IfNotPresent ,本地有则使用本地镜像,本地没有则去仓库拉取 - Never,只使用本地镜像,本地没有则报错
资源限制 为了保证充分利用集群资源,且确保重要容器在运行周期内能够分配到足够的资源稳定运行,因此平台需要具备
Pod的资源限制的能力。 对于一个pod来说,资源最基础的2个的指标就是:CPU和内存。
Kubernetes提供了个采用requests和limits 两种类型参数对资源进行预分配和使用限制。
完整文件:myblog/pod-with-resourcelimits.yaml
...
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
...
requests: - 容器使用的最小资源需求,作用于schedule阶段,作为容器调度时资源分配的判断依赖 - 只有当前节点上可分配的资源量 >= request 时才允许将容器调度到该节点 - request参数不限制容器的最大可使用资源 - requests.cpu被转成docker的--cpu-shares参数,与cgroup cpu.shares功能相同 (无论宿主机有多少个cpu或者内核,--cpu-shares选项都会按照比例分配cpu资源) - requests.memory没有对应的docker参数,仅作为k8s调度依据
limits: - 容器能使用资源的最大值 - 设置为0表示对使用的资源不做限制, 可无限的使用 - 当pod 内存超过limit时,会被oom - 当cpu超过limit时,不会被kill,但是会限制不超过limit值 - limits.cpu会被转换成docker的–cpu-quota参数。与cgroup cpu.cfs_quota_us功能相同 - limits.memory会被转换成docker的–memory参数。用来限制容器使用的最大内存
*对于 CPU,我们知道计算机里 CPU 的资源是按“时间片”的方式来进行分配的,系统里的每一个操作都需要 CPU 的处理,所以,哪个任务要是申请的 CPU 时间片越多,那么它得到的 CPU 资源就越多。 * CGroup 里面对于 CPU 资源的单位换算:
CPU = 1000 millicpu(1 Core = 1000m)
*这里的 m 就是毫、毫核的意思,Kubernetes 集群中的每一个节点可以通过操作系统的命令来确认本节点的 CPU 内核数量,然后将这个数量乘以1000,得到的就是节点总 CPU 总毫数。比如一个节点有四核,那么该节点的 CPU 总毫量为 4000m。 *
docker run命令和 CPU 限制相关的所有选项如下:
docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:16.04 /bin/bash
*将 CFS 调度的周期设为 50000,将容器在每个周期内的 CPU 配额设置为 25000,表示该容器每 50ms 可以得到 50% 的 CPU 运行时间。
注意:若内存使用超出限制,会引发系统的OOM机制,因CPU是可压缩资源,不会引发Pod退出或重建*
完善后的yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
volumes:
- name: mysql-data
hostPath:
path: /opt/mysql/data
nodeSelector: # 使用节点选择器将Pod调度到指定label的节点
component: mysql
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 15 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 15
- name: mysql
image: mysql:5.7
args:
- --character-set-server=utf8mb4
- --collation-server=utf8mb4_unicode_ci
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "myblog"
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 15
periodSeconds: 20
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
pod优化
- 考虑真实的使用场景,像数据库这类中间件,是作为公共资源,为多个项目提供服务,不适合和业务容器绑定在同一个Pod中,因为业务容器是经常变更的,而数据库不需要频繁迭代
- yaml的环境变量中存在敏感信息(账号、密码),存在安全隐患
拆分yaml
myblog/mysql.yaml
apiVersion: v1
kind: Pod
metadata:
name: mysql
namespace: luffy
labels:
component: mysql
spec:
hostNetwork: true # 声明pod的网络模式为host模式,效果同docker run --net=host
volumes:
- name: mysql-data
hostPath:
path: /opt/mysql/data
nodeSelector: # 使用节点选择器将Pod调度到指定label的节点
component: mysql
containers:
- name: mysql
image: mysql:5.7
args:
- --character-set-server=utf8mb4
- --collation-server=utf8mb4_unicode_ci
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "myblog"
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 15
periodSeconds: 20
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
myblog/myblog.yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
imagePullPolicy: IfNotPresent
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "172.21.51.55"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 15 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 15
执行yaml
## 先删除旧pod
$ kubectl -n luffy delete po myblog
## 分别创建mysql和myblog
$ kubectl create -f mysql.yaml
$ kubectl create -f myblog.yaml
## 查看pod,注意mysqlIP为宿主机IP,因为网络模式为host
$ kubectl -n luffy get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE
myblog 1/1 Running 0 41s 10.244.1.152 k8s-slave1
mysql 1/1 Running 0 52s 172.21.51.67 k8s-slave1
## 访问myblog服务正常
$ curl 10.244.1.152:8002/blog/index/
环境变量中敏感信息带来的安全隐患
为什么要统一管理环境变量
- 环境变量中有很多敏感的信息,比如账号密码,直接暴漏在yaml文件中存在安全性问题
- 团队内部一般存在多个项目,这些项目直接存在配置相同环境变量的情况,因此可以统一维护管理
- 对于开发、测试、生产环境,由于配置均不同,每套环境部署的时候都要修改yaml,带来额外的开销
k8s提供两类资源,configMap和Secret,可以用来实现业务配置的统一管理, 允许将配置文件与镜像文件分离,以使容器化的应用程序具有可移植性 。
- configMap,通常用来管理应用的配置文件或者环境变量,myblog/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myblog
namespace: luffy
data:
MYSQL_HOST: "172.21.51.55"
MYSQL_PORT: "3306"
创建并查看configMap:
$ kubectl create -f configmap.yaml
$ kubectl -n luffy get cm myblog -oyaml
或者可以使用命令的方式,从文件中创建,比如:configmap.txt
$ cat configmap.txt
MYSQL_HOST=172.21.51.55
MYSQL_PORT=3306
$ kubectl create configmap myblog --from-env-file=configmap.txt
-
Secret,管理敏感类的信息,默认会base64编码存储,有三种类型
- Service Account :用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中;创建ServiceAccount后,Pod中指定serviceAccount后,自动创建该ServiceAccount对应的secret;
- Opaque : base64编码格式的Secret,用来存储密码、密钥等;
- kubernetes.io/dockerconfigjson :用来存储私有docker registry的认证信息。
myblog/secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: myblog
namespace: luffy
type: Opaque
data:
MYSQL_USER: cm9vdA== #注意加-n参数, echo -n root|base64
MYSQL_PASSWD: MTIzNDU2
创建并查看:
$ kubectl create -f secret.yaml
$ kubectl -n luffy get secret
如果不习惯这种方式,可以通过如下方式:
$ cat secret.txt
MYSQL_USER=root
MYSQL_PASSWD=123456
$ kubectl -n luffy create secret generic myblog --from-env-file=secret.txt
修改后的mysql的yaml,资源路径:myblog/mysql-with-config.yaml
...
spec:
containers:
- name: mysql
args:
- --character-set-server=utf8mb4
- --collation-server=utf8mb4_unicode_ci
env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_USER
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_PASSWD
- name: MYSQL_DATABASE
value: "myblog"
...
整体修改后的myblog的yaml,资源路径:myblog/myblog-with-config.yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
containers:
- name: myblog
image: 172.21.51.143:5000/myblog:v1
imagePullPolicy: IfNotPresent
env:
- name: MYSQL_HOST
valueFrom:
configMapKeyRef:
name: myblog
key: MYSQL_HOST
- name: MYSQL_PORT
valueFrom:
configMapKeyRef:
name: myblog
key: MYSQL_PORT
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_USER
- name: MYSQL_PASSWD
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_PASSWD
ports:
- containerPort: 8002
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 15 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 15
*在部署不同的环境时,pod的yaml无须再变化,只需要在每套环境中维护一套ConfigMap和Secret即可。但是注意configmap和secret不能跨namespace使用,且更新后,pod内的env不会自动更新,重建后方可更新。 *
如何编写资源yaml
- 拿来主义,从机器中已有的资源中拿
$ kubectl -n kube-system get po,deployment,ds
- 学会在官网查找, https://kubernetes.io/docs/home/
- 从kubernetes-api文档中查找, https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#pod-v1-core
- kubectl explain 查看具体字段含义
pod状态与生命周期
Pod的状态如下表所示:
生命周期示意图:
启动和关闭示意:
初始化容器: - 验证业务应用依赖的组件是否均已启动 - 修改目录的权限 - 调整系统参数
...
initContainers:
- command:
- /sbin/sysctl
- -w
- vm.max_map_count=262144
image: alpine:3.6
imagePullPolicy: IfNotPresent
name: elasticsearch-logging-init
resources: {}
securityContext:
privileged: true
- name: fix-permissions
image: alpine:3.6
command: ["sh", "-c", "chown -R 1000:1000 /usr/share/elasticsearch/data"]
securityContext:
privileged: true
volumeMounts:
- name: elasticsearch-logging
mountPath: /usr/share/elasticsearch/data
...
验证Pod生命周期:
apiVersion: v1
kind: Pod
metadata:
name: pod-lifecycle
namespace: luffy
labels:
component: pod-lifecycless
spec:
initContainers:
- name: init
image: busybox
command: ['sh', '-c', 'echo $(date +%s): INIT >> /loap/timing']
volumeMounts:
- mountPath: /loap
name: timing
containers:
- name: main
image: busybox
command: ['sh', '-c', 'echo $(date +%s): START >> /loap/timing;
sleep 10; echo $(date +%s): END >> /loap/timing;']
volumeMounts:
- mountPath: /loap
name: timing
livenessProbe:
exec:
command: ['sh', '-c', 'echo $(date +%s): LIVENESS >> /loap/timing']
readinessProbe:
exec:
command: ['sh', '-c', 'echo $(date +%s): READINESS >> /loap/timing']
lifecycle:
postStart:
exec:
command: ['sh', '-c', 'echo $(date +%s): POST-START >> /loap/timing']
preStop:
exec:
command: ['sh', '-c', 'echo $(date +%s): PRE-STOP >> /loap/timing']
volumes:
- name: timing
hostPath:
path: /tmp/loap
创建pod测试:
$ kubectl create -f pod-lifecycle.yaml
## 查看demo状态
$ kubectl -n luffy get po -o wide -w
## 查看调度节点的/tmp/loap/timing
$ cat /tmp/loap/timing
1585424708: INIT
1585424746: START
1585424746: POST-START
1585424754: READINESS
1585424756: LIVENESS
1585424756: END
*须主动杀掉 Pod 才会触发 pre-stop hook,如果是 Pod 自己 Down 掉,则不会执行 pre-stop hook ,且杀掉Pod进程前,进程必须是正常运行状态,否则不会执行pre-stop钩子 *
pod 总结 1. 实现k8s平台与特定的容器运行时解耦,提供更加灵活的业务部署方式,引入了Pod概念 2. k8s使用yaml格式定义资源文件,yaml中Map与List的语法,与json做类比 3. 通过kubectl apply| get | exec | logs | delete 等操作k8s资源,必须指定namespace 4. 每启动一个Pod,为了实现网络空间共享,会先创建Infra容器,并把其他容器网络加入该容器 5. 通过livenessProbe和readinessProbe实现Pod的存活性和就绪健康检查 6. 通过requests和limit分别限定容器初始资源申请与最高上限资源申请 7. Pod通过initContainer和lifecycle分别来执行初始化、pod启动和删除时候的操作,使得功能更加全面和灵活 8. 编写yaml讲究方法,学习k8s,养成从官方网站查询知识的习惯
做了哪些工作:
- 定义Pod.yaml,将myblog和mysql打包在同一个Pod中,使用myblog使用localhost访问mysql
- mysql数据持久化,为myblog业务应用添加了健康检查和资源限制
- 将myblog与mysql拆分,使用独立的Pod管理
- yaml文件中的环境变量存在账号密码明文等敏感信息,使用configMap和Secret来统一配置,优化部署
面临的问题:
- 业务应用启动多个副本
- Pod重建后IP会变化,外部如何访问Pod服务
- 运行业务Pod的某个节点挂了,可以自动帮我把Pod转移到集群中的可用节点启动起来
- 我的业务应用功能是收集节点监控数据,需要把Pod运行在k8集群的各个节点上