目录
Kubernetes 的容器类型
Init 初始化容器
参考文档：Init 容器 | Kubernetes
使用 Init 容器的情况
案例：定义了一个具有 2 个 Init 容器的简单 Pod
你通过运行下面的命令启动 Pod：
发现两个Init容器都没有运行成功
查看更多详细信息：
查看 Pod 内 Init 容器的日志：
如下为创建这些 Service 的配置文件：
创建 mydb 和 myservice 服务的命令：
这样你将能看到这些 Init 容器执行完毕，随后 my-app 的 Pod 进入 Running 状态：
Pause容器
参考文档：K8S学习笔记之九-pause容器 - 南昌拌粉的成长 - 博客园 (cnblogs.com)
运行顺序：
pause容器--》把pod的公用的命名空间都创建好--》init容器---》app容器
Pause容器作用：
Sidecar容器
Sidecar 容器通常用于以下几个方面：
使用边车容器运行日志代理
参考文档:日志架构 | Kubernetes
传输数据流的边车容器
logrotate日志轮转
日志轮转的好处：
App容器
应用程序容器 --》 用于跑业务代码的容器
Kubernetes 的容器类型
Init 初始化容器
参考文档：Init 容器 | Kubernetes
初始化（init）容器像常规应用容器一样，只有一点不同：初始化（init）容器必须在应用容器启动前运行完成。
Init 容器的运行顺序：一个初始化（init）容器必须在下一个初始化（init）容器开始前运行完成。
与普通容器不同之处：Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe（探针类型）， 因为它们必须在 Pod 就绪之前运行完成。
就像 --》兵马未动粮草先行
应用容器运行前必须先运行完成的一个或多个初始化容器。
使用 Init 容器的情况
案例：定义了一个具有 2 个 Init 容器的简单 Pod
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动， 第二个等待 mydb 启动。 一旦这两个 Init 容器都启动完成，Pod 将启动 spec 节中的应用容器。
apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app.kubernetes.io/name: MyApp
spec:containers:- name: myapp-containerimage: busybox:1.28command: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busybox:1.28command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]- name: init-mydbimage: busybox:1.28command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]两个 2 个 Init 容器目的是解析某个域名，并输出，如果一直没有解析到会一直运行两个 Init 容器，如果能将这两个都解析出来，说明这个容器的基础工作就做好了。
你通过运行下面的命令启动 Pod：
[root@master pod]# vim init_service.yaml
[root@master pod]# kubectl apply -f init_service.yaml
pod/myapp-pod created发现两个Init容器都没有运行成功
[root@master pod]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-575db987b-5h7xn 1/1 Running 0 166m 10.244.1.10 node1 <none> <none>
my-nginx-575db987b-nwl5h 1/1 Running 0 166m 10.244.3.10 node3 <none> <none>
my-nginx-575db987b-vqngh 1/1 Running 0 166m 10.244.2.10 node2 <none> <none>
myapp-pod 0/1 Init:0/2 0 25s 10.244.1.11 node1 <none> <none>
redis 1/1 Running 0 8h 10.244.2.5 node2 <none> <none>
scnginx 1/1 Running 0 21h 10.244.2.3 node2 <none> <none>
[root@master pod]# 查看更多详细信息：
[root@master pod]# kubectl describe -f init_service.yaml
查看 Pod 内 Init 容器的日志：
kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器
kubectl logs myapp-pod -c init-mydb # 查看第二个 Init 容器
说明不能解析出来‘myservice.default.svc.cluster.local’
在这一刻，Init 容器将会等待至发现名称为 mydb 和 myservice 的服务。
如下为创建这些 Service 的配置文件：
---
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377创建 mydb 和 myservice 服务的命令：
[root@master pod]# kubectl apply -f service.yaml
service/myservice created
service/mydb created
[root@master pod]#
这样你将能看到这些 Init 容器执行完毕，随后 my-app 的 Pod 进入 Running 状态：
[root@master pod]# kubectl get -f init_service.yaml
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 15m
[root@master pod]#
[root@master pod]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-575db987b-5h7xn 1/1 Running 0 3h2m 10.244.1.10 node1 <none> <none>
my-nginx-575db987b-nwl5h 1/1 Running 0 3h2m 10.244.3.10 node3 <none> <none>
my-nginx-575db987b-vqngh 1/1 Running 0 3h2m 10.244.2.10 node2 <none> <none>
myapp-pod 1/1 Running 0 16m 10.244.1.11 node1 <none> <none>
redis 1/1 Running 0 8h 10.244.2.5 node2 <none> <none>
scnginx 1/1 Running 0 21h 10.244.2.3 node2 <none> <none>
[root@master pod]#
Pause容器
参考文档：K8S学习笔记之九-pause容器 - 南昌拌粉的成长 - 博客园 (cnblogs.com)
Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来 ，在创建一个pod的时候，最先创建的容器
1、每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷
2、因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。
3、同一个Pod里的容器之间仅需通过localhost就能互相通信。
运行顺序：
pause容器--》把pod的公用的命名空间都创建好--》init容器---》app容器
Pause容器作用：
在单个Pod中协调多个容器之间的生命周期。当一个Pod中有多个容器时，这些容器可以通过"Pause"容器来实现同步启动、重启和关闭等操作。"Pause"容器的运行状态会直接影响整个Pod的生命周期。
通过"Pause"容器实现网络和命名空间的共享。Kubernetes中的Pod共享相同的网络和命名空间，这要求容器在同一个网络和命名空间中运行。"Pause"容器充当了这个角色，确保Pod中的其他容器能够正确地共享网络和命名空间。
Sidecar容器
Sidecar 容器是指与主要应用容器共享同一个 Pod 的辅助容器（app容器的配角）。它提供了额外的功能和资源，以增强或扩展主要应用容器的功能。
Sidecar 容器通常用于以下几个方面：
日志收集和处理：Sidecar 容器可以负责将主要应用容器生成的日志进行收集、聚合、格式化等操作，并将其发送到集中式的日志存储或处理系统中，以便进行监控和分析。
监控和指标收集：Sidecar 容器可以负责收集主要应用容器的性能指标、运行状态等信息，并将其发送到监控系统中，以进行实时监控和告警。
身份验证和授权：Sidecar 容器可以提供身份验证和授权服务，对主要应用容器进行访问控制和权限管理，确保只有经过认证和授权的请求能够访问主要应用容器。
代理和负载均衡：Sidecar 容器可以充当主要应用容器的代理，处理网络请求的转发和负载均衡，实现流量管理和请求分发的功能。
通过使用 Sidecar 容器，我们可以将不同的功能模块独立部署在不同的容器中，使得应用的各个组件可以独立于彼此进行扩展、更新和维护。同时，Sidecar 容器还可以提供更好的可观察性和可靠性，以及更灵活的部署和管理方式。
使用边车容器运行日志代理
参考文档:日志架构 | Kubernetes
你可以通过以下方式之一使用边车（Sidecar）容器：
- 边车容器将应用程序日志传送到自己的标准输出。
- 边车容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。
传输数据流的边车容器
利用边车容器，写入到自己的 stdout 和 stderr 传输流， 你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 边车容器从文件、套接字或 journald 读取日志。 每个边车容器向自己的 stdout 和 stderr 流中输出日志。
这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 stdout 或 stderr 的支持。重定向日志背后的逻辑是最小的，因此它的开销不大。 另外，因为 stdout 和 stderr 由 kubelet 处理，所以你可以使用内置的工具 kubectl logs。
logrotate日志轮转
logrotate 日志轮转工具： linux系统自带这个程序，不是一直在内存运行的守护进程
[root@node2 log]# vim /etc/logrotate.conf logrotate.conf 是logrotate的配置文件，它是通过计划任务定时启动logrotate去进行日志轮转
[root@scnode2 log]# cd /etc/logrotate.d/
[root@scnode2 logrotate.d]# ls
bootlog chrony firewalld syslog wpa_supplicant yum
[root@scnode2 logrotate.d]# vim bootlog bootlog 配置文件的作用就是告诉logrotate按照它的要求去进行日志轮转[root@scnode2 logrotate.d]# cat bootlog
/var/log/boot.log
{missingokdaily #每台轮转copytruncate rotate 7 #轮转保持7个notifempty#下面是添加项：dateext #在日志文件的后面添加日期compress #在轮转的时候，进行压缩，节约磁盘空间
}
[root@scnode2 logrotate.d]# 日志轮转的好处：
防止一个日志文件过大，在对日志进行分析的时候，我们读取里面的某天的日志，就会很难去定位，并且需要查找的数据量特别大。
因此我们是使用了日志轮转可以控制日志文件大小、方便管理和分析日志文件、并且降低日志读写的性能开销。我们网络传输日志文件也会比较快（日志文件比较小）。
App容器
应用程序容器 --》 用于跑业务代码的容器
App容器是指承载应用程序的容器，也称为应用容器。它是一种虚拟化技术，用于隔离和管理应用程序及其依赖环境。
常见的App容器技术包括Docker、Kubernetes、OpenShift等。它们在云原生、微服务架构和容器编排领域得到广泛应用，为应用程序的开发、部署和运行提供了便利和灵活性。
