Migración a clusters nativos de VCN

Para migrar un cluster existente para integrar su punto final de API de Kubernetes en su propia VCN:

1. Abra el menú de navegación y haga clic en Servicios para desarrolladores. En Contenedores y artefactos, haga clic en Clusters de Kubernetes (OKE).

2. Seleccione un compartimento en el que tenga permiso para trabajar.

   Las etiquetas de migración necesaria aparecen en la página Lista de clusters junto a los nombres de clusters con puntos finales de API de Kubernetes que no están integrados en la VCN.

3. En la página Lista de clusters, haga clic en el nombre del cluster que desea migrar.

   Al seleccionar un cluster que puede migrar, aparece el botón Migrar cluster en la parte superior de la página Detalles de cluster.

4. Si desea que el punto final de API de Kubernetes del cluster sea accesible públicamente desde Internet y esté alojado en una nueva subred pública en la misma VCN que el cluster (creando y configurando nuevos recursos de red según sea necesario), realice una migración automática de la siguiente forma:
   1. En la parte superior de la página Detalles de cluster, haga clic en Migrar cluster para integrar el punto final de API de Kubernetes del cluster en su propia VCN.
   2. En el cuadro de diálogo Migrar a cluster nativo de VCN, seleccione Migración automática para crear una nueva subred regional en la VCN del cluster con un bloque CIDR 10.0.0.0/28, junto con listas de seguridad y tablas de rutas.
   3. Haga clic en Iniciar flujo de trabajo y revise el resumen de migración en el cuadro de diálogo Migración de cluster de punto final nativo de VCN.
   4. Haga clic en Migrar para crear nuevos recursos de red y migrar el cluster.

      Container Engine for Kubernetes inicia la migración del cluster, como se muestra en el cuadro de diálogo Migración de cluster.

   5. Haga clic en Cerrar para cerrar el recuadro de diálogo Migración de Cluster.
5. Si desea que el punto final de API de Kubernetes del cluster sea de acceso privado en la VCN o de acceso público desde Internet y esté alojado en una subred pública o privada regional existente en la misma VCN que el cluster, realice una migración personalizada de la siguiente forma:
   1. Confirme que los siguientes recursos de red ya existen en la VCN y están configurados correctamente para alojar el punto final de API de Kubernetes (si no, créelos y configúrelos correctamente):
      • una subred pública o privada regional (consulte Configuración de subred de punto final de API de Kubernetes)
      • si la subred es pública, un gateway de Internet (consulte Configuración de gateway de Internet)
      • si la subred es privada, un gateway de NAT (consulte Configuración de gateway de NAT) y un gateway de servicio (consulte Configuración de gateway de servicio)
      • una tabla de rutas con las reglas de ruta necesarias (consulte Tabla de rutas para subredes de punto final de API de Kubernetes)
      • un grupo de seguridad de red (recomendado) y/o una lista de seguridad con las reglas de entrada y salida necesarias (consulte Reglas de seguridad para el punto final de API de Kubernetes)

      Por ejemplo, configuraciones, consulte Configuración de recursos de red de ejemplo.

   2. En la parte superior de la página Detalles de cluster, haga clic en Migrar cluster para integrar el punto final de API de Kubernetes del cluster en su propia VCN.
   3. En el cuadro de diálogo Migrar a cluster nativo de VCN, seleccione Migración personalizada.
   4. Haga clic en Iniciar Flujo de Trabajo y especifique:
      • Subred de punto final de API de Kubernetes: subred regional para alojar el punto final de API de Kubernetes del cluster. La subred que especifique puede ser pública o privada. El punto final de API de Kubernetes siempre tiene asignada una dirección IP privada. Si especifica una subred pública, puede mostrar opcionalmente el punto final de API de Kubernetes a Internet mediante la asignación de una dirección IP pública al punto final (así como a la dirección IP privada). Para simplificar la gestión de acceso, Oracle recomienda que el punto final de API de Kubernetes se encuentre en una subred diferente a los nodos de trabajador y los equilibradores de carga. Para obtener más información, consulte Plano de control de cluster de Kubernetes y API de Kubernetes.
      • Utilizar grupos de seguridad de red para controlar el tráfico: opcionalmente, limite el acceso al punto final de API de Kubernetes del cluster mediante uno o varios grupos de seguridad de red (NSG) que especifique. Para obtener más información sobre las reglas de seguridad que se deben especificar para el NSG, consulte Reglas de seguridad para el punto final de API de Kubernetes.
      • Asignar una dirección IP pública al punto final de API: si ha seleccionado una subred pública para el punto final de API de Kubernetes, puede exponer opcionalmente el punto final a Internet mediante la asignación de una dirección IP pública al punto final (así como a la dirección IP privada). Si no asigna una dirección IP pública, actualice las reglas de ruta y las reglas de seguridad para permitir el acceso al punto final mediante un gateway de servicio y un gateway de NAT (consulte Configuración de subred de punto final de API de Kubernetes).
   5. Haga clic en Migrar para crear nuevos recursos de red y migrar el cluster.

      Container Engine for Kubernetes inicia la migración del cluster.

