KCP: Как перейти на Confluent Cloud за дни, а не недели

Хотя Apache Kafka® невероятно мощна, самостоятельное управление брокерами, обновлениями, емкостью, безопасностью и инцидентами может быстро отвлечь команды от того, что действительно важно: создания приложений реального времени и обеспечения бизнес-ценности.

Confluent Cloud может снять это операционное бремя, однако миграция все еще может казаться рискованной и утомительной. Именно поэтому мы разработали более простой способ для клиентов перенести свои рабочие нагрузки Kafka в Confluent Cloud, используя Cluster Linking для репликации данных и новый инструмент с открытым исходным кодом под названием KCP. В этой статье мы расскажем, как работает KCP и как этот новый подход позволяет перейти на Confluent Cloud за считанные дни вместо недель.

Традиционная миграция Apache Kafka®

Миграции Kafka в прошлом часто требовали таких усилий, что многие команды предпочитали оставаться на «достаточно хороших» платформах Kafka, вместо того чтобы переходить на что-то лучшее.

Команды тратят недели на ручную инвентаризацию кластеров, распутывание списков контроля доступа (ACL), схем и коннекторов, а также на ручное создание сложной инфраструктуры как кода (IaC). Как только эта гора работы проделана, им все еще приходится координировать рискованные ночные переключения, для которых необходимо остановить, перенастроить и перезапустить каждого клиента.

Современные миграции не обязательно должны выглядеть так. Типичную миграцию можно разбить на четыре этапа: обнаружение и планирование, подготовка инфраструктуры, миграция данных и миграция клиентов.

Более простой способ миграции Kafka: от обнаружения и планирования до подготовки, миграции данных и миграции клиентов

Confluent предлагает Cluster Linking — полностью управляемый сервис репликации данных «байт в байт», который сохраняет смещения (offsets). Это устраняет необходимость управления инфраструктурой репликации и позволяет клиентам беспрепятственно переключаться, продолжая работу с того места, на котором они остановились. Cluster Linking упрощает перемещение данных из любой самостоятельно управляемой среды Kafka или размещенного сервиса Kafka.

Но миграция — это не только данные. Как насчет коннекторов, ACL, схем и остального рабочего процесса миграции? Как сделать каждый шаг проще? Именно здесь на помощь приходит KCP.

Что такое KCP?

KCP — это инструмент с открытым исходным кодом, созданный Confluent для оркестрации всего процесса миграции. KCP координирует обнаружение, подготовку и миграцию между кластерами, чтобы вы могли перейти на Confluent Cloud за дни, а не недели, без ручных и подверженных ошибкам шагов.

Сегодня KCP поддерживает миграцию из Amazon Managed Streaming for Apache Kafka (MSK) в Confluent Cloud. Поддержка миграции из самостоятельно управляемой Kafka появится в ближайшее время.

KCP управляет облачными технологиями и сервисами «под капотом», поэтому это единственный инструмент, с которым вам нужно взаимодействовать во время миграции. Вот как это работает:

• Обнаружение и планирование: С помощью не более пяти команд KCP автоматически обнаруживает ваши размещенные кластеры Kafka в выбранных регионах Amazon Web Services (AWS) и сканирует каждый кластер для создания подробной инвентаризации. Это включает пропускную способность, оценочные затраты, настройку сети, механизмы аутентификации, топики, ACL, схемы, коннекторы и клиентов, предоставляя полное представление о вашей существующей среде на основе данных перед миграцией. Вы также можете визуализировать эти данные в пользовательском интерфейсе (UI) KCP для более простого анализа.

Обнаружение и планирование: С помощью не более пяти команд KCP автоматически обнаруживает ваши размещенные кластеры Kafka в выбранных регионах Amazon Web Services (AWS) и сканирует каждый кластер для создания подробной инвентаризации. Это включает пропускную способность, оценочные затраты, настройку сети, механизмы аутентификации, топики, ACL, схемы, коннекторы и клиентов, предоставляя полное представление о вашей существующей среде на основе данных перед миграцией. Вы также можете визуализировать эти данные в пользовательском интерфейсе (UI) KCP для более простого анализа.

• Подготовка инфраструктуры: Как только вы поймете свою существующую настройку, KCP поможет сопоставить ее с эквивалентной архитектурой Confluent Cloud. Он генерирует необходимые скрипты Terraform для подготовки вашей среды Confluent Cloud, включая сетевые компоненты, такие как AWS PrivateLink, чтобы целевая инфраструктура была готова до перемещения каких-либо данных. Это снижает риск и барьер входа, позволяя настроить безопасную, готовую к работе среду без необходимости глубоких знаний в области сетей.

