Kafka——两种集群搭建详解 k8s

1、简介
Kafka是一个可以或许支持高并发以及流式消息处理的消息中间件，并且Kafka天生就是支持集群的，本日就紧张来先容一下如何搭建Kafka集群。
Kafka目前支持利用Zookeeper模式搭建集群以及KRaft模式（即无Zookeeper）模式这两种模式搭建集群，这两种模式各有各的利益，本日就来分别先容一下这两种方式

1.1、Kafka集群中的节点类型
一个Kafka集群是由下列几种类型的节点构成的，它们充当着不同的作用：
Broker节点：即代理节点，是Kafka中的工作节点，充当消息队列的角色，负责储存和处理消息，每个Broker都是一个独立的Kafka服务器，可以在不同的机器上运行，除此之外Broker还负责分区（partition）的管理，将主题（topic）划分为多个分区，并分布在集群的不同Broker上
Controller节点：即控制器节点，是集群中的特殊节点，负责储存和管理整个集群元数据和状态，它可以或许监控整个集群中的Broker，在必要时还可以或许举行平衡操作
混合节点：即同时担任Broker和Controller节点角色的节点

1.2、两重模式的搭建方式
Zookeeper模式集群
KRaft模式集群
2、Zookeeper模式集群
这是一种比较简单，相对“传统”的搭建方式了！在这种模式下，每个Kafka节点都是依赖于Zookeeper的，利用Zookeeper存储集群中所有节点的元数据。
只要所有的Kafka节点连接到同一个Zookeeper上面（大概同一个Zookeeper集群），这些Kafka节点就构成了一个集群。以是说就算是只有一个Kafka节点在运行，这一个节点也可以称作一个集群。
在Zookeeper模式集群中，Zookeeper节点（大概集群）就充当了Controller的角色，而所有的Kafka节点就充当着Broker的角色。
下面就来先容一下搭建过程，这里在1台主机上分别运行Zookeeper和Kafka来模仿一个集群，一共一个Zookeeper节点和三个Kafka节点构成，如下：

节点名地址和端口Zookeeper节点localhost:2181Kafka节点1localhost:9092Kafka节点1localhost:9093Kafka节点1localhost:9094
   1、搭建Zookeeper
  起首我们要运行起一个Zookeeper节点，这里

起首我们要运行起一个Zookeeper节点，这里就不再赘述Zookeeper节点如何搭建了，搭建可以查看官方文档，大概利用Docker的方式搭建。
搭建完成并运行Zookeeper之后，我们会把所有的Kafka节点都配置到这一个Zookeeper节点上。
   2、配置并运行所有Kafka节点
  server1.properties

1. # 每个节点的id，不要不相同的整数
2. broker.id=1
3. # 存储位置
4. log.dirs=/tmp/kafka-logs/cluster/log1
5. # zookeeper集群的话，多个地址用逗号分割
6. zookeeper.connect=localhost:2181
7. # zookeeper连接超时时间
8. zookeeper.connection.timeout.ms=18000
9. # 外网暴露
10. advertised.listeners=PLAINTEXT://localhost:9092
11. # 内网端口
12. listeners=PLAINTEXT://localhost:9092

复制代码

server2.properties

1. # 每个节点的id，不要不相同的整数
2. broker.id=2
3. # 存储位置
4. log.dirs=/tmp/kafka-logs/cluster/log2
5. # zookeeper集群的话，多个地址用逗号分割
6. zookeeper.connect=localhost:2181
7. # zookeeper连接超时时间
8. zookeeper.connection.timeout.ms=18000
9. # 外网暴露
10. advertised.listeners=PLAINTEXT://localhost:9093
11. # 内网端口
12. listeners=PLAINTEXT://localhost:9093

复制代码

server3.properties

1. # 每个节点的id，不要不相同的整数
2. broker.id=3
3. # 存储位置
4. log.dirs=/tmp/kafka-logs/cluster/log3
5. # zookeeper集群的话，多个地址用逗号分割
6. zookeeper.connect=localhost:2181
7. # zookeeper连接超时时间
8. zookeeper.connection.timeout.ms=18000
9. # 外网暴露
10. advertised.listeners=PLAINTEXT://localhost:9094
11. # 内网端口
12. listeners=PLAINTEXT://localhost:9094