La migración suele tardar unos 15 minutos en completarse. Durante este tiempo, se sigue accediendo a la API de Kubernetes a través del punto final público que no está integrado en su propia VCN. Sin embargo, las operaciones del ciclo de vida del cluster (como las actualizaciones del cluster, la creación y supresión del pool de nodos) no están disponibles.

Una vez finalizada la migración, la página Detalles de cluster muestra el nombre de la subred de punto final de API de Kubernetes, la dirección IP del punto final privado de API de Kubernetes y (si ha asignado una dirección IP pública al punto final de API de Kubernetes) la dirección IP del punto final público de API de Kubernetes.

La página Detalles de cluster también indica que tiene 30 días para actualizar la configuración de kubectl, las herramientas y los pipelines de integración y despliegue continuos para acceder al nuevo punto final de API de Kubernetes (consulte Configuración del acceso a un cluster migrado). Durante este período de desmantelamiento, se puede acceder al cluster recién migrado mediante el nuevo punto final de API de Kubernetes en su VCN y mediante el punto final de API de Kubernetes público que no está integrado en su propia VCN.

Después de migrar un cluster para integrar su punto final de API de Kubernetes en su propia VCN, debe actualizar la configuración de kubectl, las herramientas y los pipelines de integración y despliegue continuos para utilizar el nuevo punto final de API de Kubernetes. Como mínimo, deberá actualizar el archivo de configuración de Kubernetes del cluster (comúnmente conocido como archivo 'kubeconfig') para permitir el acceso al cluster migrado mediante kubectl, como se describe en este tema. También debe actualizar los archivos de manifiesto que incluyan referencias a la dirección IP del punto final de API de Kubernetes del cluster.

Siga las instrucciones de este tema para generar un nuevo archivo kubeconfig. En estas instrucciones, se asume que el archivo kubeconfig del cluster se guarda en la ubicación por defecto ($HOME/.kube) y con el nombre por defecto (config). Si no es así, adapte las instrucciones en consecuencia.

1. En la ventana de terminal donde normalmente ejecuta los comandos de la CLI de Oracle Cloud Infrastructure, ejecute el siguiente comando para actualizar el archivo kubeconfig existente del cluster:

   oci ce cluster create-kubeconfig --cluster-id <cluster-ocid> --file <kubeconfig-file-location> --region <region-name> --token-version 2.0.0 --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT

   donde:

   • --cluster-id <cluster-ocid> es el OCID del cluster existente que desea que sea nativo de VCN.
   • --file <kubeconfig-file-location> es la ubicación del archivo kubeconfig del cluster.
   • --region <region-name> es la región en la que se encuentra el cluster.
   • --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT especifica si se debe agregar la dirección IP privada o la dirección IP pública del punto final de API de Kubernetes del cluster al archivo kubeconfig. Para obtener más información, consulte Plano de control de cluster de Kubernetes y API de Kubernetes.

   Por ejemplo:

   oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.phx.aaaaaaaaae... --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT

   Suponiendo que el archivo kubeconfig ya existe en la ubicación que especifique, los detalles del cluster se agregan como un nuevo contexto al archivo kubeconfig existente, incluido el nuevo punto final de API de Kubernetes del cluster en su propia VCN. El elemento current-context: del archivo kubeconfig se ha definido para que apunte al contexto recién agregado.

   Para obtener más información sobre la configuración del archivo kubeconfig, consulte Configuración del acceso al cluster.

2. Verifique que kubectl se puede conectar al cluster mediante el punto final de API de Kubernetes en su propia VCN introduciendo el siguiente comando:

   kubectl get nodes

   Se muestra información sobre los nodos del cluster.

   Ahora puede utilizar kubectl para realizar operaciones en el cluster mediante el punto final de API de Kubernetes en su propia VCN.