创建静态Pod
vim /etc/kubernetes/manifests/pod.yaml
不用执行，自动创建
在master节点上创建
init初始化容器
Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动。一个Pod里面的所有容器是共享数据卷和网络命名空间的，所以Init Container里面产生的数据可以被主容器使用到的。
Init Container和之前的钩子函数（容器启动前 / 销毁前 自动执行一段代码 / 命令）有点类似，只是是在容器执行前来做一些工作，从直观的角度看上去的话，初始化容器的确有点像PreStart，但是钩子函数和我们的InitContainer是处在不同的阶段的
PostStart和PreStop包括liveness和readiness是属于主容器的生命周期范围内的，而Init Container是独立于主容器之外的，当然他们都属于Pod的生命周期范畴之内的
我们可以看到上面我们的Pod右边还有一个infra的容器，我们可以在集群环境中去查看下任意一个Pod对应的运行的Docker容器，可以发现每一个Pod下面都包含了一个pause-amd64的镜像，这个就是我们的infra镜像，我们知道Pod下面的所有容器是共享同一个网络命名空间的，这个镜像就是来做这个事情的，所以每一个Pod当中都会包含一个这个镜像。
很多 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来，所以需要提前拉取到节点上面。
Init容器与普通容器区别
Init容器总是运行到成功为止
每个Init容器都必须在下一个Init容器启动之前成功完成
如果Pod的Init容器失败，Kubenetes会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的restartPolicy为Never，它不会重新启动
Init容器的优势
·可以包含并运行实用工具。
·可以包含实用工具和定制代码来安装，但是不能出现在应用程序容器镜像中（例如：创建镜像没有必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具）。
·应用程序容器镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
·Init容器使用LinuxNamespace，所以相对应用程序容器来说具有不同的文件系统视图（Init容器能够具有Secret的权限，而应用程序容器则不能 ）。
·它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供一种简单的阻塞或延迟应用程序容器的启动方法，直到满足先决条件。
Init容器应用场景
等待其他模块Ready：可以用来解决服务之间的依赖问题。
做初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。
其它场景：如将 pod 注册到一个中央数据库、配置中心（Nacos）等。
Init容器使用案例
vim init.yml
kubectl apply -f init.yml
他会一直搜索myservice和mysql是否创建，一直创建不成功，所以还要创建service和mysql
vim myservice.yml
kubectl apply -f myservice.yml
创建完一个service之后，状态是这样的，他开始搜索mysql是否创建
vim mysql.yml
kubectl apply -f mysql.yml
临时容器 Ephemeral Containers
临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启，因此不适用于构建应用程序。临时容器使用与常规容器相同的 Container.Spec字段进行描述，但许多字段是不允许使用的。
临时容器没有端口配置，因此像 ports，livenessProbe，readinessProbe 这样的字段是不允许的。
Pod 资源分配是不可变的，因此 resources 配置是不允许的。
临时容器是使用 API 中的一种特殊的 ephemeralcontainers处理器进行创建的， 而不是直接添加到 pod.spec段，因此无法使用 kubectl edit来添加一个临时容器。
与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。
当由于容器崩溃或容器镜像不包含调试工具而导致 kubectl exec 无用时， 临时容器对于交互式故障排查很有用。
尤其是，Distroless 镜像 允许用户部署最小的容器镜像，从而减少攻击面并减少故障和漏洞的暴露。 由于 distroless镜像不包含 Shell 或任何的调试工具，因此很难单独使用 kubectl exec 命令进行故障排查。
使用临时容器时，启用 进程名称空间共享 很有帮助，可以查看其他容器中的进程。
K8s distroless 是一个 Kubernetes 发行版，它专注于提供轻量级的 Kubernetes 环境，删除了许多默认的工具和组件，以减小 Kubernetes 的存储空间和资源占用。
K8s distroless 使用 Go 语言编写，并使用原生 Kubernetes API 进行集群管理。它删除了许多 Kubernetes 中的默认工具，例如 kubectl、kube-proxy、kubelet 等，并提供了自己的命令行工具来管理集群。
K8s distroless 的主要特点包括：
轻量化：K8s distroless 删除了许多默认的工具和组件，以减小 Kubernetes 的存储空间和资源占用。
易于部署：K8s distroless 可以轻松地在各种平台上部署，包括云端、本地和容器环境中。
高效能：K8s distroless 使用原生 Kubernetes API 进行集群管理，提供了高效的资源利用和管理。
安全性：K8s distroless 提供了高度的安全性，包括自动更新、自动补丁和严格的安全策略。
K8s distroless 适合那些想要使用 Kubernetes 进行容器编排，但不想安装大量默认工具和组件的用户。它提供了一种简单、高效和安全的 Kubernetes 解决方案。
简单实验
用一个已有的nginx-pod做实验
kubectl debug -it pod-pvc --image=busybox:1.28 --target=nginx
在已存在的 Pod：pod-pvc 内部，临时注入一个 busybox 调试容器，共享 nginx 容器的网络、进程、挂载卷（PVC）命名空间，交互式进去排错，不重启、不影响原有业务容器。
