一、kubernetes中的资源
1.1资源管理介绍
1.在kubernetes中,所有的内容都抽象为资源,用户需要通过操作资源来管理kubernetes。
2.kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes群中运行一个个的容器，并将指定的程序跑在容器中。.kubernetes的最小管理单元是pod而不是容器，只能将容器放在 Pod中，kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。
3.Pod中服务服务的访问是由kubernetes提供的service资源来实现。
4.Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现
1.2资源管理方式
命令式对象管理:直接使用命令去操作kubernetes资源
kubectl run nginx-pod --image=nginx:latest --port=80
命令式对象配置:通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yaml
声明式对象配置:通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yaml
1.2.1命令式对象管理
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
1.2.2运行和调试命令示例
#运行pod
root@k8s-master \~# kubectl run testpod --image nginx
root@k8s-master \~# kubectl get pods
#端口暴漏
root@k8s-master \~# kubectl get services
root@k8s-master \~# kubectl expose pod testpod --port 80 --target-port 80
root@k8s-master \~# kubectl get services
#查看资源详细信息
root@k8s-master \~# kubectl describe pods testpod
#查看资源日志
kubectl logs pods/testpod
#运行交互pod
kubectl run -it testpod --image busybox
#运行非交互pod
kubectl run nginx --image nginx
#进入到已经运行的容器，且容器有交互环境
kubectl attach pods/testpod -it
#在已经运行的pod中运行指定命令
kubectl exec -it pods/nginx /bin/bash
#日志文件到pod中
kubectl cp anaconda-ks.cfg nginx:/
#复制pod中的文件到本机
kubectl cp nginx:/anaconda-ks.cfg anaconda-ks.cfg
1.2.3高级命令示例
#利用命令生成yaml模板文件
kubectl create deployment --image nginx webcluster --dry-run=client -o yaml > webcluster.yml
kubectl apply -f webcluster.yml
#管理资源标签
kubectl run nginx --image nginx
kubectl get pods --show-labels
kubectl label pods nginx app=lee
kubectl get pods --show-labels
#更改标签
kubectl label pods nginx app=webcluster --overwrite
#删除标签
kubectl label pods nginx app-
二、什么是pod
Pod是可以创建和管理Kubernetes计算的最小可部署单元
一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。一个pod类似一个豌豆荚，包含一个或多个容器(通常是docker)
多个容器间共享IPC、Network和UTCnamespace。
2.1创建自主式pod(生产不推荐)
优点:
灵活性高:
可以精确控制Pod的各种配置参数，包括容器的镜像、资源限制、环境变量、命令和参数等，满足特定的应用需求。
适用于特殊场景:
在一些特殊情况下，如进行一次性任务、快速验证概念或在资源受限的环境中进行特定配置时，手动创建Pod可能是一种有效的方式。
缺点:
管理复杂:
如果需要管理大量的Pod，手动创建和维护会变得非常繁琐和耗时。难以实现自动化的扩缩容、故
障恢复等操作。
缺乏高级功能:
无法自动享受Kubernetes提供的高级功能，如自动部署、滚动更新、服务发现等。这可能导致应用的部署和管理效率低下。
可维护性差:
手动创建的Pod在更新应用版本或修改配置时需要手动干预，容易出现错误，并且难以保证一致性。相比之下，通过声明式配置或使用Kubernetes的部署工具可以更方便地进行应用的维护和更新。
kubectl get pods #查看所有的pod
kubectl run timingxu--image nginx 建立一个timingxu的pod
kubectl get pods -o wide #显示pod的详细信息
2.2利用控制器管理pod(推荐)
高可用性和可靠性:
自动故障恢复:如果一个Pod失败或被删除，控制器会自动创建新的Pod来维持期望的副本数量。确保应用始终处于可用状态，减少因单个Pod故障导致的服务中断。
健康检查和自愈:可以配置控制器对Pod进行健康检查(如存活探针和就绪探针)。如果Pod不健康，控制器会采取适当的行动，如重启Pod或删除并重新创建它，以保证应用的正常运行。可扩展性:
轻松扩缩容:可以通过简单的命令或配置更改来增加或减少Pod的数量，以满足不同的工作负载需求。例如，在高流量期间可以快速扩展以处理更多请求，在低流量期间可以缩容以节省资源。水平自动扩缩容(HPA):可以基于自定义指标(如CPU利用率、内存使用情况或应用特定的指标)自动调整Pod的数量,实现动态的资源分配和成本优化。
版本管理和更新:
滚动更新:对于Deployment等控制器,可以执行滚动更新来逐步替换旧版本的Pod为新版本，确保应用在更新过程中始终保持可用。可以控制更新的速率和策略，以减少对用户的影响。.回滚:如果更新出现问题，可以轻松回滚到上一个稳定版本，保证应用的稳定性和可靠性。
声明式配置:
简洁的配置方式:使用YAML或」SON格式的声明式配置文件来定义应用的部署需求。这种方式使得配置易于理解、维护和版本控制，同时也方便团队协作。
期望状态管理:只需要定义应用的期望状态(如副本数量、容器镜像等)，控制器会自动调整实际状态与期望状态保持一致。无需手动管理每个Pod的创建和删除，提高了管理效率。服务发现和负载均衡:
自动注册和发现:Kubernetes中的服务(Service)可以自动发现由控制器管理的Pod,并将流量路由到它们。这使得应用的服务发现和负载均衡变得简单和可靠，无需手动配置负载均衡器。
流量分发:可以根据不同的策略(如轮询、随机等)将请求分发到不同的Pod，提高应用的性能和可用性。
多环境一致性:
一致的部署方式:在不同的环境(如开发、测试、生产)中，可以使用相同的控制器和配置来部署应用，确保应用在不同环境中的行为一致。这有助于减少部署差异和错误，提高开发和运维效率。
kubectl create deployment timinglee --image nginx##建立控制器并自动运行pod
kubectl scale deployment timinglee --replicas 6##为timinglee扩容
kubectl scale deployment timinglee --replicas 2##为timinglee缩容
2.3应用版本的更新
##利用控制器建立pod
kubectl create deployment timinglee --image myapp:v1 replicas 2
#暴露端口
kubectl expose deployment timinglee --port 80 --target-port 80
kubectl get services#查看服务
kubectl rollout history deployment timinglee #查看历史版本
kubectl set image deployments/timinglee myapp-myapp:v2#更新版本
三、pod的生命周期
3.1 INIT容器
Pod可以包含多个容器，应用运行在这些容器里面，同时Pod也可以有一个或多个先于应用容器启动的Init容器。
Init容器与普通的容器非常像，除了如下两点:
它们总是运行到完成
init容器不支持Readiness，因为它们必须在Pod就绪之前运行完成，每个Init容器必须运行成功，下一个才能够运行。
如果Pod的Init容器失败，Kubernetes会不断地重启该Pod，直到Init容器成功为止。但是，如果Pod对应的restartPolicy值为Never,它不会重新启动。
3.1.1INIT容器的功能
Init容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器可具有访问Secrets的权限，而应用容器不能够访问。
由于Init容器必须在应用容器启动之前运行完成，因此Init容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
3.2探针
探针是由kubelet对容器执行的定期诊断:
ExecAction:在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
TCPSocketAction:对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction:对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一:
成功:容器通过了诊断。
失败:容器未通过诊断。
未知:诊断失败，因此不会采取任何行动。Kubelet可以选择是否执行在容器上运行的三种探针执行和做出反应:
livenessProbe:指示容器是否正在运行。如果存活探测失败,则kubelet会杀死容器,并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success。
readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
startupProbe:指示容器中的应用是否已经启动。如果提供了启动探测(startupprobe),则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。