KUbernets实践之pod

Published on Apr 16, 2020 with 0 views and 0 comments

# Linux # kubernets

一、组件和资源

核心组件

doge

ETCD：分布式高性能键值数据库,存储整个集群的所有元数据
ApiServer: API 服务器,集群资源访问控制入口,提供 restAPI 及安全访问控制
Scheduler：调度器,负责把业务容器调度到最合适的 Node 节点
Controller Manager：控制器管理,确保集群资源按照期望的方式运行
- Replication Controller
- Node controller
- ResourceQuota Controller
- Namespace Controller
- ServiceAccount Controller
- Tocken Controller
- Service Controller
- Endpoints Controller
kubelet：运行在每运行在每个节点上的主要的“节点代理”个节点上的主要的“节点代理”
- pod 管理：kubelet 定期从所监听的数据源获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。
- 容器健康检查：kubelet 创建了容器之后还要查看容器是否正常运行，如果容器运行出错，就要根据 pod 设置的重启策略进行处理.
- 容器监控：kubelet 会监控所在节点的资源使用情况，并定时向 master 报告，资源使用数据都是通过 cAdvisor 获取的。知道整个集群所有节点的资源情况，对于 pod 的调度和正常运行至关重要
kubectl: 命令行接口，用于对 Kubernetes 集群运行命令 https://kubernetes.io/zh/docs/reference/kubectl/
CNI 实现: 通用网络接口, 我们使用 flannel 来作为 k8s 集群的网络插件, 实现跨节点通信

工作流程

用户准备一个资源文件（记录了业务应用的名称、镜像地址等信息），通过调用 APIServer 执行创建 Pod
APIServer 收到用户的 Pod 创建请求，将 Pod 信息写入到 etcd 中
调度器通过 list-watch 的方式，发现有新的 pod 数据，但是这个 pod 还没有绑定到某一个节点中
调度器通过调度算法，计算出最适合该 pod 运行的节点，并调用 APIServer，把信息更新到 etcd 中
kubelet 同样通过 list-watch 方式，发现有新的 pod 调度到本机的节点了，因此调用容器运行时，去根据 pod 的描述信息，拉取镜像，启动容器，同时生成事件信息
同时，把容器的信息、事件及状态也通过 APIServer 写入到 etcd 中

简述

集群中的所有资源可以提供如下方式查看：
kubectl api-resources

命名空间，集群内一个虚拟的概念，类似于资源池的概念，一个池子里可以有各种资源类型，绝大多数的资源都必须属于某一个 namespace。集群初始化安装好之后，会默认有如下几个 namespace：

[root@k8s-master ~]# kubectl get namespaces
NAME                   STATUS   AGE
default                Active   22h
kube-node-lease        Active   22h
kube-public            Active   22h
kube-system            Active   22h
kubernetes-dashboard   Active   21h

所有 NAMESPACED 的资源，在创建的时候都需要指定 namespace，若不指定，默认会在 default 命名空间下
相同 namespace 下的同类资源不可以重名，不同类型的资源可以重名
不同 namespace 下的同类资源可以重名
通常在项目使用的时候，我们会创建带有业务含义的 namespace 来做逻辑上的整合

kubectl 的使用

$ kubectl -h
$ kubectl get -h
$ kubectl create -h
$ kubectl create namespace -h

kubectl 如何管理集群资源
kubectl get po -v=7

使用 k8s 管理业务应用

为什么引入 pod

与容器引擎解耦
Docker、Rkt。平台设计与引擎的具体的实现解耦
多容器共享网络 | 存储 | 进程空间, 支持的业务场景更加灵活

使用 YAML 格式定义 Pod

apiVersion: v1
kind: Pod
metadata:
  name: myblog
  namespace: demo
  labels:
    component: myblog
spec:
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    env:
    - name: MYSQL_HOST   #  指定root用户的用户名
      value: "127.0.0.1"
    - name: MYSQL_PASSWD
      value: "123456"
    ports:
    - containerPort: 8002
  - name: mysql
    image: 192.168.51.209:5000/mysql:5.7-utf8
    ports:
    - containerPort: 3306
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123456"
    - name: MYSQL_DATABASE
      value: "myblog"

apiVersion	含义
alpha	进入 K8s 功能的早期候选版本，可能包含 Bug，最终不一定进入 K8s
beta	已经过测试的版本，最终会进入 K8s，但功能、对象定义可能会发生变更。
stable	可安全使用的稳定版本
v1	stable 版本之后的首个版本，包含了更多的核心对象
apps/v1	使用最广泛的版本，像 Deployment、ReplicaSets 都已进入该版本

