标签：格式 tar 参数 用法 作用 status 系统 钩子 err
简介：在k8s中，一般使用yaml格式的文件来创建符合我们预期期望的pod，这样的yaml文件我们一般称为资源清单
apiVersion <string> #表示字符串类型 metadata <Object> #表示需要嵌套多层字段 labels <map[string]string> #表示由k:v组成的映射 finalizers <[]string> #表示字串列表 ownerReferences <[]Object> #表示对象列表 hostPID <boolean> #布尔类型 priority <integer> #整型 name <string> -required- #如果类型后面接 -required-，表示为必填字段 kubectl get pod xx.xx.xx -o yaml <!--使用 -o 参数加 yaml，可以将资源的配置以 yaml的格式输出出来，也可以使用json，输出为json格式-->
apiVersion: group/apiversion # 如果没有给定 group 名称，那么默认为 core，可以使用 kubectl api-versions # 获取当前 k8s 版本上所有的 apiVersion 版本信息( 每个版本可能不同 ) kind: #资源类别 metadata： #资源元数据 name namespace lables annotations # 主要目的是方便用户阅读查找 spec: # 期望的状态（disired state） status： # 当前状态，本字段有 Kubernetes 自身维护，用户不能去定义
vim pod.yaml 例子： apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: myapp version: v1 spec: containers: - name: app image: hub.lqz.com/library/nginx:latest
u 自主式Pod：Pod退出了，此类型的pod不会被创建（可理解为此pod没有管理者，他的死亡不会被拉起）
u 控制器管理的Pod：在控制器的生命周期里，始终要维持Pod的副本数目（一般为此类型）
① ReplicationController & ReplicaSet & Deployment
>HPA（HorizontalPodAutoScale）
② StatefullSet
③ DaemonSet
④ Job，Cronjob
Horizontal Pod Autoscaling 仅适用于Deployment 和ReplicaSet ，在V1 版本中仅支持根据Pod 的CPU 利用率扩所容，在v1alpha 版本中，支持根据内存和用户自定义的metric 扩缩容
StatefulSet是为了解决有状态服务的问题（对应Deployments 和ReplicaSets是为无状态服务而设计），其应用场景包括：
DaemonSet 确保全部（或者一些）Node 上运行一个Pod 的副本。当有Node 加入集群时，也会为他们新增一个Pod 。当有Node 从集群移除时，这些Pod 也会被回收。删除DaemonSet 将会删除它创建的所有Pod使用DaemonSet 的一些典型用法：
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod 成功结束Cron Job管理基于时间的Job，即：
Kubernetes 的网络模型假定了所有Pod 都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes 假定这个网络已经存在。而在私有云里搭建Kubernetes 集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker 容器之间的互相访问先打通，然后运行Kubernetes
Flannel 是CoreOS 团队针对Kubernetes 设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker 容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内
ETCD 之 Flannel 提供说明：
> 存储管理Flannel 可分配的IP 地址段资源
> 监控ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表
同一个Pod 内部通讯：同一个Pod 共享同一个网络命名空间，共享同一个Linux 协议栈
Pod1 至Pod2
> Pod1 与Pod2 不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问
> Pod1 与Pod2 在同一台机器，由Docker0 网桥直接转发请求至Pod2，不需要经过Flannel
Pod 至 Service的网络：目前基于性能考虑，全部为iptables 维护和转发
Pod 到外网：Pod 向外网发送请求，查找路由表, 转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP 更改为宿主网卡的IP，然后向外网服务器发送请求
外网访问Pod：Service
命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来（ReplicaSet:creat）
声明式编程：它侧重于定义想要什么，然后告诉计算机／引擎，让他帮你去实现(Deployment:apply)
Deployment通过ReplicaSet来管理Pod
kubectl explain pod：看pod模板有那些 kubectl explain pod.apiVersion:查看具体某一个模板 创建pod：kubectl apply -f pod.yaml kubectl create -f pod.yaml 查看pod:kubectl get pod kubectl get pod -o wide 详细信息 删除pod:kubectl delete pod myapp-pod
访问：curl 10.244.2.8
Kubectl describe pod myapp-pod //查看描述信息
kubectl log myapp-pod -c text //查看日志
Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器
Init容器与普通的容器非常像，除了如下两点：
如果Pod的Init容器失败，Kubernetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy为Never，它不会重新启动
因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：
① 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
② 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具。
③ 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
④ Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
⑤ 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。
① 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出(网络和数据卷初始化是在pause)
② 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略
③ 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
④ 如果Pod重启，所有Init容器必须重新执行
⑤ #对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
⑥ Init容器具有应用容器的所有字段。除了readinessProbe（就绪检测），因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
⑦ 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误
探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler。有三种类型的处理程序：
每次探测都将获得以下三种结果之一：
① livenessProbe：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success（会随着容器的生命周期一直存在）
② readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success
Podhook（钩子）是由Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook
Hook的类型包括两种：
PodSpec中有一个restartPolicy字段，可能的值为Always、OnFailure和Never。默认为Always。restartPolicy适用于Pod中的所有容器。restartPolicy仅指通过同一节点上的kubelet重新启动容器。失败的容器由kubelet以五分钟为上限的指数退避延迟（10秒，20秒，40秒...）重新启动，并在成功执行十分钟后重置。如Pod文档中所述，一旦绑定到一个节点，Pod将永远不会重新绑定到另一个节点。
① 挂起（Pending）：Pod已被Kubernetes系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间，这可能需要花点时间
② 运行中（Running）：该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态
③ 成功（Succeeded）：Pod中的所有容器都被成功终止，并且不会再重启
④ 失败（Failed）：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止
⑤ 未知（Unknown）：因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败
1、docker pull busybox 2、vim init-pod.yaml apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: [‘sh‘,‘-c‘,‘echo The app is running! && sleep 3600‘] initContainers: - name: init-myservice image: busybox command: [‘sh‘,‘-c‘,‘until nslookup myservice; do echo waiting for myservice; sleep 2;done;‘] - name: init-mydb image: busybox command: [‘sh‘,‘-c‘,‘until nslookup mydb; do echo waiting for mydb; sleep 2; done;‘] 3、service可以简称svc 创建service kind: Service apiVersion: v1 metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376 kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377
查看pod
kubectl delete deployment --all 删除所有deployment
kubectl delete pod --all 删除所有pod
版本最好不用latest;因为现在和以后的最新版本不一样
查看具体pod信息
链接：https://www.bilibili.com/video/av66617940/?p=17
标签：格式 tar 参数 用法 作用 status 系统 钩子 err
原文地址：https://www.cnblogs.com/LiuQizhong/p/11536127.html