Подготовка инфраструктуры: Как только вы поймете свою существующую настройку, KCP поможет сопоставить ее с эквивалентной архитектурой Confluent Cloud. Он генерирует необходимые скрипты Terraform для подготовки вашей среды Confluent Cloud, включая сетевые компоненты, такие как AWS PrivateLink, чтобы целевая инфраструктура была готова до перемещения каких-либо данных. Это снижает риск и барьер входа, позволяя настроить безопасную, готовую к работе среду без необходимости глубоких знаний в области сетей.

• Миграция данных: KCP обрабатывает миграцию данных топиков Kafka, а также миграцию ACL, схем и коннекторов, сопоставляя их с ресурсами Confluent Cloud и автоматически генерируя скрипты Terraform для их развертывания. Для данных топиков он генерирует скрипты Terraform, которые подготавливают необходимую инфраструктуру миграции, использующую Cluster Linking для беспрепятственного перемещения данных топиков из ваших существующих кластеров в Confluent Cloud.

Миграция данных: KCP обрабатывает миграцию данных топиков Kafka, а также миграцию ACL, схем и коннекторов, сопоставляя их с ресурсами Confluent Cloud и автоматически генерируя скрипты Terraform для их развертывания. Для данных топиков он генерирует скрипты Terraform, которые подготавливают необходимую инфраструктуру миграции, использующую Cluster Linking для беспрепятственного перемещения данных топиков из ваших существующих кластеров в Confluent Cloud.

• Миграция клиентов: В первой половине 2026 года KCP предложит единую команду для миграции клиентов. Используя Confluent Cloud Gateway, KCP позволит командам клиентов мигрировать любую группу клиентов — включая их топики, смещения, группы потребителей, ACL и многое другое — практически без изменений. Просто измените конечную точку шлюза с вашего исходного кластера на целевой, чтобы переключить всех клиентов одновременно.

Миграция клиентов: В первой половине 2026 года KCP предложит единую команду для миграции клиентов. Используя Confluent Cloud Gateway, KCP позволит командам клиентов мигрировать любую группу клиентов — включая их топики, смещения, группы потребителей, ACL и многое другое — практически без изменений. Просто измените конечную точку шлюза с вашего исходного кластера на целевой, чтобы переключить всех клиентов одновременно.

Вам не нужно быть экспертом в Cluster Linking, инфраструктуре Confluent Cloud или сетях AWS. KCP берет все это на себя, позволяя вам сосредоточиться на выполнении миграции, пока он заботится о подготовке инфраструктуры и оркестрации за кулисами.

Как выполнить ваш 4-этапный процесс миграции

Давайте посмотрим на KCP в действии и изучим, как он оркестрирует вашу миграцию в Confluent Cloud. Мы будем использовать Amazon MSK в качестве нашей размещенной среды Kafka.

Шаг 1. Обнаружьте вашу существующую настройку, чтобы спланировать миграцию.

Начните с создания полного и точного представления вашей существующей среды Kafka. Используйте KCP для создания единого файла состояния в процессе обнаружения, который будет использоваться для выполнения всех последующих этапов миграции.

Чтобы получить полное представление о вашей текущей настройке, KCP обнаруживает кластеры, топики, списки контроля доступа (ACL), коннекторы, схемы и клиенты, гарантируя, что ни одна деталь не будет упущена перед началом миграции.

Этап миграции Kafka №1: Использование процесса обнаружения KCP для сканирования кластеров, топиков, коннекторов, клиентов Kafka и многого другого

1a. Обнаружение вашей среды Kafka.

Сначала обнаружите вашу существующую настройку (кластеры и коннекторы MSK Connect) в одном или нескольких регионах одновременно с помощью следующей команды:

Эта команда сканирует все существующие кластеры в указанном регионе (или регионах), что особенно полезно в средах, где Kafka используют несколько команд. Она предоставляет высокоуровневый обзор всех доступных кластеров в различных регионах и создает:

• kcp-state.json — общий файл состояния, используемый для отчетов, пользовательского интерфейса и ресурсов миграции. Этот файл служит единственным источником достоверной информации для координации всего процесса миграции на всех этапах.

kcp-state.json — общий файл состояния, используемый для отчетов, пользовательского интерфейса и ресурсов миграции. Этот файл служит единственным источником достоверной информации для координации всего процесса миграции на всех этапах.