资源类型与 apiVersion 对照表

快速获得资源和版本

$ kubectl explain pod
$ kubectl explain Pod.apiVersion

创建和访问 pod

创建 namespace, namespace 是逻辑上的资源池
kubectl create namespace demo
使用指定文件创建 Pod
kubectl create -f demo-pod.yaml

查看 pod，可以简写 po
所有的操作都需要指定 namespace，如果是在 default 命名空间下，则可以省略

[root@k8s-master myblog]# kubectl -n demo get pods -o wide 
NAME     READY   STATUS    RESTARTS   AGE     IP           NODE         NOMINATED NODE   READINESS GATES
myblog   2/2     Running   0          2m12s   10.244.1.6   k8s-slave1   <none>           <none>

进入容器,执行初始化, 不必到对应的主机执行 docker exec

[root@k8s-master myblog]#  kubectl -n demo exec -ti myblog -c myblog bash
[root@myblog myblog]# env
[root@myblog myblog]# python3 manage.py migrate

[root@k8s-master myblog]#  kubectl -n demo exec -ti myblog -c mysql bash
root@myblog:/# mysql -p123456

Infra 容器

登录 k8s-slave1 节点
##其中包含 MySQL 和 myblog 程序以及 Infra 容器
##为了实现 Pod 内部的容器可以通过 localhost 通信，每个 Pod 都会启动 Infra 容器，然后 Pod 内部的其他容器的网络空间会共享该 Infra 容器的网络空间(Docker 网络的 container 模式)，Infra 容器只需要 hang 住网络空间，不需要额外的功能，因此资源消耗极低。

登录 master 节点，查看 pod 内部的容器 ip 均相同，为 pod ip

[root@k8s-master myblog]# kubectl -n demo exec -ti myblog -c myblog bash
[root@myblog myblog]# ifconfig

pod 容器命名: k8s_<container_name>_<pod_name>_<namespace>_<random_string>

查看 pod 详细信息

查看 pod 调度节点及 pod_ip
$ kubectl -n demo get pods -o wide
查看完整的 YAML
$ kubectl -n demo get po myblog -o yaml
查看 pod 的明细信息及事件
$ kubectl -n demo describe pod myblog

Troubleshooting and Debugging
进入 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 定点

apiVersion: v1
kind: Pod
metadata:
  name: myblog
  namespace: demo
  labels:
    component: myblog
spec:
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    env:
    - name: MYSQL_HOST   #  指定root用户的用户名
      value: "127.0.0.1"
    - name: MYSQL_PASSWD
      value: "123456"
    ports:
    - containerPort: 8002
  - name: mysql
    image: 192.168.51.209:5000/mysql:5.7-utf8
    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 demo delete pod myblog

创建

[root@k8s-master one-pod]# kubectl create -f pod-with-volume.yaml
pod/myblog created

此时：此时 pod 状态 Pending

[root@k8s-master one-pod]# kubectl -n demo get pods 
NAME     READY   STATUS    RESTARTS   AGE
myblog   0/2     Pending   0          43s

查看原因，提示调度失败，因为节点不满足 node selector

[root@k8s-master myblog]# kubectl -n demo describe pod myblog
...
Events:
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 node(s) didn't match node selector.
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 node(s) didn't match node selector.

为节点打标签

[root@k8s-master myblog]# kubectl label node k8s-slave1 component=mysql
node/k8s-slave1 labeled

再次查看，已经运行成功

[root@k8s-master myblog]# kubectl -n demo get po
NAME     READY   STATUS    RESTARTS   AGE
myblog   2/2     Running   0          4m51s

到 k8s-slave1 节点，查看/opt/mysql/data

