無名
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
初始化容器（Init Containers）和 Sidecar 容器是 Kubernetes 中两种不同类型的容器，它们的作用和用途也不同。
初始化容器是在应用容器启动之前运行的一个特殊容器，它的作用是在应用容器启动前完成一些初始化操作。这些初始化操作可能包括数据准备、配置加载、数据库迁移、证书生成等等。当初始化容器完成任务后，它会自动退出，然后应用容器才会开始启动。初始化容器可以确保应用容器运行前所需要的依赖和配置已经准备就绪，从而提高了应用容器的可靠性。
相比之下，Sidecar 容器则是在应用容器运行期间一直存在的容器。它通常是用来提供一些额外的功能或者服务，比如日志收集、监控、安全认证等。在一个 Pod 中，多个容器可以共享同一个网络命名空间、存储卷等资源，这使得 Sidecar 容器能够很方便地与应用容器进行通信和交互。
因此，初始化容器和 Sidecar 容器在 Kubernetes 中的作用是不同的，前者用来做一些应用容器启动前的初始化操作，而后者则提供额外的功能或服务。需要根据具体的场景来选择使用哪一种容器。
文件有9.23M哎，外部环境网速变慢，导致需要的缓存更大，我也觉得可能需要调整一下看看结果，除了上面的时间，还可以设置大小：
一般是docker的原因导致的。
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：
sudo systemctl restart docker.service
sudo kubeadm reset
检查 docker 的日志：
journalctl -ul docker
你看下kafka集群的配置文件，是否设置了auto.create.topics.enable=false。
如果有，就设置为ture，当topic不存在，导致的，允许它自动创建。
或者你也可以手动创建topic：
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test
$ kubectl wait --for=condition=complete --timeout=600s job/myjob
Kafka有5个核心API：
Producer API 允许应用程序发送数据流到kafka集群中的topic。Consumer API 允许应用程序从kafka集群的topic中读取数据流。Streams API 允许从输入topic转换数据流到输出topic。Connect API 通过实现连接器（connector），不断地从一些源系统或应用程序中拉取数据到kafka，或从kafka提交数据到宿系统（sink system）或应用程序。Admin API 用于管理和检查topic，broker和其他Kafka对象。具体可参考：kafka接口API
导致kubernetes node状态为NotReady的原因有很多，常见的错误如下：
RPC 调用过程中容器运行时响应超时(有可能是性能下降，死锁或者出现了 bug)。
节点上的 Pod 数量太多，导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。
relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。
获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信，实现容器的网络功能)。
1、NotReady的node上的容器依然提供服务，但已脱离了kubernetes的调度，不会做任何变动。
2、kubernetes将NotReady的node节点上的容器调度正常的node上。
从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。
在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
1、当 NODE节点上内存资源不够的时候，QoS级别是BestEffort的Pod会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。
2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的Pod已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的Ppod都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
详细参考：配置Pod的服务质量（QoS）