复制代码

三台假造机配置完成后，分别利用终端进入到Kafka目录下并启动，执行下列命令：

1. ./kafka-server-start.sh -daemon ../config/cluster/server1.properties
2. ./kafka-server-start.sh -daemon ../config/cluster/server2.properties
3. ./kafka-server-start.sh -daemon ../config/cluster/server3.properties

复制代码

3、测试
先在kafka1的端口上面再开一个终端并进入Kafka目录，执行下列命令创建cluster-topic，共3个分区，每个人去都分配3个副本：

1. ./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic cluster-topic --partitions 3 --replication-factor 3

复制代码

然后在kafka2的端口查询该topic：

1. ./kafka-topics.sh --bootstrap-server localhost:9093 --describe --topic cluster-topic 

复制代码

显而易见，该topic下有3个分区，每个分区有三个副本。每个分区的leader分别是1，2，3，表明kafka将该topic的3分区均匀地在3台broker上举行了分配。
删除分区：

1. ./kafka-topics.sh --bootstrap-server localhost:9093 --delete --topic cluster-topic

复制代码

3、KRaft模式集群

在上述传统方案中，Kafka必要依赖Zookeeper完成元数据存放和共享，这样也就袒露出了一些题目：

• 搭建Kafka集群时还必要额外搭建Zookeeper，增长了运维成本
  
• Zookeeper是强同等性的组件（符合CP理论），如果集群中数据发生变化，那么必须要等到别的节点都同步，至少超过一半同步完成，这样节点数多性能差
  

KRaft模式是新版本Kafka中推出的集群模式，这种模式下就完全不必要Zookeeper了！只必要数个Kafka节点就可以直接构成集群，在这时集群中的Kafka节点既有大概是Controller节点也大概是Broker节点，在这个模式中，我们不仅可以手动配置某个节点的角色（是Controller还是Broker），还可以使其同时担任Broker和Controller角色（混合节点）。
在KRaft模式中，集群的节点会通过投票选举的方式，选择出一个紧张的Controller节点，这个节点也称作向导者，它将负责维护整个集群的元数据和状态信息，那么别的的Controller节点大概混合节点就称之为跟随者，它们会从向导者同步集群元数据和状态信息。如果向导者宕机了，所有的节点会重新投票选举一个新的向导者。
在选举过程中，所有的节点都会参与投票过程，而候选节点只会是Controller节点大概混合节点（即Broker节点不会被选举为向导者）。
必要注意的是，在默认环境下Kafka集群中的Broker节点和Controller节点通常会监听不同的端口：
 

• Broker节点是Kafka集群中的数据节点（消息队列），它们负责接收客户端的消息和传递消息给客户端，默认环境下，每个Broker节点会监听9092端口，该端口用于与客户端举行通讯，客户端可以将消息发送到这个端口，大概从这个端口接收消息，这个端口可以称作客户端通讯端口
  
• Controller节点是Kafka集群中的控制器节点，负责管理集群的状态和元数据，Controller节点监听的端口通常是9093，该端口用于集群中其他节点获取元数据或在混合节点选举新的Controller时举行通讯，通过该端口，其他节点可以与Controller节点交互，获取集群的元数据信息或参与控制器的选举过程，这个端口可以称作控制器端口
  
• 混合节点（即同时担任Broker和Controller角色的节点）中，这两个端口都会被利用，默认环境下混合节点将监听9092端口接收和传递消息给客户端，并监听9093端口用于与其他节点举行元数据交换和控制器选举通讯，可见混合节点会同时利用两个端口分别作为客户端通讯端口与控制器端口
   
  

以是必要根据现实环境配置网络设置和防火墙规则，以确保Kafka集群中的节点可以或许在精确的端口上举行通讯。上述提到的两种端口也是可以修改的，当然不发起修改。
同样地，就算是你只是搭建了一个Kafka节点，这一个节点也仍旧被视为一个Kafka集群，并且KRaft模式下如果只必要建立一个节点，那么这个节点必须是混合节点。
单台主机模仿搭建三个Kafka节点构成的KRaft模式集群如下：
节点名地址节点类型客户端通讯端口控制器端口Kafka节点1localhost混合节点90929093Kafka节点2localhost混合节点90949095Kafka节点3localhost混合节点90969097   1、修改配置文件
  在KRaft模式下，配置文件位于Kafka目录中的config/kraft/server.properties，利用文本编辑器打开并找到下列配置以修改：