[root@k8s-slave1 ~]# ll /data/mysql/data/
total 188484
-rw-r-----. 1 polkitd input       56 Apr 18 06:15 auto.cnf
-rw-------. 1 polkitd input     1676 Apr 18 06:15 ca-key.pem
-rw-r--r--. 1 polkitd input     1112 Apr 18 06:15 ca.pem
-rw-r--r--. 1 polkitd input     1112 Apr 18 06:15 client-cert.pem
-rw-------. 1 polkitd input     1680 Apr 18 06:15 client-key.pem
-rw-r-----. 1 polkitd input     1346 Apr 18 06:16 ib_buffer_pool
-rw-r-----. 1 polkitd input 79691776 Apr 18 06:16 ibdata1
-rw-r-----. 1 polkitd input 50331648 Apr 18 06:16 ib_logfile0
-rw-r-----. 1 polkitd input 50331648 Apr 18 06:15 ib_logfile1
-rw-r-----. 1 polkitd input 12582912 Apr 18 06:16 ibtmp1
drwxr-x---. 2 polkitd input       20 Apr 18 06:16 myblog
drwxr-x---. 2 polkitd input     4096 Apr 18 06:15 mysql
drwxr-x---. 2 polkitd input     8192 Apr 18 06:15 performance_schema
-rw-------. 1 polkitd input     1676 Apr 18 06:15 private_key.pem
-rw-r--r--. 1 polkitd input      452 Apr 18 06:15 public_key.pem
-rw-r--r--. 1 polkitd input     1112 Apr 18 06:15 server-cert.pem
-rw-------. 1 polkitd input     1680 Apr 18 06:15 server-key.pem
drwxr-x---. 2 polkitd input     8192 Apr 18 06:15 sys

执行 migrate，创建数据库表，然后删掉 pod，再次创建后验证数据是否存在
kubectl -n demo exec -ti myblog python3 manage.py migrate
测试一下服务是否正常

[root@k8s-master ~]# kubectl -n demo get po -o wide
NAME     READY   STATUS    RESTARTS   AGE    IP           NODE         NOMINATED NODE   READINESS GATES
myblog   2/2     Running   0          7m6s   10.244.1.7   k8s-slave1   <none>           <none>

删除 pod 再创建

[root@k8s-master myblog]# kubectl delete -f pod-with-volume.yaml
pod "myblog" deleted
[root@k8s-master myblog]# 
[root@k8s-master myblog]# kubectl create -f pod-with-volume.yaml
pod/myblog created

查看 pod ip 并访问服务*

[root@k8s-master myblog]# kubectl -n demo get po -o wide
NAME     READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
myblog   2/2     Running   0          34s   10.244.1.8   k8s-slave1   <none>           <none>

测试一次啊：
[root@k8s-master myblog]# curl 10.244.1.8:8002/myblog/index

使用 PV+PVC 连接分布式存储解决方案
ceph
glusterfs
nfs

服务健康检查

检测容器服务是否健康的手段，若不健康，会根据设置的重启策略（restartPolicy）进行操作，两种检测机制可以分别单独设置，若不设置，默认认为 Pod 是健康的。

两种机制：

LivenessProbe 探针
用于判断容器是否存活，即 Pod 是否为 running 状态，如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将 kill 掉容器，并根据容器的重启策略是否重启，如果一个容器不包含 LivenessProbe 探针，则 Kubelet 认为容器的 LivenessProbe 探针的返回值永远成功。
ReadinessProbe 探针
用于判断容器是否正常提供服务，即容器的 Ready 是否为 True，是否可以接收请求，如果 ReadinessProbe 探测失败，则容器的 Ready 将为 False，控制器将此 Pod 的 Endpoint 从对应的 service 的 Endpoint 列表中移除，从此不再将任何请求调度此 Pod 上，直到下次探测成功。（剔除此 pod 不参与接收请求不会将流量转发给此 Pod）。

三种类型：

exec：通过执行命令来检查服务是否正常，回值为 0 则表示容器健康
httpGet 方式：通过发送 http 请求检查服务是否正常，返回 200-399 状态码则表明容器健康
tcpSocket：通过容器的 IP 和 Port 执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康

示例：

apiVersion: v1
kind: Pod
metadata:
  name: myblog
  namespace: demo
  labels:
    component: myblog
spec:
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    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: 15 	# 执行探测的频率
      timeoutSeconds: 2		# 探测超时时间
    readinessProbe: 
      httpGet: 
        path: /blog/index/
        port: 8002
        scheme: HTTP
      initialDelaySeconds: 10 
      timeoutSeconds: 2
      periodSeconds: 15
  - name: mysql
    image: 192.168.51.209:5000/mysql:5.7-utf8
    ports:
    - containerPort: 3306
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123456"
    - name: MYSQL_DATABASE
      value: "myblog"
    readinessProbe:
      tcpSocket:
        port: 3306
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 3306
      initialDelaySeconds: 15
      periodSeconds: 20
    volumeMounts:
    - name: mysql-data
      mountPath: /var/lib/mysql

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。
periodSeconds：执行探测的频率。默认是 10 秒，最小 1 秒。
timeoutSeconds：探测超时时间。默认 1 秒，最小 1 秒。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1，最小值是 1。
failureThreshold：探测成功后，最少连续探测失败多少次
才被认定为失败。默认是 3，最小值是 1。

