用云原生Kubernetes API管理混合云数据的详细指南

xcvxvxc
333 阅读9分钟

Confluent for Kubernetes（CFK）为集群链接增加了声明式API支持，允许你用声明式API连接公共和私有云环境。

Confluent for Kubernetes为部署和自我管理作为云原生系统的Confluent平台提供了一个完整的、声明式API驱动的体验。Cluster Linking是一个易于使用、安全和具有成本效益的数据迁移和地理复制解决方案，可以在你的混合架构中无缝、可靠地连接应用程序和数据系统。随着Confluent Platform 7.0的发布，Confluent宣布在Confluent Platform和Confluent Cloud中全面推出Cluster Linking。使用CFK的集群链接的声明式API，你现在可以用基础设施即代码（IaC）模型创建混合云环境。

这篇博客详细介绍了在开发集群链接的声明式API时面临的技术挑战，以及为提供最佳用户体验而做出的有主见的选择。这篇文章还展示了用CFK的Cluster Linking API建立混合云环境是多么简单和干净，它在Confluent Cloud中的Apache Kafka®集群--一种完全管理的、用于连接和处理所有实时数据的云原生服务--和一个由CFK管理的Kubernetes上的本地Confluent集群之间建立了集群链接，以将数据从本地集群迁移到云集群，展示了数据在私有云和公共云基础设施间的移动。

集群链接的声明式API

CFK的声明式API使您能够将基础设施管理交给Confluent的智能、基于软件的自动化，从而使您能够完全专注于您的实时业务应用。这些API使您能够以YAML文件集合的形式将您的基础设施状态和应用程序状态表达为代码。你可以将YAML文件检查到Git存储库中，这样你的团队就可以协作管理这些环境。通过CI/CD系统，YAML文件可以从Git中提取，将更新部署到开发、QA和生产中的Confluent环境。这整个范式被称为GitOps。

Confluent for Kubernetes提供了一个声明式的ClusterLink API来配置和管理集群链接。这个声明式的API允许你通过定义一个基于ClusterLink CustomResourceDefinition （CRD）的ClusterLinkCustomResource （CR）来定义集群链接的理想状态。然后，Confluent for Kubernetes会创建集群链接，并确保它保持CustomResource所定义的理想状态。

这些是ClusterLink声明式API中定义集群链接的组件。

  • 目的地Kafka集群：这定义了集群链接的目标集群。集群链接由目标集群管理，从源集群的角度来看，它只是一个消费者。要创建集群链接，你需要访问目的地集群的REST API端点信息以及认证信息（如果有）。KafkaRestClass声明性API封装了所有管理客户端的配置，包括认证和证书。ClusterLink CR在这个API中引用了kafkaRestClassRef 下的KafkaRestClass。这可以在Git仓库中维护，并且可以在任何其他需要REST管理客户端的CFK声明式API中重复使用，只需引用其名称即可。

  • 源Kafka集群：这描述的是集群链接的源集群，数据将从这里同步。它吸收了源集群的引导端点和可选的认证配置。声明式API的威力在此显而易见，你可以用几行字来定义源集群的认证和SSL证书，而不是用管理员客户端命令创建集群链接时需要设置的一系列配置，包括证书。

    在实现这个API的过程中，有一些有主见的选择，以达到最佳的用户体验。源配置的重要组成部分之一是认证和TLS信息。TLS证书可以通过将它们放在目标集群中并将该路径添加到配置中，或者通过将原始证书作为配置传递给集群来配置。选择通过secrets或HashiCorp Vault直接传递证书，因为它消除了额外的步骤，以确保证书存在于Kafka集群中，并避免了对Kafka CR的改变，以将证书装入Kafka经纪商，这反过来需要滚动Kafka集群。另一个决定是在这个API中接受一个clusterID 。虽然源集群的clusterID 可以从sourceKafkaCluster.kafkaRestClassRef ，但我们决定在API中接受clusterID，因为源集群不会在其网络之外开放REST管理端点的使用情况。

  • 镜像主题：Kafka中的消息被组织成主题。每个主题都有一个名称，在整个Kafka集群中是唯一的。在集群链接术语中，源集群将这些对象简单地称为 "主题"，而主题被镜像到的目标集群则将它们称为 "镜像主题"。这些是由集群链接维护的目标集群上的只读主题。镜像主题可以处于以下状态之一。ACTIVE,PAUSED,PENDING_STOPPED,STOPPED,SOURCE_UNAVAILABLE,LINK_FAILED,FAILED 。关于镜像主题状态的更多细节，请参考镜像主题文档。如果没有声明性的API，你必须运行一个管理员客户端命令来创建每个所需的镜像主题（可能还有第二个命令来设置镜像主题的状态）。但有了CFK的声明式API，你只需列出要镜像的主题和所需的状态（PAUSE,ACTIVE, 等等），剩下的就由Confluent for Kubernetes自动处理。在内部，这个主题变化API是一个状态机，需要根据镜像主题的当前状态，将所需的主题状态（ACTIVE,PAUSE, 等）转换为主题动作（RESUME,FAILOVER, 等），并抛出错误以处理无效的状态转换。像其他Kubernetes构造一样，ClusterLink CRD在其状态中维护集群链接的当前状态，包括镜像主题及其状态。状态机从状态中获取当前的镜像主题状态，从CR中获取期望的状态，并提出要采取的行动，使镜像主题达到期望状态。为了确保最佳的用户体验，决定从YAML文件中删除镜像主题，这就意味着在内部状态机中删除镜像主题，而删除整个集群链接则意味着集群链接的所有镜像主题的故障转移。