• node.id 表现这个节点的id，一个集群中每个节点id不能重复，必要是不小于1的整数，这里三台假造机的配置分别为1，2和3（类似上述Zookeeper的broker.id配置）
  
• controller.quorum.voters 设定投票者列表，即必要配置所有的Controller节点id及其地址端口，配置格式为节点1的id@节点1地址:节点1端口,节点2的id@节点2地址:节点2端口,节点3的id@节点3地址:节点3端口…，这里的端口必要是控制器端口，默认都是9093，上面也提到过了，默认不必要修改
  
• advertised.listeners 表现这个Kafka节点的外网地址，这里分别配置为PLAINTEXT://localhost:9092，PLAINTEXT://localhost:9094和PLAINTEXT://localhost:9096（和上述Zookeeper模式中的一样，现实在服务器上搭建时替换为服务器的外网地址大概域名）
  
• process.roles 表现设定这个节点的类型，设定为broker表现设定这个节点为Broker节点，同样地设定controller表现设定为Controller节点，默认是broker,controller表现这个节点会自动切换节点类型
  

server1.properties

1. #节点类型，默认为混合节点
2. process.roles=broker,controller
3. # 节点id，为不小于1的整数
4. node.id=1
5. # 投票者列表：nodeId+地址端口
6. controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
7. # 内网地址
8. listeners=PLAINTEXT://:9092,CONTROLLER://:9093
9. inter.broker.listener.name=PLAINTEXT
10. # 外网地址
11. advertised.listeners=PLAINTEXT://localhost:9092
12. controller.listener.names=CONTROLLER
13. log.dirs=/tmp/kraft-combined-logs/log1

复制代码

server2.properties

1. # 节点类型，默认为混合节点
2. process.roles=broker,controller
3. # 节点id，为不小于1的整数
4. node.id=2
5. # 投票者列表：nodeId+地址端口
6. controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
7. # 内网地址
8. listeners=PLAINTEXT://:9094,CONTROLLER://:9095
9. inter.broker.listener.name=PLAINTEXT
10. # 外网地址
11. advertised.listeners=PLAINTEXT://localhost:9094
12. controller.listener.names=CONTROLLER
13. log.dirs=/tmp/kraft-combined-logs/log2

复制代码

server3.properties

1. # 节点类型，默认为混合节点
2. process.roles=broker,controller
3. # 节点id，为不小于1的整数
4. node.id=3
5. # 投票者列表：nodeId+地址端口
6. controller.quorum.voters=1@localhost:9093,2@localhost:9095,3@localhost:9097
7. # 内网地址
8. listeners=PLAINTEXT://:9096,CONTROLLER://:9097
9. inter.broker.listener.name=PLAINTEXT
10. # 外网地址
11. advertised.listeners=PLAINTEXT://localhost:9096
12. controller.listener.names=CONTROLLER
13. log.dirs=/tmp/kraft-combined-logs/log3

复制代码

  2、天生集群ID并利用集群ID格式化数据目录
  在KRaft模式下，一个集群必要设定一个id，我们可以利用自带的命令天生，先进入上述恣意一台假造机并利用终端进入Kafka目录中，执行下列命令天生一个UUID：

1. bin/kafka-storage.sh random-uuid

复制代码

里记录下这个ID以备用。kilMbKEoRUq3Ha6nruW6Aw
这个集群ID事实上是一个长度16位的字符串通过Base64编码后得来的，因此你也可以不利用上述命令，直接自界说一个16位长度的纯英文和数字构成的字符串，然后将这个字符串编码为Base64格式作为这个集群ID也可以。可以利用菜鸟工具中的在线Base64编码工具。
然后，分别执行下列命令，配置集群元数据：

