無名
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
人生能有几回搏。
一般是docker的原因导致的。
一个可行的解决方案是重新启动 Docker 服务，然后重新运行 kubeadm reset：
sudo systemctl restart docker.service
sudo kubeadm reset
检查 docker 的日志：
journalctl -ul docker
KVM 全称 Kernel-Based Virtual Machine，转译过来叫基于内核的虚拟机，它是一个 Linux 的一个内核模块，该内核模块使得 Linux 变成了一个虚拟机监控程序（Hypervisor）。使主系统能够运行多个隔离的虚拟环境，即虚拟客户机或虚拟机（VM）。
Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“根”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器（Virtual Machine Monitor），即vmm。主要功能就是用来控制生成vm，并管理多个vm的运行，不同的vm中可以安装不同的操作系统，这些操作系统共用一台硬件主机。
|------------------------|
| App | App |
| Bins/Libs | Bins/Libs |
| Guest OS | Guest OS |
| -----------------------|
| Hypervisor |
| -----------------------|
| Host OS |
| -----------------------|
| infrastructure |
|------------------------|
所以，KVM的核心能力就是将你的Linux主操作系统变成了一个Hypervisor，使得能在之上运行多个隔离的虚拟环境。
你看下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
首先，Follower发送FETCH请求给Leader。
接着，Leader会读取底层日志文件中的消息数据，再更新它内存中的Follower副本的LEO值，更新为FETCH请求中的fetchOffset值。
最后，尝试更新分区高水位值。Follower接收到FETCH响应之后，会把消息写入到底层日志，接着更新LEO和HW值。
Leader和Follower的HW值更新时机是不同的，Follower的HW更新永远落后于Leader的HW。这种时间上的错配是造成各种不一致的原因。
因此，对于消费者而言，消费到的消息永远是所有副本中最小的那个HW。
首先，Follower发送FETCH请求给Leader。
接着，Leader会读取底层日志文件中的消息数据，再更新它内存中的Follower副本的LEO值，更新为FETCH请求中的fetchOffset值。
最后，尝试更新分区高水位值。Follower接收到FETCH响应之后，会把消息写入到底层日志，接着更新LEO和HW值。
Leader和Follower的HW值更新时机是不同的，Follower的HW更新永远落后于Leader的HW。这种时间上的错配是造成各种不一致的原因。
因此，对于消费者而言，消费到的消息永远是所有副本中最小的那个HW。
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
可通过以下命令来查看imagePullPolicy这行的解释。
kubectl explain pod.spec.containers
K8s的镜像下载策略有三种：Always、Never、IFNotPresent；
Always：镜像标签为latest时，总是从指定的仓库中获取镜像；Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。
可通过以下命令来查看imagePullPolicy这行的解释。
kubectl explain pod.spec.containers
K8s的镜像下载策略有三种：Always、Never、IFNotPresent；
Always：镜像标签为latest时，总是从指定的仓库中获取镜像；Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。
kubectl scale deployment myapp-deploy --replicas=3
更新
kubectl set image deployment myapp-deploy myapp:v2
如果发现刚才升级的这个版本有问题可以回滚：
kubectl rollout history deployment myapp-deploy
// 获取运行的容器名
kubectl get pods
//
kubectl get pods myapp-deploy-xxxxx -o yaml
kubectl exec -ti myapp-deploy -- /bin/bash
