【Kubernetes】Job、Volume、PV、Namespace、Annotation、ConfigMap

# Job
批处理任务通常并行（或者串行）启动多个计算机进程去处理一批工作项（work item），在处理完成后，整个批处理任务结束。

Kubernetes 支持批处理类型的应用，可以通过 Kubernetes Job 这种新的资源对象定义并启动一个 批处理任务 Job。

与 RC、Deployment、RS、DaemonSet 类似，Job 也控制一组 Pod 容器。Job 也是一种特殊的 Pod 副本自动控制器，同时 Job 控制 Pod 副本与 RC 等控制器工作机制有以下差别

## Job 控制的 Pod 副本是短暂运行的
可以将 Job 视为一组 Docker 容器，其中的每个 Docker 容器都仅仅运行一次，当 Job 控制的所有 Pod 副本都运行结束时，对应的Job 也就结束了。

Job 生成的 Pod 副本是不能自动重启的，对应 Pod 副本的 RestartPoliy 都被设置为 `Never`

当对应 Pod 副本都执行完时，相应的 Job 也就完成了控制使命，即 Job 生成的 Pod 在 Kubernetes 中是短暂存在的。

### 定时任务 CronJob
在 1.5 版本之后，提供了类似 crontab 的定时任务，CronJob，解决了某些批处理任务需要定时反复执行的问题。

## Job 控制的 Pod 副本的工作模式能够多实例并行计算
如 TensorFlow 框架，可以将一个机器学习的计算任务分布到 10 台机器上，在每台机器上都运行一个 worker 执行计算任务。

## Job 的常见使用场景
- 数据处理 / 迁移
- 批量计算
- CI/CD 流水线任务
- 一次性初始化工作
- 数据库架构更新

# Volume 存储卷
Volume 是 Pod 中能够被多个容器访问的共享目录。

Kubernetes 中的 Volume 被定义在 Pod 上，然后被一个 Pod 里的多个容器挂载到具体的文件目录下；
Kubernetes 中的 Volume 与 Pod 的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume 中的数据也不会丢失；
Kubernetes 支持多种类型的 Volume，如 GlusterFS、Ceph 等分布式文件系统。

## Volume 的使用
现在 Pod 上生命一个 Volume，然后再容器里引用该 Volume 并挂载（Mount）到容器里的某个目录上。

## Volume 实践
给之前的 Tomcat Pod 增加一个名为 datavol 的Volume，并且挂载到容器的 `/mydata-data/` 目录上。
可以追溯到之前创建 tomcat 的 deployment 配置文件是 tomcat-deployment.yaml ，使用 vim 进入配置文件编辑如下内容：
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
        name: frontend
spec:
        replicas: 1
        selector:
                matchLabels:
                        tier: frontend
        template:
                metadata:
                        labels:
                                app: app-demo
                                tier: frontend
                spec:
                        containers:
                        - name: tomcat-demo
                          image: kubeguide/tomcat-app:v1
                          imagePullPolicy: IfNotPresent
                          ports:
                          - containerPort: 8080
                          resources:
                                  requests:
                                          cpu: "200m"
                                          memory: "256Mi"
                                  limits:
                                          cpu: "500m"
                                          memory: "512Mi"
                          volumeMounts: # volumeMounts 在 container 层级下
                          - name: datavol
                            mountPath: /mydata-data
                        volumes: # volumes 在 spec 层级下，跟 containers 同级
                        - name: datavol
                          emptyDir: {}
```

更新deployment 
```bash
kubectl apply -f tomcat-deployment.yaml
```
配置文件解析：
- 在容器配置中添加了 `volumeMounts` 部分，指定挂载点
- 在 Pod 规格中添加了 `volumes` 部分，定义了一个 `emptyDir` 类型的卷。
	- 这是一个临时存储，Pod 删除后数据会丢失，如果需要持久化存储，可以考虑使用 PersistentVolumeClaim（PVC） 和 PersistentVolume（PV）

## Volume 类型
### emptyDir
一个 `emptyDir Volume` 是在 Pod 分配到 Node 时创建的，初始内容为空，并且无需指定宿主机上对应的目录文件，因为这个是 Kubernetes 自动分配的一个目录，当 Pod 从 Node 上移除时，emptyDir 中的数据也会被永久删除。用途如下：
- 临时空间，用于某些应用程序运行时所需要的临时目录，且无须永久保留
- 长时间任务的中间过程 CheckPoint 的临时保存目录
- 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

用户无法控制 emptyDir 使用的介质种类。如果 kubelet 的配置是使用硬盘，那么所有 emptyDir 都会被创建在该硬盘上。

### hostPath
`hostPath` 为在 Pod 上`挂载宿主机`上的文件或目录，通常用于以下方面：
- 容器应用程序生成的日志文件需要永久保存时，可以用宿主机的高速文件系统进行存储
- 需要访问宿主机上 Docker 引擎内部数据结构的容器应用时，可以通过定义 hostPath 为宿主机 `/var/lib/docker` 目录，使容器内部应用可以直接访问 Docker 的文件系统
需要注意的是：
- 在不同的 Node 上具有相同配置的 Pod，可能会因为宿主机上的目录和文件不同而导致对 Volume 上目录和文件的访问结果不一致
- 如果使用了资源配额管理，则 Kubernetes 无法将 hostPath 在宿主机上使用的资源纳入管理

可以通过如下方式定义：(使用宿主机的 `/data` 目录定义了一个 hostPath 类型的 Volume
```yaml
volumes: 
- name: "persistent-storage" 
  hostPath: 
	path: "/data"
