我在kubernetes上运行kafka(部署在Azure上(，使用strimzi作为开发环境，并且更喜欢使用内部kubernete节点存储。如果我使用persistent-claim或jbod，它会在azure存储上创建标准磁盘。然而，我更喜欢使用内部节点存储，因为我有16gb可用。我不想使用短暂的，因为我希望数据至少在kubernetes节点上持久化。以下是我的部署。yml
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: kafka-cluster
spec:
kafka:
version: 3.1.0
replicas: 2
listeners:
- name: plain
port: 9092
type: internal
tls: false
- name: tls
port: 9093
type: internal
tls: true
- name: external
type: loadbalancer
tls: false
port: 9094
config:
offsets.topic.replication.factor: 2
transaction.state.log.replication.factor: 2
transaction.state.log.min.isr: 2
default.replication.factor: 2
min.insync.replicas: 2
inter.broker.protocol.version: "3.1"
storage:
type: persistent-claim
size : 2Gi
deleteClaim: false
zookeeper:
replicas: 2
storage:
type: persistent-claim
size: 2Gi
deleteClaim: false
entityOperator:
topicOperator: {}
userOperator: {}
使用persistent-claim存储时，它将使用默认存储类来配置存储，在您的情况下，我想它会创建标准存储。
如何使用工作节点的本地磁盘空间有两个选项：
- 您可以使用
ephemeral类型的存储。但请记住，这就像一个临时目录，在每次滚动更新时都会丢失。此外，如果您同时删除所有pod，则会丢失所有数据。因此，它只推荐用于CI中的一些短期集群，可能是一些短期开发等。但肯定不适用于任何需要可靠性的地方 - 您可以使用本地持久卷，它是绑定到特定节点的持久卷。这些是持久的，因此pod将在重新启动和滚动udpate之间重复使用卷。然而，它将pod绑定到存储所在的特定工作节点->因此您无法轻松地将其重新安排到另一个工作节点。但除了这些限制之外，如果操作得当，它还可以(与
ephemeral存储不同(以可靠性和可用性使用。本地持久卷通常也通过StorageClass进行配置->因此，在Strimzi中的Kafka自定义资源中，它仍将使用persistent-claim类型的存储，只是具有不同的存储类
你应该清楚地知道你到底想用什么以及为什么。根据我的经验，当
- 您在裸机/内部部署集群上运行，这些集群通常无法获得良好的共享块存储
- 当您需要最大性能时(本地存储不依赖于网络，因此通常速度更快(
但是，在支持高质量网络块存储的公共云中，如Amazon EBS卷及其Azure或Google对等卷，本地存储往往带来更多的问题而非优势，因为它将Kafka代理绑定到特定的工作节点。
有关本地持久卷的更多详细信息，请访问此处：https://kubernetes.io/docs/concepts/storage/volumes/#local。。。还有不同的提供程序可以帮助您使用它。我不确定Azure是否支持开箱即用的功能。
旁注：对于卡夫卡来说，2Gi的空间非常小。不确定在磁盘空间用完之前你能做多少。即使是16Gi也相当小。如果你知道你在做什么，那就好了。但如果没有，你应该小心