• cluster-credentials.yaml — шаблон с данными для подключения, необходимыми для более глубокого сканирования Kafka.

cluster-credentials.yaml — шаблон с данными для подключения, необходимыми для более глубокого сканирования Kafka.

1b. Оценка стоимости и нагрузки.

С помощью файла kcp-state.json вы можете создавать подробные отчеты о затратах.

KCP использует API AWS Cost Explorer и Amazon Cloudwatch для создания файлов в формате markdown, предоставляющих подробный обзор затрат исходного кластера, пропускной способности, хранилища и размеров, что помогает определить объем миграции и эффективно расставить приоритеты для кластеров.

ЗАПРОСИТЬ ОЦЕНКУ СТОИМОСТИ

Confluent может помочь вам еще больше, предоставив подробную оценку стоимости вашей миграции. Если вы хотите запросить ее, перейдите в Migration hub в Confluent Cloud, загрузите свой файл kcp-state.json и выберите «Request cost estimate». Это побудит представителя Confluent связаться с вами и предоставить детализированную разбивку затрат на основе вашего текущего состояния.

Вы также можете визуализировать эти данные в пользовательском интерфейсе KCP. Выполните следующую команду на машине, где установлен KCP, а затем загрузите созданный файл состояния в пользовательский интерфейс:

1c. Завершение инвентаризации.

Теперь, когда у нас есть общее представление о наших существующих кластерах и затратах, мы можем углубиться в обнаружение топиков, ACL, схем, клиентов и коннекторов. Используя файлы состояния и учетных данных, созданные на этапе обнаружения, KCP может обогатить инвентаризацию вашей среды по нескольким измерениям.

• Кластеры: KCP может собирать дополнительные сведения на уровне кластера, включая топики, идентификаторы кластеров, ACL, политики хранения, количество партиций и коэффициенты репликации. Используйте следующую команду, чтобы обогатить ваш файл состояния этой информацией; введите здесь учетные данные вашего кластера, чтобы позволить KCP выполнить детальное обнаружение кластера.

Кластеры: KCP может собирать дополнительные сведения на уровне кластера, включая топики, идентификаторы кластеров, ACL, политики хранения, количество партиций и коэффициенты репликации. Используйте следующую команду, чтобы обогатить ваш файл состояния этой информацией; введите здесь учетные данные вашего кластера, чтобы позволить KCP выполнить детальное обнаружение кластера.

• Схемы: Для обнаружения схем KCP может сканировать ваш Confluent Schema Registry и фиксировать все субъекты схем вместе с их настройками совместимости. Он поддерживает как неаутентифицированные подключения, так и подключения с базовой аутентификацией (Basic Auth) к Schema Registry. Вот пример подключения к неаутентифицированному локальному реестру схем.

Схемы: Для обнаружения схем KCP может сканировать ваш Confluent Schema Registry и фиксировать все субъекты схем вместе с их настройками совместимости. Он поддерживает как неаутентифицированные подключения, так и подключения с базовой аутентификацией (Basic Auth) к Schema Registry. Вот пример подключения к неаутентифицированному локальному реестру схем.

• Клиенты: KCP может провести инвентаризацию всех активных клиентов Kafka в вашей среде, включая продюсеров и консьюмеров. Он делает это путем сканирования логов брокера Kafka, хранящихся в Amazon S3, для идентификации активных клиентов. KCP анализирует строки TRACE KafkaApi для запросов FETCH и PRODUCE, извлекая метаданные клиента, такие как идентификатор клиента, топик, роль, тип аутентификации и субъект (principal).

Клиенты: KCP может провести инвентаризацию всех активных клиентов Kafka в вашей среде, включая продюсеров и консьюмеров. Он делает это путем сканирования логов брокера Kafka, хранящихся в Amazon S3, для идентификации активных клиентов. KCP анализирует строки TRACE KafkaApi для запросов FETCH и PRODUCE, извлекая метаданные клиента, такие как идентификатор клиента, топик, роль, тип аутентификации и субъект (principal).

Выполнение этих трех команд обогащает тот же файл kcp-state.json топиками, ACL, коннекторами, схемами и активными клиентами, предоставляя вам единый источник достоверной информации для планирования остальной части вашей миграции.

Этап 2. Подготовка инфраструктуры для мигрирующих кластеров.