```

### gcePersistentDisk
使用 gcePersistentDisk 表示使用谷歌公有云提供的永久磁盘（`Persisten Disk，PD`）存放 Volume 的数据。
PD 上的内容会被永久保存，当 Pod 被删除时，PD 只是被卸载（Unomunt），但不会被删除。

！！需要先创建一个 PD，才能使用 gcePersistentDisk

限制条件：
- Node （运行 kubelet 的节点）需要是 GCE 虚拟机
- 这些虚拟机需要与 PD 存在于相同的 GCE 项目和 Zone 中。

### awsElasticBlockStore
GCE 类似，该类型的 Volume 使用亚马逊公有云提供的 EBS Volume 存储数据，需要先创建一个EBS Volume 才能使用 awsElasticBlockStore。

### NFS
使用 NFS 网络文件系统提供的共享目录存储数据时，我们需要在系统中部署一个 NFS Server。
```yaml
volumes: 
- name: nfs 
  nfs: 
  # 改为你的NFS服务器地址 
  server: nfs-server.localhost 
  path: "/"
```

### 其他类型
- iSCSI：使用 iSCSI 存储设备上的目录挂载到 Pod 中
- Flocker：使用 Flocker 管理存储卷
- rbd：使用 Ceph 块设备共享存储（Rados Block Device）挂载到 Pod 中
- gitRepo：通过挂载一个空目录，并从 Git 库 clone 一个 git repository 以供 Pod 使用
- secret：一个 Secret Volume 用于为 Pod 提供加密的信息，你可以将定义在 Kubernetes 中的 Secret 直接挂载为文件让 Pod 访问。Secret Volume 是通过 TMFS（内存文件系统）实现的，这种类型的 Volume 总是不会被持久化的

# Persistent Volume
Volume 是被定义在 Pod 上的，属于计算资源的一部分。网络存储是相对独立于计算资源而存在的一种实体资源。
在使用虚拟机的情况下，通常会先定义一个网络存储，然后从中划出一个 “网盘” 并挂接到虚拟机上。
Persistent Volume（PV）和与之相关联的 Persistent Volume Claim（PVC） 也起到了类似的作用。

PV 可以被理解成 Kubernetes 集群中的某个网络存储对应的一块存储，与 Volume 类似，但有以下区别：
- PV 只能是网络存储，不属于任何 Node。但可以在每个 Node 上访问
- PV 并不是被定义在 Pod 上的，而是独立于 Pod 之外定义的
- PV 目前支持的类型包括：gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC（Fibre Channel）、Flocker、NFS、iSCSI、RBD（Rados Block Device）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath（仅供单机测试）

## PV 的声明方式
NFS 类型的 PV 的一个 YAML 定义文件，声明了需要 5Gi 的存储空间：
```yaml
apiVersion: v1 
kind: PersistentVolume 
metadata: 
	name: pv0003 
spec: 
	capacity: 
		storage: 5Gi 
		accessModes: 
		- ReadWriteOnce 
		nfs: 
			path: /somepath 
			server: 172.17.0.2
```

## PV 的 accessModes 属性
- `ReadWriteOnce`：读写权限，并且只能被单个 Node 挂载
- `ReadOnlyMany`：只读权限，允许被多个 Node 挂载
- `ReadWriteMany`：读写权限，允许被多个 Node 挂载

如果某个 Pod 想申请某种类型的 PV，则首先需要定义一个 PersistentVolumeClaim 对象：
```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
	name: myclaim
spec:
	accessModes:
		- ReadWriteOnce
	resources:
		requests:
			storage: 8Gi
```
然后在 Pod 的 Volume 定义中引用上述 PVC 即可：
```yaml
volumes:
	- name: mypod
	  persistentVolumeClaim:
	  claimName: myclaim
```

## PV 的状态
PV 是有状态的对象，状态有以下几种：
- Available：空闲状态
- Bound：已经绑定到某个 PVC 上
- Released：对应的 PVC 已经被删除，但资源还没有被集群收回
- Failed：PV 自动回收失败

# Namespace
Namespace 在很多情况下用于实现 `多租户` 的资源隔离。
Namespace 通过将集群内部的资源对象 “分配” 到不同的 Namespace 中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

Kubernetes 集群在启动后会创建一个名为 default 的 Namespace，查看方式：
```bash
kubectl get namespaces
```
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/10/t15kot.webp)

如果不特别指明 Namespace，则用户创建的 Pod、RC、Service 都将被系统创建到这个默认的 名为 `default` 的 Namespace 中。

## Namespace 定义方式
```yaml
apiVersion: v1
kind: Namespace
metadata:
	name: development