重启策略：

Pod 的重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 RestartPolicy 的设置来进行相应的操作。
Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。

Always：当容器失败时，由 kubelet 自动重启该容器；
OnFailure：当容器终止运行且退出码不为 0 时，有 kubelet 自动重启该容器；
Never：不论容器运行状态如何，kubelet 都不会重启该容器。

镜像拉取策略

spec:
  containers:
  - name: myblog
    image: 192.168.51.209:5000/demo/myblog
    imagePullPolicy: IfNotPresent

设置镜像的拉取策略，默认为 IfNotPresent

Always，总是拉取镜像，即使本地有镜像也从仓库拉取
IfNotPresent ，本地有则使用本地镜像，本地没有则去仓库拉取
Never，只使用本地镜像，本地没有则报错

Pod 资源限制

为了保证充分利用集群资源，且确保重要容器在运行周期内能够分配到足够的资源稳定运行，因此平台需要具备

Pod 的资源限制的能力。对于一个 pod 来说，资源最基础的 2 个的指标就是：CPU 和内存。

Kubernetes 提供了个采用 requests 和 limits 两种类型参数对资源进行预分配和使用限制。

apiVersion: v1
kind: Pod
metadata:
  name: myblog
  namespace: demo
  labels:
    component: myblog
spec:
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    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: 192.168.51.209:5000/mysql:5.7-utf8
    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

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 资源的单位换算：

1 CPU = 1000 millicpu（1 Core = 1000m）这里的 m 就是毫、毫核的意思，Kubernetes 集群中的每一个节点可以通过操作系统的命令来确认本节点的 CPU 内核数量，然后将这个数量乘以 1000，得到的就是节点总 CPU 总毫数。比如一个节点有四核，那么该节点的 CPU 总毫量为 4000m。

docker run 命令和 CPU 限制相关的所有选项如下：

选项	描述
`--cpuset-cpus=""`	允许使用的 CPU 集，值可以为 0-3,0,1
`-c`,`--cpu-shares=0`	CPU 共享权值（相对权重）
`cpu-period=0`	限制 CPU CFS 的周期，范围从 100ms~1s，即[1000, 1000000]
`--cpu-quota=0`	限制 CPU CFS 配额，必须不小于1ms，即 >= 1000，绝对限制

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: demo
  labels:
    component: myblog
spec:
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    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: 192.168.51.209:5000/mysql:5.7-utf8
    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
mysql.yaml 文件内容

apiVersion: v1
kind: Pod
metadata:
  name: mysql
  namespace: demo
  labels:
    component: mysql
spec:
  hostNetwork: true	# 声明pod的网络模式为host模式，效果通docker run --net=host
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: mysql
    image: 192.168.51.209:5000/mysql:5.7-utf8
    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: demo
  labels:
    component: myblog
spec:
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_HOST   #  指定root用户的用户名
      value: "192.168.51.209"
    - 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 demo delete po myblog
分别创建 MySQL 和 myblog

kubectl create -f mysql.yaml
kubectl create -f myblog.yaml

查看 pod，注意 mysqlIP 为宿主机 IP，因为网络模式为 host

[root@k8s-master two-pod]# kubectl -n demo get pods -o wide 
NAME     READY   STATUS    RESTARTS   AGE   IP               NODE         NOMINATED NODE   READINESS GATES
myblog   1/1     Running   0          26s   10.244.1.9       k8s-slave1   <none>           <none>
mysql    1/1     Running   0          33s   192.168.51.210   k8s-slave1   <none>           <none>

访问 myblog 服务正常

[root@k8s-master two-pod]# curl 10.244.1.9:8002/blog/index/
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>首页</title>
</head>
<body>
<h3>我的博客列表：</h3>
    
        <a href="/blog/article/1"> nihao </a>
        <br/>
    

    </br>
    </br>
    <a href=" /blog/article/edit/0 ">写博客</a>

</body>
</html>

解决问题二，环境变量中敏感信息带来的安全隐患

为什么要统一管理环境变量

环境变量中有很多敏感的信息，比如账号密码，直接暴漏在 YAML 文件中存在安全性问题
团队内部一般存在多个项目，这些项目直接存在配置相同环境变量的情况，因此可以统一维护管理
对于开发、测试、生产环境，由于配置均不同，每套环境部署的时候都要修改 YAML，带来额外的开销

k8s 提供两类资源，configMap 和 Secret，可以用来实现业务配置的统一管理，允许将配置文件与镜像文件分离，以使容器化的应用程序具有可移植性。