Cluster Linking упрощает миграцию, обеспечивая перемещение данных из любого хостируемого кластера Kafka в любой кластер Confluent Cloud, независимо от используемого сетевого метода. Благодаря недавно представленной функции External Cluster Linking через PrivateLink, теперь вы можете напрямую подключить частный, самоуправляемый кластер Kafka или хостируемый кластер к частному кластеру Confluent Cloud через AWS PrivateLink. Также поддерживаются пиринговые соединения виртуальных частных облаков (VPC), Transit Gateway и миграция публичных кластеров.

Ранее для миграции из частных кластеров Kafka в частный кластер Confluent Cloud, поддерживаемый PrivateLink, требовалось создание промежуточного кластера (jump cluster) и выполнение двухэтапной передачи данных. С помощью External Cluster Linking через PrivateLink вы можете напрямую соединить оба кластера, используя обратный PrivateLink. Это включает развертывание сервиса конечных точек PrivateLink перед вашим кластером Kafka и создание Egress Endpoints в Confluent Cloud, которые имеют доступ к этому сервису.

Настройка Cluster Link, конфигурация PrivateLink и создание Egress Endpoints могут быть утомительными и сложными при выполнении вручную. К счастью, KCP автоматизирует подготовку всей инфраструктуры с помощью Terraform, включая сетевые компоненты и конфигурацию конечных точек, чтобы вы могли сосредоточиться непосредственно на самой миграции.

Как KCP автоматизирует подготовку сетевой инфраструктуры с помощью Terraform

Имея четкое представление о вашей существующей настройке, вы теперь можете использовать KCP для подготовки целевой среды Confluent Cloud и вспомогательной инфраструктуры. В общих чертах вы:

• Подготавливаете ресурсы Confluent Cloud, включая целевой кластер(ы), сеть (PrivateLink) и контроль доступа

Подготавливаете ресурсы Confluent Cloud, включая целевой кластер(ы), сеть (PrivateLink) и контроль доступа

• Разворачиваете инфраструктуру миграции, включая бастион-хосты, обратные прокси-серверы и необходимые элементы для Cluster Linking

Разворачиваете инфраструктуру миграции, включая бастион-хосты, обратные прокси-серверы и необходимые элементы для Cluster Linking

С помощью всего двух команд KCP может генерировать шаблоны IaC как для целевой среды Confluent Cloud, так и для инфраструктуры миграции, что позволяет выполнять развертывание согласованно, а не создавать ресурсы вручную. Вы выбираете сетевой шаблон, соответствующий вашему исходному кластеру и настройкам Confluent Cloud (например, общедоступный или PrivateLink); KCP создает правильные строительные блоки для поддерживаемых комбинаций.

Шаг второй миграции Kafka с помощью KCP: подготовка инфраструктуры

Целевая инфраструктура

Чтобы сгенерировать скрипт Terraform для целевой инфраструктуры, выполните команду create-asset target-infra:

Эта команда использует файл kcp-state.json и Amazon Resource Name (ARN) существующего кластера, который вы хотите перенести, а затем генерирует скрипты Terraform в каталоге confluent-cloud-infrastructure. Эти скрипты подготавливают среду Confluent Cloud и кластер Enterprise, формируя основу вашей целевой инфраструктуры.

Вы можете использовать существующее сетевое подключение или подготовить PrivateLink в рамках этого шага. В большинстве случаев рекомендуется создание нового подключения PrivateLink. KCP настроит необходимые VPC-эндпоинты в той же VPC, где находится ваш существующий кластер; вам просто нужно предоставить CIDR подсетей, в которых должны быть созданы эти эндпоинты.

После получения скрипта Terraform разверните их, выполнив следующую команду из каталога confluent-cloud-infrastructure:

Инфраструктура миграции

Теперь, когда целевая инфраструктура готова, мы можем использовать KCP для развертывания инфраструктуры миграции. Это включает в себя Cluster Linking и ресурсы AWS, необходимые для работы внешнего Cluster Linking через PrivateLink.

Чтобы сгенерировать скрипт Terraform для инфраструктуры миграции, выполните:

Эта команда использует сведения о кластере Confluent Cloud, сгенерированные командой target-infra, вместе с ARN кластера MSK для создания скриптов Terraform, которые подготавливают связь кластеров (cluster link) с именем migration-link.

KCP поддерживает несколько шаблонов миграции для адаптации к различным конфигурациям сети и аутентификации:

• MSK с аутентификацией SASL/SCRAM (общедоступные или частные эндпоинты). Если у вас не настроен SASL/SCRAM, легко добавить прослушиватель SASL/SCRAM исключительно для трафика Cluster Linking.

