無名

两者的相同之处：两者都有总线和外界联系，有自己的缓存体系，以及数字和逻辑运算单元。一句话，两者都为了完成计算任务而设计。

两者的区别在于存在于片内的缓存体系和数字逻辑运算单元的结构差异：CPU虽然有多核，但总数没有超过两位数，每个核都有足够大的缓存和足够多的数字和逻辑运算单元，并辅助有很多加速分支判断甚至更复杂的逻辑判断的硬件；GPU的核数远超CPU，被称为众核（NVIDIA Fermi有512个核）。每个核拥有的缓存大小相对小，数字逻辑运算单元也少而简单（GPU初始时在浮点计算上一直弱于CPU）。从结果上导致CPU擅长处理具有复杂计算步骤和复杂数据依赖的计算任务，如分布式计算，数据压缩，人工智能，物理模拟，以及其他很多很多计算任务等。GPU由于历史原因，是为了视频游戏而产生的（至今其主要驱动力还是不断增长的视频游戏市场），在三维游戏中常常出现的一类操作是对海量数据进行相同的操作，如：对每一个顶点进行同样的坐标变换，对每一个顶点按照同样的光照模型计算颜色值。GPU的众核架构非常适合把同样的指令流并行发送到众核上，采用不同的输入数据执行。在2003-2004年左右，图形学之外的领域专家开始注意到GPU与众不同的计算能力，开始尝试把GPU用于通用计算（即GPGPU）。之后NVIDIA发布了CUDA，AMD和Apple等公司也发布了OpenCL，GPU开始在通用计算领域得到广泛应用，包括：数值分析，海量数据处理（排序，Map-Reduce等），金融分析等等。

简而言之，当程序员为CPU编写程序时，他们倾向于利用复杂的逻辑结构优化算法从而减少计算任务的运行时间，即Latency。当程序员为GPU编写程序时，则利用其处理海量数据的优势，通过提高总的数据吞吐量（Throughput）来掩盖Lantency。目前，CPU和GPU的区别正在逐渐缩小，因为GPU也在处理不规则任务和线程间通信方面有了长足的进步。另外，功耗问题对于GPU比CPU更严重。

初始化容器（Init Containers）和 Sidecar 容器是 Kubernetes 中两种不同类型的容器，它们的作用和用途也不同。

初始化容器是在应用容器启动之前运行的一个特殊容器，它的作用是在应用容器启动前完成一些初始化操作。这些初始化操作可能包括数据准备、配置加载、数据库迁移、证书生成等等。当初始化容器完成任务后，它会自动退出，然后应用容器才会开始启动。初始化容器可以确保应用容器运行前所需要的依赖和配置已经准备就绪，从而提高了应用容器的可靠性。

相比之下，Sidecar 容器则是在应用容器运行期间一直存在的容器。它通常是用来提供一些额外的功能或者服务，比如日志收集、监控、安全认证等。在一个 Pod 中，多个容器可以共享同一个网络命名空间、存储卷等资源，这使得 Sidecar 容器能够很方便地与应用容器进行通信和交互。

因此，初始化容器和 Sidecar 容器在 Kubernetes 中的作用是不同的，前者用来做一些应用容器启动前的初始化操作，而后者则提供额外的功能或服务。需要根据具体的场景来选择使用哪一种容器。

kafka topic存储都是没有限制的呀？
只有网络限流，你指的是什么呢？

感谢，很详细。

区别在这里：
Dockerfile文件的ADD和COPY命令

一般是docker的原因导致的。

一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：

sudo systemctl restart docker.service
sudo kubeadm reset

检查 docker 的日志：

journalctl -ul docker

https://github.com/kubernetes/kubernetes/issues/53533

你看下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

Kubernetes(k8s)就是按照用户的期望的样子来运行部署应用程序。
赞！

大佬，非常高兴能看到你得文章

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

NotReady是什么导致的？

导致kubernetes node状态为NotReady的原因有很多，常见的错误如下：

1. kubelet启动节点失败（核心）
2. 网络附加组件cni，如：calico、flannel等故障
3. 节点OOM（NotReady和Ready状态反复切换，因为释放容器之后，又满了，轮询反复）

大部分情况是kubelet引起的：

• RPC 调用过程中容器运行时响应超时(有可能是性能下降，死锁或者出现了 bug)。

• 节点上的 Pod 数量太多，导致 relist操作无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。

• relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。

• 获取 Pod 的网络堆栈信息时CNI插件出现了bug(简而言之即容器管理系统和网络插件之间通过 JSON 格式的文件进行通信，实现容器的网络功能)。

NotReady会发生什么？

1、NotReady的node上的容器依然提供服务，但已脱离了kubernetes的调度，不会做任何变动。
2、kubernetes将NotReady的node节点上的容器调度正常的node上。

QoS是怎么实现的

从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。

QoS是什么

在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。

QoS 类

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：

• Guaranteed
• Burstable
• BestEffort

QoS 类为 Guaranteed 的 Pod

• Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。
• Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。

QoS 类为 Burstable 的 Pod

如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个容器具有内存或 CPU 请求。

QoS 类为 BestEffort 的 Pod

• 对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。

QoS级别决定了kubernetes处理这些Pod的方式，我们以内存资源为例：

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）