Хотя 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 анализирует строки KafkaApi TRACE для запросов FETCH и PRODUCE, извлекая метаданные клиента, такие как идентификатор клиента, топик, роль, тип аутентификации и субъект (principal).
Клиенты: KCP может инвентаризировать всех активных клиентов Kafka в вашей среде, включая продюсеров и потребителей. Он делает это путем сканирования логов брокера Kafka, хранящихся в Amazon S3, для идентификации активных клиентов. KCP анализирует строки KafkaApi TRACE для запросов 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) и выполнение двухэтапной передачи данных. С помощью внешнего Cluster Linking через PrivateLink вы можете напрямую соединить оба кластера, используя обратный PrivateLink. Это включает развертывание службы конечных точек PrivateLink перед вашим кластером Kafka и создание конечных точек Egress в Confluent Cloud, которые имеют доступ к этой службе.
Установка Cluster Link, настройка PrivateLink и создание конечных точек Egress могут быть утомительными и сложными при выполнении вручную. К счастью, 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 автоматизирует настройку всей необходимой инфраструктуры, включая связующие компоненты Cluster Linking, чтобы вы могли легко и надежно переносить данные топиков из 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 сможет помочь вам еще больше: чтобы получить детальную разбивку затрат, просто перейдите в Центр миграции в Confluent Cloud, загрузите свой файл kcp-state.json и выберите «Запросить оценку стоимости», чтобы представитель Confluent связался с вами с подробным анализом.
Если вы еще этого не сделали, зарегистрируйтесь для бесплатной пробной версии Confluent Cloud. Новые пользователи получают 400 долларов на расходы в Confluent Cloud в течение первых 30 дней. Используйте код CLOUDBLOG60 для получения дополнительных 60 долларов на бесплатное использование.
Apache®, Apache Kafka®, Kafka® и логотип Kafka являются зарегистрированными товарными знаками Apache Software Foundation. Использование этих знаков не подразумевает одобрения со стороны Apache Software Foundation.