1. kafka-storage.sh format -t 生成的集群ID -c ../config/kraft/cluster/server1.properties
2. kafka-storage.sh format -t kilMbKEoRUq3Ha6nruW6Aw -c ../config/kraft/cluster/server2.properties
3. kafka-storage.sh format -t kilMbKEoRUq3Ha6nruW6Aw -c ../config/kraft/cluster/server3.properties

复制代码

3、启动Kafka集群
利用终端，分别执行下列命令：

• kafka-server-start.sh -daemon ../config/kraft/cluster/server1.properties
  
• kafka-server-start.sh -daemon ../config/kraft/cluster/server2.properties
  
• kafka-server-start.sh -daemon ../config/kraft/cluster/server3.properties
  

4、创建topic测试
先在kafka1的端口(9092)上面再开一个终端并进入Kafka目录，执行下列命令创建cluster-topic，共3个分区，每个人去都分配3个副本：

1. ./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic cluster-topic --partitions 3 --replication-factor 3

复制代码

然后在kafka2的端口(9094)查询该topic：

1. ./kafka-topics.sh --bootstrap-server localhost:9094 --describe --topic cluster-topic 

复制代码

在kafka3的端口(9096)删除分区：

1. ./kafka-topics.sh --bootstrap-server localhost:9096 --delete --topic cluster-topic 

复制代码

可见集群节点之间可以互相通讯。
4、紧张配置先容
4.1、listeners
这个配置项用于指定Kafka服务器监听客户端连接的地址和端口，当 Kafka 服务器启动时，它将监听listeners配置项中指定的地址和端口，等候客户端的连接请求。
一般环境下这个配置以PLAINTEXT://大概CONTROLLER://开头，意义如下：

• 若这个节点是Broker节点，则以PLAINTEXT://开头
  
• 若这个节点是Controller节点，则以CONTROLLER://开头
  
• 若这个节点是混合节点，则必要同时配置两者开头的地址
  

这个配置项通常不必要修改，下面给出几个配置示例：

• PLAINTEXT://:9092 本节点作为Broker节点，监听本机所有可用网卡的9092端口（利用9092端口作为客户端通讯端口），也是默认配置
  
• PLAINTEXT://127.0.0.1:9092 本节点作为Broker节点，监听当地的9092端口，这样仅继承来自当地的请求
  
• CONTROLLER://:10000 本节点作为Controller节点，监听本机所有可用网卡的10000端口（利用10000端口作为控制器端口）
  
• PLAINTEXT://:9092,CONTROLLER://:9093 本节点作为混合节点，监听本机所有可用网卡的9092和9093端口，此中9092作为客户端通讯端口，9093作为控制器端口
  

4.2、advertise.listeners
这个配置容易和listeners肴杂，事实上它们是有较大的区别的。
该配置项指定Kafka服务器广播给客户端的地址和端口，通常配置为Kafka地点服务器的外网地址。
当客户端（生产者或消费者）尝试连接到Kafka服务器时，它起首会获取Kafka服务器广播的地址和端口，也就是advertise.listeners配置所指定的地址和端口，然后才会利用advertise.listeners配置所指定的地址和端口来建立与Kafka服务器的连接。
相信这时大家会有个疑问：既然客户端要连接Kafka（例如Spring Boot集成Kafka客户端），那肯定是已经知道了Kafka对外的地址端口了，那为什么连接的时间还必要获取一下广播的地址端口再举行连接呢？这样是不是有一些多此一举？
事实上，Kafka计划这个配置是为了解决下面较为复杂的网络场景：

• 多网络接口的主机摆设：在一个多网络接口的主机摆设Kafka时，Kafka服务器大概会监听多个地址和端口，这些地址和端口大概与客户端现实访问的地址和端口不同，advertise.listeners答应服务器指定一个公开的、可访问的地址和端口，以便客户端可以或许精确连接
  
• NAT/代理环境：在某些网络环境下，Kafka服务器位于一个私有网络中，客户端位于一个公共网络中，两者之间大概存在网络地址转换（NAT）或代理，在这种环境下，Kafka服务器的内部地址和端口对客户端来说是不可访问的。通过利用advertise.listeners，Kafka服务器可以将一个公共地址和端口广播给客户端，使得客户端可以或许通过公共网络连接到服务器
  
