半兽人

35 声望

不要让懒惰占据你的大脑,不让要妥协拖跨你的人生。青春就是一张票,能不能赶上时代的快车,你的步伐掌握在你的脚下,good luck

不要让懒惰占据你的大脑,不让要妥协拖跨你的人生。青春就是一张票,能不能赶上时代的快车,你的步伐掌握在你的脚下,good luck

个人动态
  • 早出晚归 回复 半兽人kafka外网转发 中 :

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

    8小时前
  • 半兽人 回复 早出晚归kafka外网转发 中 :

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

    8小时前
  • 早出晚归 回复 半兽人kafka外网转发 中 :

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

    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:9092127.0.0.1:9093127.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
    

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

    8小时前
  • 半兽人 回复 早出晚归kafka外网转发 中 :

    首先

    advertised.listeners
    

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

    13小时前
  • 早出晚归 回复 半兽人kafka外网转发 中 :

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

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

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

    13小时前
  • 关注了用户 qwerty · 昨天
  • 今天我 贬了 在 Kafka安装和使用 -【视频】 的评论!

    yes,but only one video...

    昨天
  • 無名 赞了 在 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

    5天前
  • 赞了 半兽人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

    6天前
  • 半兽人 赞了 在 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

    6天前
  • 赞了 無名K8s中镜像的下载策略是什么? 的评论!

    可通过以下命令来查看imagePullPolicy这行的解释。

    kubectl explain pod.spec.containers
    

    K8s的镜像下载策略有三种:AlwaysNeverIFNotPresent

    • Always:镜像标签为latest时,总是从指定的仓库中获取镜像;
    • Never:禁止从仓库中下载镜像,也就是说只能使用本地镜像;
    • IfNotPresent:仅当本地没有对应镜像时,才从目标仓库中下载。
    6天前
  • 关注了 {{10365 | filter2}} · 6天前
  • 赞了 半兽人kubernetes就绪探针和存活探针的区别和作用? 的评论!

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

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

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

    6天前
  • 半兽人 赞了 在 kubernetes就绪探针和存活探针的区别和作用? 的评论!

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

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

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

    6天前
  • 赞了 半兽人k8s的service和ep是如何关联和相互影响的? 的评论!

    service将流量发送endpoint(ep)

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

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

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

    详细参考:kubernetes中什么是endpoint?

    6天前
  • 半兽人 赞了 在 k8s的service和ep是如何关联和相互影响的? 的评论!

    service将流量发送endpoint(ep)

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

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

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

    详细参考:kubernetes中什么是endpoint?

    6天前
  • 無名 赞了 在 k8s节点NotReady是什么导致的?NotReady会发生什么? 的评论!

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

    6天前
  • 啊啊 赞了 在 Pod创建过程是什么? 的评论!

    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。

    6天前
  • 赞了 半兽人kubernetes中什么是endpoint? 的评论!

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

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

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

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

    6天前
  • 半兽人 赞了 在 kubernetes中什么是endpoint? 的评论!

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

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

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

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

    6天前
  • 赞了 半兽人k8s节点NotReady是什么导致的?NotReady会发生什么? 的评论!

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

    6天前
  • 半兽人 赞了 在 k8s节点NotReady是什么导致的?NotReady会发生什么? 的评论!

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

    6天前
  • 关注了 {{10258 | filter2}} · 12天前
  • 订阅了 kafka 主题! · 12天前
  • 关注了 {{10255 | filter2}} · 15天前
  • Darker。 关注了Ta · 16天前
  • 易初 关注了Ta · 20天前
  • 发表了 删除kafka消费者组  
    21天前
  • artomu 关注了Ta · 23天前
  • 订阅了 istio 主题! · 26天前
  • い゛i 关注了Ta · 1月前
  • 发表了 KubeBiz配置Kubernetes  
    1月前
  • 庸人自扰 关注了Ta · 1月前
  • 1月前
  • 1月前
  • 订阅了 KubeBiz 主题! · 1月前
  • 周末多睡会 关注了Ta · 1月前
  • July。 关注了Ta · 2月前
  • 发光✨ 关注了Ta · 2月前
  • 关注了用户 Marion · 2月前
  • the prayer 关注了Ta · 2月前
  • 订阅了 linux 主题! · 2月前
  • YuiKuen_Yuen 关注了Ta · 2月前
  • 订阅了 bootstrap5 主题! · 3月前