configMap，通常用来管理应用的配置文件或者环境变量，myblog/two-pod/configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: myblog
  namespace: demo
data:
  MYSQL_HOST: "192.168.51.209"
  MYSQL_PORT: "3306"

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 的认证信息。

apiVersion: v1
kind: Secret
metadata:
  name: myblog
  namespace: demo
type: Opaque
data:
  MYSQL_USER: cm9vdA==  #注意加-n参数， echo -n root|base64
  MYSQL_PASSWD: MTIzNDU2

创建并查看：

[root@k8s-master two-pod]# kubectl create -f secret.yaml 
secret/myblog created
[root@k8s-master two-pod]# kubectl -n demo get secret 
NAME                  TYPE                                  DATA   AGE
default-token-cv8ks   kubernetes.io/service-account-token   3      103m
myblog                Opaque                                2      28s

如果不习惯这种方式，可以通过如下方式：

[root@k8s-master two-pod]# cat secret.txt 
MYSQL_USER=root
MYSQL_PASSWD=123456

kubectl -n demo create secret generic myblog --from-env-file=secret.txt

修改后的 MySQL 的 YAML 文件：

apiVersion: v1
kind: Pod
metadata:
  name: mysql
  namespace: demo
  labels:
    component: mysql
spec:
  hostNetwork: true	# 声明pod的网络模式为host模式，效果通docker run --net=host
  volumes: 
  - name: mysql-data
    hostPath: 
      path: /data/mysql/data
  nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
    component: mysql
  containers:
  - name: mysql
    image: 192.168.51.209:5000/mysql:5.7-utf8
    ports:
    - containerPort: 3306
    env:
    - name: MYSQL_USER
      valueFrom:
        secretKeyRef:
          name: myblog
          key: MYSQL_USER
    - name: MYSQL_PASSWD
      valueFrom:
        secretKeyRef:
          name: myblog
          key: MYSQL_PASSWD
    - 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: demo
  labels:
    component: myblog
spec:
  containers:
  - name: myblog
    image: 192.168.51.209:5000/myblog
    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 不会自动更新，重建后方可更新。
configmap 文件

apiVersion: v1
kind: ConfigMap
metadata:
  name: myblog
  namespace: demo
data:
  MYSQL_HOST: "192.168.51.209"
  MYSQL_PORT: "3306"

如何编写资源 YAML

从机器中已有的资源中拿
kubectl -n kube-system get po,deployment,ds
kubectl -n demo get pod mysql -o yaml
学会在官网查找， https://kubernetes.io/docs/home/
从 kubernetes-api 文档中查找， https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#pod-v1-core
kubectl explain 查看具体字段含义

pod 状态与生命周期

生命周期示意图：

启动和关闭示意：

apiVersion: v1
kind: Pod
metadata:
  name: demo-start-stop
  namespace: demo
  labels:
    component: demo-start-stop
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 测试：

[root@k8s-master myblog]# kubectl create -f demo-pod-start.yaml

查看 demo 状态
kubectl -n demo get po -o wide -w

查看调度节点的/tmp/loap/timing
cat /tmp/loap/timing

小节：

实现 k8s 平台与特定的容器运行时解耦，提供更加灵活的业务部署方式，引入了 Pod 概念
k8s 使用 YAML 格式定义资源文件，YAML 中 Map 与 List 的语法，与 JSON 做类比
通过 kubectl create | get | exec | logs | delete 等操作 k8s 资源，必须指定 namespace
每启动一个 Pod，为了实现网络空间共享，会先创建 Infra 容器，并把其他容器网络加入该容器
通过 livenessProbe 和 readinessProbe 实现 Pod 的存活性和就绪健康检查
通过 requests 和 limit 分别限定容器初始资源申请与最高上限资源申请
通过 Pod IP 访问具体的 Pod 服务

标题：KUbernets实践之pod
作者：cuijianzhe
地址：https://cjzshilong.cn/articles/2020/04/16/1587015956420.html

一、组件和资源
核心组件
工作流程
简述
kubectl 的使用
使用 k8s 管理业务应用
使用 YAML 格式定义 Pod
创建和访问 pod
Infra 容器
查看 pod 详细信息
更新服务版本
Pod 数据持久化
创建
服务健康检查
镜像拉取策略
Pod 资源限制
YAML 优化
如何编写资源 YAML
pod 状态与生命周期
小节：

Share WeiBo Twitter QZone WeChat ← → ↑ ↓