MSK с аутентификацией SASL/SCRAM (общедоступные или частные эндпоинты). Если у вас не настроен SASL/SCRAM, легко добавить прослушиватель SASL/SCRAM исключительно для трафика Cluster Linking.

• MSK с аутентификацией на основе управления идентификацией и доступом (IAM) с использованием шаблона кластера перехода (jump cluster).

MSK с аутентификацией на основе управления идентификацией и доступом (IAM) с использованием шаблона кластера перехода (jump cluster).

В приведенном выше примере показан подход с прямым связыванием кластеров с частным кластером MSK с аутентификацией SASL/SCRAM. Если SASL не является вариантом, вам придется пойти по пути кластера перехода. Здесь KCP также автоматизирует инфраструктуру кластера перехода.

Как KCP автоматизирует подготовку инфраструктуры кластера перехода при миграции размещенной Kafka в Confluent Cloud

Для получения дополнительной информации о том, как это работает, см. документацию KCP.

Шаг 3. Миграция данных из размещенной Kafka в Confluent Cloud.

После подготовки целевой инфраструктуры и инфраструктуры миграции вы можете перенести конфигурацию и данные: ACL, коннекторы, схемы и топики. Шаблон KCP каждый раз одинаков: генерируйте активы, а затем применяйте их контролируемым образом.

Шаг третий миграции Kafka с помощью KCP: миграция конфигураций и данных

Миграция разрешений на основе IAM и ACL

Используя ранее собранные данные обнаружения, KCP переносит как разрешения на основе IAM, так и ACL Kafka из вашего исходного кластера в Confluent Cloud. Субъекты IAM извлекаются из ранее захваченного инвентаря клиентов, а ACL Kafka сопоставляются непосредственно с метаданными уровня кластера.

KCP повторно использует тот же файл состояния kcp-state.json для преобразования этих существующих разрешений в их эквиваленты в Confluent Cloud, автоматически генерируя необходимые активы Terraform.

Вы можете либо применить все сгенерированные ACL, либо выборочно выбрать субъектов через пользовательский интерфейс KCP.

Миграция коннекторов Kafka

KCP обнаруживает как MSK Connect, так и самоуправляемые коннекторы, а затем помогает вам перенести их на полностью управляемые коннекторы Confluent Cloud. KCP не переносит сами коннекторы; он генерирует конфигурации коннекторов в формате JSON, чтобы вы могли использовать выбранный вами инструмент для миграции коннекторов.

Рекомендуемый инструмент — Connect Migration Utility, бесплатный инструмент с открытым исходным кодом на основе CLI, доступный на GitHub. Он обеспечивает управляемый процесс миграции от MSK Connect или самоуправляемых коннекторов к полностью управляемым коннекторам Confluent Cloud. Вы начинаете платить за управляемые коннекторы после завершения переключения, что обеспечивает путь миграции с низким уровнем риска.

Чтобы сгенерировать конфигурации JSON, выполните следующее:

Эта команда создает конфигурации коннекторов в формате JSON, которые затем могут быть использованы утилитой Connect Migration Utility. Утилита:

• Преобразует конфигурации в их эквиваленты полностью управляемых коннекторов Confluent Cloud

Преобразует конфигурации в их эквиваленты полностью управляемых коннекторов Confluent Cloud

• Обрабатывает изменения классов коннекторов с v1 на v2

Обрабатывает изменения классов коннекторов с v1 на v2

• Сохраняет смещения (offsets) коннекторов для обеспечения плавного перехода

Сохраняет смещения (offsets) коннекторов для обеспечения плавного перехода

Если вы предпочитаете подход IaC, KCP также может генерировать модули Terraform для каждого коннектора как для MSK Connect, так и для самоуправляемых коннекторов, позволяя вам применять их с использованием ваших существующих рабочих процессов IaC.

Репликация и экспорт схем

После этапа обнаружения KCP может перенести схемы, сгенерировав активы Terraform, которые настраивают экспортеры схем для репликации из вашего исходного реестра схем (Schema Registry) в Confluent Cloud.

Сгенерируйте активы миграции с помощью:

KCP создает папку migrate_schemas/, содержащую Terraform для экспортера, который непрерывно синхронизирует все схемы с Confluent Cloud, сохраняя контексты и настройки совместимости в том виде, в котором они существуют в исходном реестре.

Перенос данных топиков в Confluent Cloud с помощью Cluster Linking