```

一旦创建了 Namespace，在创建资源对象时就可以指定这个资源对象属于哪个 Namespace。

## Namespace 实践
创建 namespace
```bash
touch busybox-namespace.yaml
```
busybox-namespace.yaml 文件内容：
```yaml
apiVersion: v1
kind: Namespace
metadata:
	name: development
```
创建 busybox Pod 在这个 Namespace 中
```bash
touch busybox-pod.yaml
```

配置文件内容：
```yaml
apiVersion: v1
kind: Pod
metadata:
	name: busybox
	namespace: development # 指定 namespace
spec:
	containers:
	- name: busybox
	  image: dockerio.vkus1.skybyte.me/library/busybox
	  command:
	  - sleep
	  - "3600" # 让容器运行 1 小时
```
执行创建命令：
```bash
kubectl apply -f busybox-development.yaml
kubectl apply -f busybox-pod.yaml
```

如果此时只简单地执行 `kubectl get pods` 是看不到刚刚创建的 pod 的，因为这个命令默认只会显示 `default` namespace 的 pods。这个命令等同于 `kubectl get pods -n default`
如果想要显示指定 namespace 的 pods，则可以执行以下命令：
```bash
kubectl get pods --namespace=development
# 或
kubectl get pods -n development
```

![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/11/p263rg.webp)

如果执行以下命令，可以查看所有 namespace：
```bash
kubectl get pods --all-namespaces
# 或
kubectl get pods -A
```
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/11/p5pr7a.webp)

### 所有查看方式汇总

| 命令                                  | 显示范围                  | 输出示例                       |
| ----------------------------------- | --------------------- | -------------------------- |
| `kubectl get pods`                  | default namespace     | frontend-pod, mysql-pod... |
| `kubectl get pods -n development`   | development namespace | busybox                    |
| `kubectl get pods --all-namespaces` | 所有 namespaces         | 所有 pods                    |
当给每个租户创建一个 Namespace 来实现多租户的资源隔离时，还能组合 Kubernetes 的资源配额管理，限定不同租户能占用的资源，例如 CPU 使用量、内存使用量等。

# Annotation
Annotation：注解，与 Label 类似，也是用 key/value 键值对 的形式定义。
Annotation 是用户任意定义的附加信息，以便于外部工具查找。

通常来说会通过 Annotation 来记录以下信息：
- build 信息、release 信息、Docker 镜像信息等，eg. 时间戳、release id 号、PR 号、镜像 Hash 值、Docker Registry 地址等
- 日志库、监控库、分析库等资源库的地址信息
- 程序调试工具信息，eg. 工具名称、版本号等
- 团队的联系信息，eg, 电话号码、负责人名称、网址等

# ConfigMap
Docker 通过将 程序、依赖库、数据及配置文件 “打包固化” 到一个不变的镜像文件中的做法，解决了应用的部署的难题，但这同时带来了：配置文件中的参数在运行期如何修改 的问题。

我们不可以在启动 Docker 容器后 再修改容器里的配置文件，然后用新的配置文件重启容器里的用户主进程，所以 Docker 提供了两种方式：
- 在运行时通过容器的环境变量来传递参数
- 通过 Docker Volume 将容器外的配置文件映射到容器内

后一种方式更适合，因为大多数应用通常从一个或多个配置文件中读取参数。但使用这种方式的话，我们必须在目标主机上先创建好对应的配置文件，然后才能映射到容器里。

## Kubernetes 的解决方案
把所有的配置项都当作 `key-value` 字符串，当然 value 可以来自摸个文本文件，比如配置项 `password=123456`、`user=root`、`host=192.168.8.4` 等用于表示连接 FTP 服务器的配置参数。

这些配置项可以作为 Map 表中的一个项，整个 Map 的数据可以被持久化存储在 Kubernetes 的 Etcd 数据库中，然后提供 API 以方便 Kubernetes 相关组件或客户应用 CRUD 操作这些数据，这些专门用来保存配置参数的 Map 就是 Kubernetes ConfigMap 资源对象。

Kubernetes 提供一种内建机制，将存储在 etcd 中的 ConfigMap 通过 Volume 映射的方式变成目标 Pod 内的配置文件，不管目标 Pod 被调度到哪台服务器上，都会完成自动映射。

如果 ConfigMap 中的 key-value 数据被修改，则映射到 Pod 中的 “配置文件” 也会随之自动更新。

![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/11/po58eu.webp)
ConfigMap 特点：
- 可动态更新
- 明文存储
- namespace 隔离
- 容量限制

![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/11/pqi9e2.webp)

最佳实践：
![image](https://cdn-imagehost.xyzttt.xyz/image/2025/03/11/pro8af.webp)

# References
- claude 3.5 sonnet
- Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）