このページは、まだ日本語ではご利用いただけません。翻訳中です。
Migrate a self-managed zone control plane to Kong Konnect
If you already have zone control planes in Kong Mesh, you can migrate them to Konnect in Mesh Manager. Mesh Manager allows you to create, manage, and view your Kong Mesh service meshes using the Konnect platform.
Here are a few benefits of creating a mesh deployment in Konnect instead of using a self-managed setup:
- Kong-managed global control plane: By creating your mesh in Konnect, your global control plane is managed by Kong.
- All entities in one place: You can view all your information, such as entities from Kong Ingress Controller (KIC) for Kubernetes, Konnect-managed entities, and now service mesh data, all from one central platform.
- Managed UI wizard setup: Konnect simplifies the process of creating a mesh by providing a setup wizard in the UI that guides you through the configuration steps.
This guide explains how to migrate a self-managed zone control plane to Kong Konnect.
Figure 1: Diagram that explains how the Kong Mesh global control plane communicates with zone control planes, services, and data planes before migrating. Each service has an associated data plane proxy and those communicate with the zone control plane. The zone control plane then communicates with the Kong Mesh global control plane. All of these entities are self-managed.
Figure 2: Diagram that explains how the Konnect global control plane communicates with zone control planes, services, and data planes after migrating. Each service has an associated data plane proxy and those communicate with the zone control plane. The services, data plane proxies, and zone control planes are all self-managed. The zone control plane then communicates with the Konnect global control plane, which is managed by Kong.
Limitation
This guide assumes you are migrating zones from the self-managed global control plane to Kong Konnect one by one. In Kong Mesh, service discovery between zones works by to syncing Zone Ingresses from zone to global. This means that if you have multiple zones that you are migrating, services in zone-1 won’t be able to communicate with services in zone-2 while you’re migrating zone-1 because the Zone Ingress from zone-2 is not synced yet to Kong Konnect.
Prerequisites
- A universal or Kubernetes cluster with a running zone control plane connected to the self-managed global control plane
- The latest version of kumactl installed and configured to communicate with the self-managed global control plane
- A Kong Mesh global control plane in Konnect
- yq installed
Transfer resources from the self-managed global control plane to Konnect
- Make sure the self-managed global control plane is active:
kumactl config control-planes list
This should return your self-managed global control plane. If you are using Kubernetes, you can run
kubectl port-forward deployment/mesh-cp-name -n mesh-namespace 5681
to get quick access withkumactl
. -
Get the service mesh resources and policies for each service mesh. The following script provides an example of which resources are required:
#!/bin/bash outdir="policies" mkdir -p ${outdir} types="circuit-breakers external-services fault-injections healthchecks meshaccesslogs meshcircuitbreakers meshfaultinjections meshgateways meshgatewayroutes meshhealthchecks meshhttproutes meshloadbalancingstrategies meshproxypatches meshratelimits meshretries meshtcproutes meshtimeouts meshtraces meshtrafficpermissions proxytemplates rate-limits retries timeouts traffic-logs traffic-permissions traffic-routes traffic-traces virtual-outbounds access-role-bindings access-roles accessaudits meshglobalratelimits meshopas opa-policies" meshes=$(kumactl get meshes -oyaml | yq '.items[].name') # For each service mesh we produce a single file ${mesh}.yaml that contains all the policies of the mesh including # the mesh resource itself for mesh in ${meshes}; do kumactl get mesh ${mesh} -oyaml | yq '(del(.creationTime,.modificationTime))' > "${outdir}/${mesh}.yaml" echo "---" >> "${outdir}/${mesh}.yaml" for type in ${types}; do kumactl get ${type} --mesh ${mesh} -oyaml | yq '.items[] |= (del(.creationTime,.modificationTime)) | .items[] | split_doc' | grep ^ >> "${outdir}/${mesh}.yaml" && echo "---" >> "${outdir}/${mesh}.yaml" done done
- If mTLS is enabled on the mesh and the backend type is
builtin
orprovided
, then copy the mesh secrets:-
Builtin: Copy secrets named
{mesh_name}.ca-builtin-cert-{backend_name}
and{mesh_name}.ca-builtin-key-{backend_name}
. For more information, see storage of secrets. - Provided: Copy secrets specified in the mesh resource. For more information, see usage of “provided” CA.
-
Builtin: Copy secrets named
- Switch the active
kumactl
control plane to Konnect:kumactl config control-planes switch --name {config}
- Apply resources fetched from the self-managed global control plane in steps 2 and 3:
kumactl apply -f {file_name}
Connect the zone control plane to Konnect
-
Create a new zone in Konnect. The name of the new zone should match the zone from Kong Mesh that we’re connecting to. Be sure to override your existing zone control plane
values.yaml
configuration with the values provided in the Konnect UI wizard. - If KDS TLS is enabled with self-signed certificates, set
kuma.controlPlane.tls.kdsZoneClient.secretName=""
so the zone control plane can use public certificates to authenticate with Konnect:kumactl install control-plane \ --set "kuma.controlPlane.tls.kdsZoneClient.secretName=kds-ca-certs" \ | kubectl apply -f -
- Restart the zone control plane with the new values. Konnect will automatically start looking for the zone. Once Konnect finds the zone, it will display it in the UI.