k8s の Pod
一、k8s 中的资源和组件
- 组件是为了支撑
k8s平台的运行，而提前安装好的软件 - 资源是如何去使用
k8s能力的定义，比如k8s使用pod去管理业务应用，那么pod就是k8s的一类资源。
先要查看 k8s 下的所有的资源，可以使用如下命令
kubectl api-resources
kubectl api-resources -owide # 更详细命令
组件运行的位置
kubelet运行在宿主机上，而其他常用组件则运行在docker中；- 运行在
宿主机上的组件，可直接使用systemd查看，例如:systemctl status kubelet.service - 运行在
docker中的组件，可以直接通过docker查看，例如：docker ps |grep proxy,查询结果如下：
- 如果使用系统命令，查看
docker服务的日志(注意是 docker服务，而不是docker中的进程)。可以使用如下命令查看
journalctl -fu docker.service -o cat
其中 -f 表示跟踪服务器实时输出，-u 指定服务名称，-o 指定输出文件格式，使用 cat 输出时，可以让日志带颜色
二、Pod
为什么要引入 pod
- 与容器引擎解耦，例如：docker, crio, containerd and isula
- 多容器之间共享
网络、存储、进程空间，支持的业务场景也更加的灵活。
api-versions
api version 是一个成熟度的体现
| apiversion | |
|---|---|
| alpha | 进入 Kubernetes 的新功能的早期候选版本。这些可能包含错误，并且不保证将来可以使用。 |
| beta | API 版本名称中的 beta 表示测试已经超过了 alpha 级别，并且该功能最终将包含在 Kubernetes 中。 虽然它的工作方式可能会改变，并且对象的定义方式可能会完全改变， |
| stable | 稳定的 apiVersion 这些名称中不包含 alpha 或 beta。 它们可以安全使用。 |
| v1 | 这是 Kubernetes API 的第一个稳定版本。 它包含许多核心对象。 |
| apps/v1 | 使用最广泛的版本 |
查看 k8s 集群的版本信息
使用命令 kubectl version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.10", GitCommit:"7e54d50d3012cf3389e43b096ba35300f36e0817", GitTreeState:"clean", BuildDate:"2022-08-17T18:32:54Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.10", GitCommit:"7e54d50d3012cf3389e43b096ba35300f36e0817", GitTreeState:"clean", BuildDate:"2022-08-17T18:26:59Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"linux/amd64"}
其中 Client Version 表示 kubectl的版本；Server Version 表示 k8s 集群的版本。
pod 的资源清单
用来定义生成 pod 的 yaml 文件，叫做资源清单。如下是一个用于生成 nginx的资源清单
apiVersion: v1
kind: Pod
metadata:
name: nginxpod
namespace: zdp
labels:
component: nginxpodtstlab
spec:
containers:
- image: nginx:latest
name: nginxcon
ports:
- containerPort: 80
protocol: TCP
如果不知道 pod 怎么写，可以使用 kubectl explain pod 命令，查看对应的解释
使用 资源清单创建pod
1.创建 zdp 命名空间
kubectl create ns zdp
2.查看是否创建成功 kubectl get ns
3.通过文件，创建 pod容器
# 使用 create 创建，如果资源已存在，会报错，一般用于创建资源
kubectl create -f ./nginx.yaml
# 使用 apply 创建，如果资源已存在，会更新；一般用于创建或更新资源
kubectl apply -f ./nginx.yaml
4.在对应命名空间下，看一下容器状态
kubectl get pods -owide -n zdp
5.直接更具 pod 的 ip 地址进行访问
curl 10.233.83.25
6.删除该pod
kubectl delete -f ./nginx.yaml
7.查看 pod 的详细信息
kubectl get pods nginxtestpod -n zdp -oyaml # 使用 yaml 格式，查看 pod 的详细信息
kubectl get pods nginxtestpod -n zdp -ojson # 使用 pod 格式，查看 pod 的详细信息
这种方法，一般用于创建一个新容器时，可以直接从其它已有的pod，直接复制一个过来，具体命令 kubectl get pods nginxtestpod -n zdp -ojson > demo.yaml
通过查看 yaml 输出的文件格式，可以看出比我们自定义的 yaml 多很多参数，这都是 k8s 默认帮我们设置的。
8. 查看 pod 的详细信息与事件
kubectl describe pods nginxtestpod -n zdp
使用 describe比 -oyaml，查出来的结果中会多包含一个 Events事件，用于记录pod启动时的一些事件。
从 docker 层面查看 pod
1.使用 grep 从文档中过滤关键字
grep -i -C 2 "sp" nginx.yaml
2. 使用 docker ps |grep nginx 查看docker创建的对应容器
e167a25b54af nginx "/docker-entrypoint.…" 10 minutes ago Up 10 minutes k8s_nginxzdp_nginxtestpod_zdp_2445f594-149a-4e75-9ce0-5c5f092328c1_0
0161b73be464 registry.cn-beijing.aliyuncs.com/kubesphereio/pause:3.6 "/pause" 10 minutes ago Up 10 minutes k8s_POD_nginxtestpod_zdp_2445f594-149a-4e75-9ce0-5c5f092328c1_0
- 观察可看出，创建容器时，会先创建一个关键字为
pause的容器作为pod的基础，这是由于docker中有一种--net=container的网络模式，可以共享网络空间，k8s正是采用这种网络模式，启动一个容器先占用一个网络空间，而后其他的服务通过--net=container的方式与它连接。 - 观察可以看出 docker 容器的命名规范，使用 k8s 创建的 dcoker，命名规则为
k8s_容器名称_pod名称_命名空间_pod的UUID
静态的 pod
- 打开如下路径，看到三个用于启动
pod的资源清单。 - 该目录下的
pod均为静态pod，当k8s启动时，该目录下的pod将自动创建，即使被删除，k8s也会将自动重新创建。
/etc/kubernetes/manifests
├── kube-apiserver.yaml
├── kube-controller-manager.yaml
└── kube-scheduler.yaml
目录挂载
k8s的目录挂载，与直接使用docker进行一对一的目录挂载不同。由于同一个 pod 中的一个host文件，可能映射多个容器。
apiVersion: v1
kind: Pod
metadata:
name: nginxpod
namespace: zdp
labels:
component: nginxpodtstlab
spec:
volumes: # 目录挂载，应该和 containers同级
- name: my-etc # 挂载目录自定义名称
hostPath:
path: /opt/text.txt
containers:
- image: nginx:latest
name: nginxcon
ports:
- containerPort: 80
protocol: TCP
volumeMounts:
- name: my-etc # 与上面的自定义名称相对应
mountPath: /opt/text/text.txt
节点选择器
当创建 pod时，比如 mysql类型的容器，尽量运行在磁盘较大的机器上，nginx类的代理机器，尽量放在网卡吞吐较大的机器上。
apiVersion: v1
kind: Pod
metadata:
name: nginxpod
namespace: zdp
labels:
component: nginxpodtstlab
spec:
volumes:
- name: my-etc
hostPath:
path: /opt/text.txt
nodeSelector:
component: fast_eth
containers:
- image: nginx:latest
name: nginxcon
ports:
- containerPort: 80
protocol: TCP
volumeMounts:
- name: my-etc
mountPath: /opt/text/text.txt
如上的 资源清单 中，声明了 component: fast_eth，表示应该放在网卡吞吐量较大的 node 节点上
查看所有节点的lables
kubectl get nodes --show-labels
给已有节点，添加 lables
kubectl label nodes peng component=fast_eth
再次查看 node 的 labels
查看 pod状态为 runing，由此可见，k8s 的这种 wait-list模式的优势，即当 pod调度失败后，调度器会一直调度他，直到成功运行为止。
