一、资源管理
1.概述
说到k8s中的pod，即荚的意思，就不得不先提到k8s中的资源管理，k8s中可以用以下命令查看我们的资源：
kubectl api-resources
比如我们现在需要使用k8s开启一个东西，那么k8s通过apiserver去对比etcd里面的数据，并且去调用scheduler来确定我这个东西要放在哪台主机上，还需要调用managecontroller(控制器)去控制pod开启的数量和时间，以及监控pod的状态
而我们的pod有Deployment,CronJob,DaemonSet,ReplicaSet,Job,StatefulSet,Hpa,通过我们的控制器开启pod，开启pod之后pod中的数据，即程序便运行起来了，程序运行了之后不能像docker一样通过暴露端口的方式直接被访问，还需要service（微服务），对端口进行暴露，最终我们通过service微服务来访问pod中的数据。而pod中的数据持久化是通过建立volume卷，再把pod中的目录挂载到宿主机上，这样pod中的数据就能持久化到宿主机上了。
2.资源管理方式
- 命令式对象管理：直接使用命令去操作kubernetes资源：
kubectl run nginx-pod --image=nginx:latest --port=80 - 命令式对象配置：通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yml - 声明式对象配置：通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yml类型 适用环境 优点 缺点 命令式对象管理 测试 简单 只能操作活动对象，无法审计、跟踪 命令式对象配置 开发 可以审计、跟踪 项目大时，配置文件多，操作麻烦 声明式对象配置 开发 支持目录操作 意外情况下难以调试 kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署
kubectl命令的语法如下:
kubectl [command] [type] [name] [flags]
- comand:指定要对资源执行的操作，例如create、get、delete
- type:指定资源类型，比如deployment、pod、service
- name:指定资源的名称，名称大小写敏感
- flags:指定额外的可选参数
查看所有pod
kubectl get pod查看某个pod
kubectl get pod pod_name查看某个pod,以yaml格式展示结果
kubectl get pod pod_name o yaml显示集群版本
kubectl version
显示集群信息
kubectl cluster-info 
创建一个webcluster控制器，控制器中pod数量为2
kubectl create deployment webcluster --image nginx/nginx:latest --replicas 2
查看资源帮助
kubectl explain deployment查看控制器参数帮助
kubectl explain deployment.spec编辑控制器配置
kubectl patch deployments.apps webcluster -p '{"spec": {"replicas":4}}'
删除资源
kubectl delete deployments.apps webcluster
运行和调试命令示例
运行pod
kubectl run testpod --image nginx/nginx:latest
端口暴露
kubectl run testpod --image nginx/nginx:latest
kubectl expose pod testpod --port 80 --target-port 80
查看资源详细信息
kubectl describe pods testpod查看资源日志
kubectl logs pods/testpod运行交互pod
ctrl+pq退出不停止pod
kubectl run -it testpod --image busybox
进入到已经运行的容器，且容器有交互环境
kubectl attach pods/testpod -it
在已经运行的pod中运行指定命令
kubectl exec -it pods/testpod1 /bin/bash
拷贝文件到pod中
kubectl cp testpod1.yml testpod1:/
kubectl exec -it pods/testpod1 /bin/bash
复制pod中的文件到本机
kubectl cp testpod1:/testpod1.yml testpod1.yml
运行非交互pod
kubectl run nginx --image nginx/nginx:latest
高级命令示例
利用命令生成yaml模板文件
kubectl create deployment --image nginx/nginx:latest webcluster --dry-run=client -o yaml > webcluster.yml
kubectl apply -f webcluster.yml
管理标签
kubectl run nginx --image nginx/nginx:latest
kubectl get pods --show-labels
kubectl label pods nginx app=karl
kubectl get pods --show-labels
更改标签
kubectl label pods nginx app=webcluster --overwrite删除标签
kubectl label pods nginx app-二、pod
1.手动建立pod（生产不推荐）
Kubernetes Pod 是 Kubernetes 中最小的可部署单元，它代表集群中运行的单个实例。Pod 包含一个或多个紧密相关的容器，这些容器共享存储和网络资源，并且总是作为一个整体进行调度和管理。Kubernetes Pod 是 Kubernetes 中的基本构建块，用于封装和管理应用程序的容器。通过共享网络和存储资源，Pod 提供了一种灵活和高效的方式来部署和管理应用程序。理解 Pod 的概念和使用方法是掌握 Kubernetes 的基础。
查看所有pods
kubectl get pods建立一个名为revkarl的pod
kubectl run revkarl --image nginx/nginx:latest
显示pod的较为详细的信息
kubectl get pods -o wide
2.利用控制器管理pod（推荐）
- 自动化管理自动创建和删除：
- 自动创建和删除：控制器可以自动创建、删除和管理 Pod，确保集群始终处于期望的状态。例如，Deployment 控制器可以根据指定的副本数自动创建或删除 Pod。
- 自动恢复：如果 Pod 出现故障或崩溃，控制器会自动检测并重新创建新的 Pod，确保应用的高可用性。
2.高可用性和容错性
- 自动重启：控制器可以监控 Pod 的健康状态，如果某个 Pod 失败，控制器会自动重启它，确保应用始终可用。
- 负载均衡：通过 ReplicationController 或 ReplicaSet，可以确保多个 Pod 实例在不同的节点上运行，实现负载均衡和故障隔离
3.水平扩展
- 自动扩展：使用 Horizontal Pod Autoscaler (HPA)，可以根据 CPU 使用率或其他指标自动调整 Pod 的数量，以应对负载变化。
- 手动扩展：管理员可以轻松地手动增加或减少 Pod 的副本数，以适应业务需求。
4. 滚动更新和回滚
- 滚动更新：使用 Deployment 控制器，可以进行滚动更新，逐步替换旧的 Pod 实例，确保应用在更新过程中始终保持可用。
- 回滚：如果新版本的 Pod 出现问题，可以轻松地回滚到之前的版本，确保应用的稳定性和可靠性。
5. 资源配置和管理
- 资源请求和限制：控制器可以为 Pod 设置资源请求和限制，确保每个 Pod 都有足够的资源来运行，同时避免资源浪费。
- 亲和性和反亲和性：通过设置亲和性和反亲和性规则，可以控制 Pod 的调度行为，确保 Pod 在合适的节点上运行，提高性能和可靠性。
6. 简化运维
- 集中管理：控制器提供了一种集中管理多个 Pod 的方式，简化了运维工作。管理员可以通过一个控制器管理多个 Pod，而不是单独管理每个 Pod。
- 标准化：控制器提供了一种标准化的方式来管理 Pod，确保所有 Pod 都遵循相同的标准和规范。
7. 服务发现和负载均衡
- 服务发现：通过 Service 对象，可以为一组 Pod 提供稳定的网络标识符，实现服务发现。
- 负载均衡：Service 对象可以自动将流量分发到后端的 Pod，实现负载均衡。
建立控制器并自动运行pod
kubectl create deployment revkarl --image nginx/nginx:latest
为revkarl扩容
为revkarl缩容
3.应用版本的更新
利用控制器建立pod
kubectl create deployment revkarl --image myapp:v1 --replicas 2暴露端口
kubectl expose deployment revkarl --port 80 --target-port 80
service/revkarl exposed
查看历史版本
kubectl rollout history deployment revkarl
更新控制器镜像版本
kubectl set image deployments/revkarl myapp=myapp:v2
访问测试一下：
版本回滚
kubectl rollout undo deployment revkarl --to-revision 1
4.利用yaml文件部署应用
获得资源帮助
kubectl explain pod.spec.containers运行简单的单个容器pod
kubectl run revkarl --image myapp:v1 --dry-run=client -o yaml > pod.yml
kubectl apply -f pod.yml运行多个容器pod
vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: revkarl
name: revkarl
spec:
containers:
- image: myapp:v1
name: web1
- image: myapp:v2
name: web2
在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰
vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: revkarl
name: revkarl
spec:
containers:
- image: myapp:v1
name: web1
- image: busybox:latest
name: web2
command: ["/bin/sh","-c","sleep 1000000"]
三、pod的生命周期
1.init容器
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下两点:
o它们总是运行到完成
o init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个Init 容器必须运 行成功，下一个才能够运行。
如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
init容器的功能
- Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
- Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
- 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
- Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
- 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
init容器示例
kubectl run initpod --image myapp:v1 -o yaml > pod.yml
vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: initpod
name: initpod
spec:
containers:
- image: myapp:v1
name: myapp
initContainers:
- name: init-myservice
image: busybox
command: ["sh","-c","until test -e /testfile;do echo wating for myservice;sleep 2;done"]
