【DevOps实战】Pod基本操作
myblog改造及优化,Pod声明周期,Pod操作小结
✨ 前言
在上一篇文章中,我们学习了 Pod 的常用设置,那么这篇文章咱们继续开动!
1. myblog改造及优化
目前完善后的 yaml,myblog/one-pod/pod-completed.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 中,因为业务容器是经常变更的,而数据库不需要频繁迭代
- yaml 的环境变量中存在敏感信息(账号、密码),存在安全隐患
解决问题一,需要拆分 yaml
myblog/two-pod/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.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.67"
- 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
创建测试
## 先删除旧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/two-pod/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myblog
namespace: luffy
data:
MYSQL_HOST: "172.21.51.67"
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.67
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 的认证信息。
- Service Account:用来访问 Kubernetes API,由 Kubernetes 自动创建,并且会自动挂载到 Pod 的
myblog/two-pod/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/two-pod/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/two-pod/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 不会自动更新,重建后方可更新。
2. Pod生命周期
🍑 如何编写资源 yaml
- 拿来主义,从机器中已有的资源中拿
$ kubectl -n kube-system get po,deployment,ds
🍑 pod状态与生命周期
Pod的状态如下表所示:
状态值 | 描述 |
---|---|
Pending | API Server已经创建该Pod,等待调度器调度 |
ContainerCreating | 拉取镜像启动容器中 |
Running | Pod内容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态 |
Succeeded|Completed | Pod内所有容器均已成功执行退出,且不再重启 |
Failed|Error | Pod内所有容器均已退出,但至少有一个容器退出为失败状态 |
CrashLoopBackOff | Pod内有容器启动失败,比如配置文件丢失导致主进程启动失败 |
Unknown | 由于某种原因无法获取该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-sto p钩子
3. Pod操作总结
小结:
- 实现k8s平台与特定的容器运行时解耦,提供更加灵活的业务部署方式,引入了 Pod 概念
- k8s使用 yaml 格式定义资源文件,yaml 中 Map 与 List 的语法,与 json 做类比
- 通过 kubectl apply| get | exec | logs | delete 等操作 k8s 资源,必须指定 namespace
- 每启动一个 Pod,为了实现网络空间共享,会先创建 Infra 容器,并把其他容器网络加入该容器
- 通过 livenessProbe 和 readinessProbe 实现 Pod 的存活性和就绪健康检查
- 通过 requests 和 limit 分别限定容器初始资源申请与最高上限资源申请
- Pod 通过 initContainer 和 lifecycle 分别来执行初始化、pod 启动和删除时候的操作,使得功能更加全面和灵活
- 编写 yaml 讲究方法,学习 k8s,养成从官方网站查询知识的习惯
做了哪些工作:
- 定义
Pod.yaml
,将 myblog 和 mysql 打包在同一个 Pod 中,使用 myblog 使用 localhost 访问 mysql - mysql 数据持久化,为 myblog 业务应用添加了健康检查和资源限制
- 将 myblog 与 mysql 拆分,使用独立的 Pod 管理
- yaml 文件中的环境变量存在账号密码明文等敏感信息,使用 configMap 和 Secret 来统一配置,优化部署
只使用 Pod,面临的问题:
- 业务应用启动多个副本
- Pod 重建后 IP 会变化,外部如何访问 Pod 服务
- 运行业务 Pod 的某个节点挂了,可以自动帮我把 Pod 转移到集群中的可用节点启动起来
- 我的业务应用功能是收集节点监控数据,需要把 Pod 运行在 k8s 集群的各个节点上
更多推荐
所有评论(0)