• 容器环境：例如你把Kafka放在Docker容器中运行，按照默认配置，Kafka服务端只会监听容器网络的9092端口，我们知道外部不能直接访问容器的网络，而是必要利用网络映射，假设你把Kafka容器的9092端口映射至了宿主机9095端口，也就是说外部必要通过9095端口访问到Kafka容器的9092端口，那么你就配置advertise.listeners为PLAINTEXT://服务器外网地址:9095，客户端就可以精确访问容器中的Kafka了
  

总之，这个配置设置为Kafka服务器地点的外网地址即可！例如PLAINTEXT://69.54.112.239:9092。
4.3、process.roles
这是KRaft模式下专门的配置，用于配置这个节点的类型，可以配置为下列值：

• broker 表现这个节点是Broker节点，充当消息队列的角色
  
• controller 表现这个节点是Controller节点，充当元数据存放和管理的角色
  
• broker,controller 表现这个节点同时担任Broker和Controller的角色，也称作混合节点
  

如果没有配置这个选项，则Kafka会以Zookeeper模式运行。
这里有下列注意事项：

• 如果设定节点为controller：
  

              1.  则不能配置advertised.listeners，可以将其注释掉大概删掉
              2.  listeners必要配置为CONTROLLER://开头，发起配置为CONTROLLER://:9093

• 如果设定节点为broker：
  

                1. 则必要配置advertised.listeners为服务器外网地址和端口，这和Zookeeper模式中雷同
                2.listeners必要配置为PLAINTEXT://开头，发起配置为PLAINTEXT://:9092

• 如果设定节点为混合节点：
  

               1. 同样必要配置advertised.listeners为服务器外网地址和端口
l              2. isteners必要同时配置CONTROLLER://和PLAINTEXT://，发起配置为            PLAINTEXT://:9092,CONTROLLER://:9093

在开发环境大概小规模集群，可以全部利用混合节点，如果是生产环境就发起设定好每个节点的类型了！并且通常必要先启动Controller节点再启动Broker节点。
事实上，我们发现Kafka的KRaft配置目录config/kraft下有三个配置文件，此中server.properties是混合节点的配置模板，而broker.properties和controller.properties分别是Broker节点和Controller节点的配置模板，大家如果要设定节点类型，可以直接利用对应的配置文件，将对应配置文件必要修改的部分修改一下，然后将上述格式化数据目录命令和启动命令中的配置文件路径改变一下即可，这样可以省略我们设定process.roles和listeners大概控制器节点删除advertise.listeners配置的操作。
4.4、controller.quorum.voters
该配置项用于配置集群中Controller节点选举过程中的投票者，集群中所有的Controller节点都必要被罗列在这个配置项中，其配置格式为id1@host1:port1,id2@host2:port2,id3@host3:port3...。
有的同学大概以为这里必要把集群中所有节点都写进去，事实上这是错误的，这里只必要写所有的Controller节点和混合节点的id、地址和端口即可，这个配置中配置的端口当然是控制器端口。
上述集群搭建的例子中，由于所有的节点都是混合节点，因此就全部写在此中了！如果我们手动设定每个节点的类型，例如：
节点名节点id地址服务器通讯端口控制器端口节点类型Kafka节点11kafka1/9093ControllerKafka节点22kafka29092/BrokerKafka节点33kafka39092/Broker
那么所有节点的controller.quorum.voters都必要配置为1@kafka1:9093。
事实上，所有的节点都是通过这个配置中的节点列表，来得知所有的控制器节点信息（以获取集群元数据）并得到投票候选者的，因此集群中所有节点，不论是Broker还是Controller，还是混合节点，都必要配置这一项。
4.5、别的配置
除了上述我们涉及到的一些配置之外，还有下列配置大家可以举行修改：

• socket.send.buffer.bytes 每次发送的数据包的最大大小（单位：字节）
  
• socket.receive.buffer.bytes 每次接收的数据包的最大大小（单位：字节）
  
• socket.request.max.bytes 接收的最大请求大小（单位：字节）
  
• num.partitions 每个Topic的默认分区数
  

上述无论是哪个模式的集群，都可以在配置文件中找到这些配置，如果找不到可手动加入。除了修改配置文件之外，我们还可以在启动Kafka的命令中指定配置和值，例如：