总的来说，开发一个声明式的API，提供最佳的用户体验，同时确保它对Confluent用户没有太多限制，这是一个有趣的技术挑战。一旦你有了CustomResource YAML文件，你所需要做的就是运行kubectl apply -f clusterlink.yaml 。你可以有多个ClusterLink定义，连接一个组织内的不同环境。所有这些YAML文件都可以在Git仓库中维护（GitOps模型），让你的团队使用可读的声明式API进行协作。

使用CFK和Confluent云的混合云环境

Hybrid cloud environment with CFK and Confluent Cloud

Confluent for Kubernetes为企业内部环境带来了运动中数据工作负载的云原生体验。它提供了简单性、灵活性和效率，而没有复杂的、与Kafka相关的基础设施操作的头痛和负担。Cluster Linking允许你通过安全、可靠和毫不费力地在企业内部和云环境之间创建一座桥梁来连接企业内部环境。Cluster Linking的声明式API通过提供一种云原生的方式来配置内部和云之间的桥梁，使这种组合更进一步。

下面的例子设置了一个混合云环境，在内部运行并由Confluent for Kubernetes管理的Confluent Platform和另一个在完全管理的Confluent Cloud上运行的Kafka集群之间配置了一个集群链接。在内部集群中产生的数据将被透明地复制到云集群中的相应主题。

apiVersion: platform.confluent.io/v1beta1
kind: ClusterLink
metadata:
  name: clusterlink-demo
  namespace: operator
spec:
  destinationKafkaCluster: 
    kafkaRestClassRef:
      name: krc-cloud
      namespace: operator
  sourceKafkaCluster:
    authentication:
      type: plain
      jaasConfig:
        secretRef: plainpassjks
    bootstrapEndpoint: clink.platformops.dev.gcp.devel.cpdev.cloud:9092
    kafkaRestClassRef:
      name: krc-cfk
      namespace: operator
  mirrorTopics:
    - name: demo-topic
---
apiVersion: platform.confluent.io/v1beta1
kind: KafkaRestClass
metadata:
  name: krc-cloud
  namespace: operator
spec:
  kafkaClusterRef:
    name: kafka
  kafkaRest:
    endpoint: https://pkc-cloud.us-west4.gcp.confluent.cloud:443
    kafkaClusterID: lkc-cloud
    authentication:
      type: basic
      basic:
        secretRef: restclass-ccloud
    tls:
      secretRef: ccloud-tls-certs

你可以通过上述CR在运行在Confluent Cloud上的Kafka集群中创建一个集群链接。请参考在Confluent云中创建Kafka集群和管理主题文档，了解如何创建集群和所需主题的说明。这个Kafka集群为外部监听器配置了SASL-SSL，这意味着在CFK中你需要配置相应的认证和TLS证书信息。这个集群的任何客户端，包括集群链接，都必须有正确的认证信息和证书。

ClusterLink demo

接下来，你使用CFK在内部部署了Confluent平台。Confluent平台的CustomResource文件以及使用CFK建立集群的步骤都定义在这个GitHub仓库中。这将在SASL普通模式下建立一个Kafka集群和ZooKeeper。一旦内部集群建立并运行，你可以在云集群和内部集群之间建立集群链接。这将设置内部集群为源集群，云集群为目标集群，以同步来自镜像主题的消息，下面是一个快速演示：

Demo

通过这些简单的步骤，你就拥有了一个混合环境，数据以透明的方式从企业内部集群转移到云集群，企业内部和云资源以云原生的方式用CFK管理。

总结

构建Confluent for Kubernetes的目的是为了在所有环境中提供云原生的Confluent。Cluster Linking的建立是为了提供一个易于使用、安全和具有成本效益的数据迁移和地理复制解决方案，在你的混合架构中无缝和可靠地连接应用程序和数据系统。在集群链接的声明式API的支持下，用户有一个简单、干净和云原生的方式来建立一个混合云环境。如果你想用CFK建立一个混合云，请注册Confluent Cloud的免费试用，并下载Confluent Platform和CFK。你可以使用促销代码CL60BLOG ，获得额外的60美元的免费云使用权。

avatar
文章
阅读
粉丝