Миграция топиков осуществляется с помощью Cluster Linking, при этом KCP генерирует скрипты Terraform и поддерживает конфигурацию, необходимую для вашей конкретной топологии.

KCP автоматизирует настройку всей необходимой инфраструктуры, включая связывание кластеров, чтобы вы могли беспрепятственно и надежно перемещать данные топиков из MSK в Confluent Cloud. Мы уже создали целевую инфраструктуру и инфраструктуру миграции; теперь мы начинаем перемещение данных, выполнив:

Эта команда генерирует скрипты Terraform в папке migration_infra/, которые:

• Создают связи кластеров между вашим существующим кластером и Confluent Cloud

Создают связи кластеров между вашим существующим кластером и Confluent Cloud

• Зеркалируют топики, поддерживая синхронизацию ваших данных, включая смещения групп потребителей, пока вы не будете готовы к переключению

Зеркалируют топики, поддерживая синхронизацию ваших данных, включая смещения групп потребителей, пока вы не будете готовы к переключению

Шаг 4. Миграция клиентов.

Миграция клиентов часто является самой сложной частью процесса миграции, не из-за технической сложности, а из-за межкомандной координации, необходимой для планирования и выполнения переключения клиентов.

Сегодня существует два распространенных подхода к миграции клиентов, каждый из которых имеет свои преимущества и недостатки.

• Для обеспечения плавного и предсказуемого процесса переключения клиентов пользователи могут использовать Cluster Linking для миграции. Этот подход сохраняет смещения (offsets), но требует небольшого времени простоя клиента для выполнения переключения.

Для обеспечения плавного и предсказуемого процесса переключения клиентов пользователи могут использовать Cluster Linking для миграции. Этот подход сохраняет смещения (offsets), но требует небольшого времени простоя клиента для выполнения переключения.

• Пользователи, которым необходимо выполнить миграцию без простоя, могут вместо этого использовать двойную запись (dual-produce) как в исходный, так и в целевой кластеры. Это требует более сложного управления смещениями во время миграции.

Пользователи, которым необходимо выполнить миграцию без простоя, могут вместо этого использовать двойную запись (dual-produce) как в исходный, так и в целевой кластеры. Это требует более сложного управления смещениями во время миграции.

Сегодня KCP может помочь с миграцией клиентов, сканируя журналы и создавая инвентаризацию активных клиентов с помощью команды kcp scan client-inventory. Однако большая часть процесса миграции клиентов по-прежнему выполняется вручную.

В первой половине 2026 года KCP значительно упростит этот этап благодаря совместимости с Confluent Cloud Gateway. Благодаря поддержке Confluent Cloud Gateway в KCP вы сможете подключить всех клиентов к конечной точке Gateway, а затем переключить всех клиентов одновременно, направив Gateway на ваш целевой кластер.

Шаг четвертый миграции Kafka с KCP: миграция клиентов Kafka с использованием Cluster Linking или двойной записи в исходный и целевой кластеры

Начните планирование миграции в Confluent Cloud с помощью KCP и Cluster Linking

KCP превращает зачастую сложный и ручной процесс миграции в оптимизированный автоматизированный рабочий процесс. Оркестрируя такие этапы, как обнаружение инвентаризации и оценка затрат, подготовка инфраструктуры, а также миграция данных и клиентов, KCP ускоряет сроки миграции и снижает объем работы и сложность процесса.

Переход на Confluent Cloud еще никогда не был таким простым. Начните работу с KCP сегодня, изучив документацию, посетив репозиторий GitHub и попробовав наш семинар по миграции, чтобы увидеть инструмент в действии. Как только вы сделаете эти первые шаги, Confluent сможет помочь вам еще больше: чтобы получить детальную разбивку затрат, просто перейдите в Migration hub в Confluent Cloud, загрузите свой файл kcp-state.json и выберите «Request cost estimate», чтобы представитель Confluent связался с вами для предоставления подробного анализа.

Если вы еще этого не сделали, зарегистрируйтесь для бесплатной пробной версии Confluent Cloud. Новые пользователи получают 400 долларов США на расходы в Confluent Cloud в течение первых 30 дней. Используйте код CLOUDBLOG60 для получения дополнительных 60 долларов США на бесплатное использование.

Apache®, Apache Kafka®, Kafka® и логотип Kafka являются зарегистрированными товарными знаками Apache Software Foundation. Использование этих знаков не подразумевает одобрения со стороны Apache Software Foundation.