1. bin/kafka-server-start.sh config/server.properties --override zookeeper.connect=127.0.0.1:2181 --override broker.id=1

复制代码

上述命令在启动时通过命令指定了zookeeper.connect配置值为127.0.0.1:2181，以及broker.id为1，可见在背面追加–override 配置名=值即可，注意命令行中指定的配置值会覆盖掉配置文件中的配置值！


listeners 和 advertised.listeners 以及其他通讯配置

listeners

侦听器列表，这里配置的监听器底层调用的是

1. ServerSocketAdaptor.bind(SocketAddress local)

复制代码

那么这个阐明什么意思呢？阐明你配置的监听器将被用于监听网络请求。
简单理解就是你建立监听一个通道, 别人可以或许通过这个通道跟你沟通。
以是我们必要设置 ​​​IPort​​.
这个属性的格式为:

1. listeners = listener_name://host_name:port,listener_name2://host_nam2e:port2

复制代码

• 可以同时配置多个, 并且用逗号隔开
  
• 监听器的名称和端口必须是唯一的, 端口雷同, 就冲突了
  
• host_name 如果为空, 例如 (​​listeners = ://host_name:port​​​), 则会绑定到默认的接口 (网卡), 一般环境下是​​localhost​​，底层调用的是
  

1. java.net.InetAddress.getCanonicalHostName()

复制代码

• 将 host_name 设置为​​0.0.0.0 ​​​ 则会绑定所有的网卡, 也就是说不管从哪个网卡进入的请求都会被继承处理。但是请注意, 假如你设置的是​​0.0.0.0​​​, 那么​​advertised.listeners​​​ 必须要设置, 由于​​advertised.listeners​​​默认请看下利用的是​​listeners​​​的配置发布到 zk 中, 发布到 zk 中是给其他 Brokers/Clients 来跟你通讯的, 你设置​​0.0.0.0​​, 谁知道要请求哪个 IP 呢, 以是它必须要指定并明确 IPORT。具体详情请看下面示例 3
  
• listener_name 是监听名, 唯一值, 他并不是安全协议 (大部分人都会搞错), 由于默认的 4 个安全协议已经做好了映射, 例如 ：PLAINTEXT ==> PLAINTEXT . 以是你经常看到的配置
  

1. ## 这个PLAINTEXT是监听名称,刚好他对应的安全协议就是 PLAINTEXT
2. ## 当然这个是可以自定义的, 详细情况 后面的配置listener.security.protocol.map
3. listeners = PLAINTEXT://your.host.name:9092

复制代码

advertised.listeners

发布公开的监听器, 啥叫发布公开的监听器？
就是, 让 Brokers 和 Clients 们都可以或许知道的监听器, 你想想看,​​​listeners​​是 Broker 用来监听网络请求的
那么, 其他 Broker 大概客户端想要与它通讯, 则必要知道具体的 IPORT 吧？
以是, 为了让别人知道自己的监听器, 那么就必要公开出去, 当然这个公开的情势, 是通过 zk 来共享数据。
看看 broker 到 zk 节点​​/brokers/{brokerid}/ ​​下面的信息示例

• 默认环境下,​​advertised.listeners​​​不设置会自动利用​​listeners​​属性
  
• ​​advertised.listeners​​​不支持​​0.0.0.0​​​这种情势, 以是如果​​listeners​​​属性设置成​​0.0.0.0​​​，则必须设置​​advertised.listeners​​属性。具体请看示例 3
  由于​​​0.0.0.0​​是表现的是监听 Broker 上恣意的网卡的, 你将这个发布出去, 那么别的 Broker 和客户端怎么知道你具体的 ip 和端口呢？
  
• 可以同时配置多个, 并且用逗号隔开
  
• 可动态配置该属性
  

一文搞懂 Kafka 中的 listeners 和 advertised.listeners 以及其他通讯配置-CSDN博客

1. [root@localhost statefulset]# cat jettech-kafka-statefulset-prod.yaml
2. apiVersion: v1
3. kind: Service
4. metadata:
5.   labels: {name: jettech-kafka}
6.   name: jettech-kafka
7.   namespace: jettech-prod
8. spec:
9.   ports:
10.   #- {name: t9092, nodePort: 9092, port: 9092, protocol: TCP, targetPort: t9092}
11.   - {name: t9092, port: 9092, protocol: TCP, targetPort: t9092}
12.   - {name: t9093, port: 9093, protocol: TCP, targetPort: t9093}
13.   selector: {name: jettech-kafka}
14.   #type: NodePort
15.   #type: ClusterIP
16.   clusterIP: None
18. ---
19. apiVersion: apps/v1
20. kind: StatefulSet
21. metadata:
22.   labels: {name: jettech-kafka}
23.   name: jettech-kafka
24.   namespace: jettech-prod
25. spec:
26.   serviceName: "jettech-kafka"
27.   replicas: 1
28.   selector:
29.     matchLabels: {name: jettech-kafka}
30.   template:
31.     metadata:
32.       labels: {name: jettech-kafka}
33.       name: jettech-kafka
34.     spec:
35.       affinity:
36.         nodeAffinity:
37.           requiredDuringSchedulingIgnoredDuringExecution:
38.             nodeSelectorTerms:
39.             - matchExpressions:
40.               - key: kubernetes.io/hostname
41.                 operator: In
42.                 values:
43.                 - 172.16.10.49
44.       initContainers:
45.       #hostname: jettech-kafka-controller01
46.       #subdomain: p-kfk-con1
47.       containers:
48.       - name: jettech-kafka
49.         image: harbor.jettech.com/jettechtools/kafka:3.9.0
50.         env:
51.         - {name: KAFKA_KRAFT_MODE, value: 'true'}
52.         - {name: KAFKA_PROCESS_ROLES, value: 'broker,controller'}
53.         - {name: KAFKA_NODE_ID, value: '1'}
54.         - {name: KAFKA_LISTENERS, value: 'PLAINTEXT://:9092,CONTROLLER://:9093'}
55.         - {name: KAFKA_ADVERTISED_LISTENERS, value: 'PLAINTEXT://jettech-kafka.jettech.com:9092,CONTROLLER://jettech-kafka.jettech.com:9093'}
56.         - {name: KAFKA_INTER_BROKER_LISTENER_NAME, value: 'PLAINTEXT'}
57.         - {name: KAFKA_CONTROLLER_LISTENER_NAMES, value: 'CONTROLLER'}
58.         - {name: KAFKA_LISTENER_SECURITY_PROTOCOL_MAP, value: 'PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT'}
59.         - {name: KAFKA_CONTROLLER_QUORUM_VOTERS, value: '1@jettech-kafka.jettech.com:9093'}
60.         - {name: KAFKA_LOG_DIRS, value: '/var/lib/kafka/data'}
61.         - {name: KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR, value: '1'}
62.         - {name: KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR, value: '1'}
63.         - {name: KAFKA_TRANSACTION_STATE_LOG_MIN_ISR, value: '1'}
64.         - {name: KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS, value: '1'}
65.         - {name: KAFKA_BROKER_ID, value: '1'}
66.         - {name: KAFKA_NUM_PARTITIONS, value: '1'}
67.         securityContext:
68.           privileged: true
69.         ports:
70.         - {containerPort: 9092, name: t9092, protocol: TCP}
71.         - {containerPort: 9093, name: t9093, protocol: TCP}
72.         volumeMounts:
73.         - name: jettech-kafka-data
74.           mountPath: /var/lib/kafka/data
75.         - name: host-time
76.           mountPath: /etc/localtime
77.         imagePullPolicy: Always #[Always | Never | IfNotPresent]
78.       tolerations:
79.       - key: type
80.         operator: Equal
81.         value: db
82.         effect: NoSchedule
83.       hostNetwork: true
84.       dnsPolicy: ClusterFirstWithHostNet
85.       restartPolicy: Always #Never
86.       volumes:
87.       - name: jettech-kafka-data
88.         #nfs:
89.         #  server: 192.168.99.42
90.         #  path: /data/jettechproduct/jettech/prod/kafka8.0/data
91.         hostPath:
92.           path: /data/jettechproduct/jettech/prod/kafka/data
93.       - name: host-time
94.         hostPath:
95.           path: /etc/localtime

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。