半兽人

那是怎么对应啊?能给个代码吗

端口导致的，域名只解决ip，把端口也对应上。

用域名配置的方式，我也是试过了，也不行的

Linux kafka_2.11-0.11.0.2集群三台机子分别配置：

server.properties配置

advertised.listeners=PLAINTEXT://hadoop01.richstone.com:9092
advertised.listeners=PLAINTEXT://hadoop02.richstone.com:9092
advertised.listeners=PLAINTEXT://hadoop03.richstone.com:9092

hosts配置

10.0.2.5   hadoop01.richstone.com
10.0.2.6   hadoop02.richstone.com
10.0.2.7   hadoop03.richstone.com

虚拟机nat端口转发

10.0.2.5:9092 转发到宿主机127.0.0.1:9092
10.0.2.6:9092 转发到宿主机127.0.0.1:9093
10.0.2.7:9092 转发到宿主机127.0.0.1:9094

宿主机配置hosts配置

127.0.0.1 hadoop01.richstone.com
127.0.0.1 hadoop02.richstone.com
127.0.0.1 hadoop03.richstone.com

windows宿主机：

Telnet 127.0.0.1:9092，127.0.0.1:9093，127.0.0.1:9094是通的

访问：

.\bin\windows\kafka-console-consumer.bat --topic first --bootstrap-server  hadoop01.richstone.com:9092,hadoop02.richstone.com:9093,hadoop03.richstone.com:9094 --from-beginning

但是上面消费数据的时候就阻塞了，没法消费数据

首先

advertised.listeners

不要配置了，已经弃用了。
其次，你在仔细读读这篇文章，你核心还没抓到。

我是试过配了宿主机ip的，

listeners=PLAINTEXT://10.0.2.5:9092
advertised.listeners=PLAINTEXT://本机ip:9092

这么配连虚拟机内网的消费者生产者都启动不了，宿主机和虚拟机用的是nat端口转发，不是用的桥接模式的，这相当于两个不同的局域网，宿主机不能直接访问虚拟机的网络

yes，but only one video...

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

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

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：仅当本地没有对应镜像时，才从目标仓库中下载。

kubelet 使用存活探测器来知道什么时候要重启容器。 例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）

kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。

详细参考：kubernetes配置Liveness和Readiness探针

kubelet 使用存活探测器来知道什么时候要重启容器。 例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）

kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。

详细参考：kubernetes配置Liveness和Readiness探针

service将流量发送endpoint(ep)。

ep是Kubernetes中明确定义的一个网络抽象概念。由于它是次要的，你通常不会直接操作它，命令行可以查看：

$ kubectl get ep
NAME         ENDPOINTS            AGE
kubernetes   192.168.32.32:8443   2d

在这里你可以看到它实际上是什么：一个IP地址和一个端口。

详细参考：kubernetes中什么是endpoint？

service将流量发送endpoint(ep)。

ep是Kubernetes中明确定义的一个网络抽象概念。由于它是次要的，你通常不会直接操作它，命令行可以查看：

$ kubectl get ep
NAME         ENDPOINTS            AGE
kubernetes   192.168.32.32:8443   2d

在这里你可以看到它实际上是什么：一个IP地址和一个端口。

详细参考：kubernetes中什么是endpoint？

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上。

kubernetes Pod 创建的工作流：

step 1：

kubectl 向 api server 发起一个create pod 请求

step 2：

apiserver接收到pod创建请求后，不会去直接创建pod，而是生成一个包含创建信息的yaml。

step 3：

apiserver 将刚才的yaml信息写入etcd数据库。到此为止仅仅是在etcd中添加了一条记录， 还没有任何的实质性进展。

step 4：

scheduler 查看 k8s api ，类似于通知机制。

首先判断：pod.spec.Node == null?

若为null，表示这个Pod请求是新来的，需要创建；因此先进行调度计算，找到最闲的node。
然后将信息在etcd数据库中更新分配结果：pod.spec.Node = nodeA (设置一个具体的节点)

ps:同样上述操作的各种信息也要写到etcd数据库中中。

step 5：

kubelet 通过监测etcd数据库(即不停地看etcd中的记录)，发现api server 中有了个新的Node；
如果这条记录中的Node与自己的编号相同(即这个Pod由scheduler分配给自己了)；
则调用node中的docker api，创建container。

它是Kubernetes中明确定义的一个网络抽象概念。由于它是次要的，你通常不会直接操作它，命令行可以查看：

$ kubectl get ep
NAME         ENDPOINTS            AGE
kubernetes   192.168.32.32:8443   2d

在这里你可以看到它实际上是什么：一个IP地址和一个端口。

service则将流量发送endpoint(ep)了。

它是Kubernetes中明确定义的一个网络抽象概念。由于它是次要的，你通常不会直接操作它，命令行可以查看：

$ kubectl get ep
NAME         ENDPOINTS            AGE
kubernetes   192.168.32.32:8443   2d

在这里你可以看到它实际上是什么：一个IP地址和一个端口。

service则将流量发送endpoint(ep)了。

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上。

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上。