Documentación de Oracle Cloud Infrastructure

Migración a clusters nativos de VCN

Descubra cómo migrar un cluster para integrar su punto final de API de Kubernetes en su propia VCN mediante Kubernetes Engine (OKE).

En versiones anteriores (antes del 16 de marzo de 2021), Kubernetes Engine aprovisionaba clusters con puntos finales de API de Kubernetes que no estaban integrados en su propia VCN. El punto final de API de Kubernetes era público y no podía restringir el acceso a él. Puede continuar creando dichos clusters mediante la CLI o API (hasta la fecha especificada en el anuncio de cambio de servicio aquí), pero no la consola.

Después del 16 de marzo de 2021, Kubernetes Engine puede aprovisionar clusters con sus puntos finales de API de Kubernetes en una subred de su propia VCN (estos clusters se conocen como "clusters nativos de VCN"). Tiene más flexibilidad para configurar clusters nativos de VCN para cumplir sus propios requisitos de seguridad y red. Puede configurar el punto final de API de Kubernetes para que sea de acceso privado dentro de su VCN (y una red local conectada) o para que sea de acceso público desde Internet:

  • Para hacer que el punto final de API de Kubernetes sea de acceso privado, aloje el punto final de API de Kubernetes en una subred privada y no le asigne una dirección IP pública.
  • Para que el punto final de API de Kubernetes sea accesible públicamente desde Internet, aloje el punto final de API de Kubernetes en una subred pública y asígnele una dirección IP pública.

Puede controlar el acceso a la subred de punto final de API de Kubernetes mediante reglas de seguridad definidas para grupos de seguridad de red (recomendado) o listas de seguridad.

Para aprovechar el control de seguridad que ofrecen los clusters nativos de VCN, puede migrar un cluster existente para integrar su punto final de API de Kubernetes en su propia VCN.

La migración de cluster tiene las siguientes etapas:

  • Etapa 1: Migrar el cluster

    Para iniciar la migración, seleccione el cluster que desea migrar y, a continuación, especifique la VCN existente y la subred pública o privada para alojar el nuevo punto final de API de Kubernetes. La migración suele tardar unos 15 minutos.

    Durante este tiempo, la API de Kubernetes sigue siendo accesible a través del punto final público original que no está integrado en su propia VCN. Sin embargo, las operaciones de ciclo de vida del cluster (como actualizaciones de cluster, creación y supresión de pools de nodos) no están disponibles.

    Consulte Migración de un cluster existente a un cluster nativo de VCN.

  • Etapa 2: Configurar el acceso al cluster migrado

    Cuando se completa la migración, se puede acceder al cluster a través del nuevo punto final de API de Kubernetes en su propia VCN, así como a través del punto final de API de Kubernetes público original que no está integrado en su VCN. Ahora puede actualizar la configuración de sus kubectl, herramientas y pipelines de integración y despliegue continuos para utilizar el nuevo punto final de API de Kubernetes.

    Para verificar que ha actualizado correctamente kubectl, las herramientas y los pipelines de integración y despliegue continuos, tiene la opción de retirar temporalmente el punto final público original de la API de Kubernetes, probar que las configuraciones actualizadas utilizan el nuevo punto final de la API de Kubernetes y, a continuación, revertir la retirada del punto final original.

    Consulte Configuración del acceso a un cluster migrado.

  • Etapa 3: Retire el punto final público original de la API de Kubernetes que no está integrado en su propia VCN

    Cuando esté seguro de que ha actualizado correctamente 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 en su propia VCN, puede retirar el punto final de API de Kubernetes público original que no está integrado en su VCN. Al retirar el punto final de API de Kubernetes original, solo se puede acceder al cluster a través del nuevo punto final de API de Kubernetes. El desmantelamiento suele tardar menos de cinco minutos.

    Tenga en cuenta que si no retira explícitamente el punto final original, el cluster seguirá siendo accesible tanto a través del punto final original como del nuevo punto final.

    Una vez retirado el punto final original, tiene varios días en los que puede revertir el cierre definitivo y volver a activar ese punto final original. El período de rollback por defecto es de 30 días, pero puede aumentarlo a un máximo de 60 días.

    Consulte Rechazo del punto final público original de la API de Kubernetes de un cluster migrado.

Migración de un cluster existente para que sea nativo de VCN

Uso de la consola

Para migrar un cluster existente para que sea nativo de VCN, haciéndolo accesible a través de un nuevo punto final de API de Kubernetes en su VCN:

  1. En la página de lista Clusters, seleccione el nombre del cluster que desea migrar. Si necesita ayuda para encontrar la página de lista o el cluster, consulte Listing Clusters.

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

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

  2. Si desea que el punto final de API de Kubernetes del cluster sea accesible públicamente desde Internet y alojado en una nueva subred pública en la misma VCN que el cluster (creación y configuración de nuevos recursos de red según sea necesario), realice una migración automática de la siguiente manera:
    1. En la parte superior del separador Detalles de cluster, seleccione 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 de CIDR 10.0.0.0/28, junto con listas de seguridad y tablas de rutas.
    3. Seleccione 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. Seleccione Migrar para crear nuevos recursos de red y migrar el cluster.

      Kubernetes Engine comienza a migrar el cluster, como se muestra en el cuadro de diálogo Migración de cluster.

    5. Seleccione Cerrar para cerrar el recuadro de diálogo Migración de Cluster.
  3. Si desea que el punto final de API de Kubernetes del cluster sea de acceso privado dentro de la VCN o de acceso público desde Internet, y que 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 manera:
    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): Para ver configuraciones de ejemplo, consulte Example Network Resource Configurations.
    2. En la parte superior del separador Detalles de cluster, seleccione 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. Seleccione 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 del API de Kubernetes siempre tiene asignada una dirección IP privada. Si especifica una subred pública, también puede exponer el punto final de API de Kubernetes a Internet asignando una dirección IP pública al punto final (así como 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 en la red para controlar la circulación: si lo desea, restrinja el acceso al punto final de API de Kubernetes del cluster mediante uno o varios grupos en la 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 del API: si ha seleccionado una subred pública para el punto final del API de Kubernetes, puede exponer opcionalmente el punto final a Internet asignando 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. Seleccione Migrar para crear nuevos recursos de red y migrar el cluster.

      Kubernetes Engine comienza a migrar el cluster.

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

Una vez finalizada la migración, el separador 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.

Un mensaje indica que el cluster se ha migrado y está pendiente de la retirada del punto final de API pública. En este punto, se puede acceder al cluster recién migrado mediante el nuevo punto final de API de Kubernetes en la VCN y mediante el punto final de API de Kubernetes público original que no está integrado en su propia VCN.

Uso de la CLI

Utilice el comando oci ce cluster-migrate-to-native-vcn y los parámetros necesarios para migrar un cluster existente para integrar su punto final de API de Kubernetes en su propia VCN:

oci ce cluster cluster-migrate-to-native-vcn --cluster-id <cluster-ocid> --endpoint-config "{\"subnetId\":\"<kube-api-endpoint-subnet-ocid>\"}" [OPTIONS]

Para obtener una lista completa de parámetros y valores para los comandos de la CLI, consulte la Referencia de comandos de la CLI.

Uso de la API

Ejecute la operación ClusterMigrateToNativeVcn para migrar un cluster a fin de integrar su punto final de API de Kubernetes en su propia VCN.

Configuración del acceso a un cluster migrado

Tras 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, deseará actualizar el archivo de configuración de Kubernetes del cluster (conocido comúnmente como archivo "kubeconfig") para permitir el acceso al cluster migrado mediante kubectl, como se describe en este tema. También debe actualizar cualquier archivo de manifiesto que incluya referencias a la dirección IP de punto final de API de Kubernetes original 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 en la que normalmente ejecuta 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 Setting Up Cluster Access.

  2. Verifique que kubectl se pueda conectar al cluster mediante el nuevo punto final de API de Kubernetes del cluster 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 nuevo punto final de API de Kubernetes del cluster.

Nota

Hasta que se anule el cierre del punto final de API original que no está integrado en la VCN, puede seguir generando el archivo kubeconfig original omitiendo la opción --kube-endpoint del comando oci ce cluster create-kubeconfig.

Desactivación del punto final de API pública de Kubernetes original de un cluster migrado

Uso de la consola

Para retirar el punto final de API de Kubernetes público original que no está integrado en su propia VCN:

  1. En la parte superior del separador Detalles de cluster, seleccione Rechazar cuando desee:

    • Anule temporalmente el punto final original, pruebe que las configuraciones actualizadas utilizan el nuevo punto final de API de Kubernetes y, a continuación, anule la retirada.
    • Desactivar permanentemente el punto final original.

    El desmantelamiento suele tardar menos de cinco minutos en completarse. Cuando se completa la retirada, se agrega un período de rollback por defecto de 30 días. Durante el período de rollback, puede:

    • restaurar el punto final original
    • ampliar el período de rollback
    Importante

    Cuando finaliza el período de rollback, ya no puede realizar un rollback de la retirada del punto final original. El punto final original se ha retirado permanentemente y el proceso de retirada no se puede revertir.

  2. (Opcional) Seleccione Anular para realizar un rollback de la retirada y restaurar el punto final original. El rollback suele tardar menos de cinco minutos en completarse.
  3. (Opcional) Seleccione Ampliar fecha límite de rollback para aumentar el período de rollback a un máximo de 60 días.

Uso de la CLI

Utilice el comando oci ce cluster start-public-api-endpoint-decommission y los parámetros necesarios para retirar el punto final original de un cluster:

oci ce cluster start-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Utilice el comando oci ce cluster rollback-public-api-endpoint-decommission y los parámetros necesarios para realizar un rollback de la retirada del punto final original de un cluster:

oci ce cluster rollback-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Utilice el comando oci ce cluster extend-endpoint-decommission-rollback-deadline y los parámetros necesarios para aumentar el período de rollback al retirar el punto final original de un cluster:

oci ce cluster extend-endpoint-decommission-rollback-deadline --cluster-id <cluster-ocid> --rollback-deadline-delay <duration> [OPTIONS]

donde --rollback-deadline-delay <delay> especifica una duración en formato ISO 8601. Por ejemplo, --rollback-deadline-delay P10d para aumentar el período de rollback en 10 días.

Para obtener una lista completa de parámetros y valores para los comandos de la CLI, consulte la Referencia de comandos de la CLI.

Preguntas frecuentes sobre la migración de clusters

Definición de clusters nativos VCN

Kubernetes Engine crea clusters de Kubernetes completamente integrados en la red virtual en la nube (VCN) de Oracle Cloud Infrastructure. Los nodos de trabajador, los equilibradores de carga y el punto final de API de Kubernetes forman parte de su propia VCN, y puede configurarlos como públicos o privados. Estos clusters que están totalmente integrados en su propia VCN se conocen como "cluster nativo VCN".

¿Cómo puedo saber si un cluster ya es un cluster nativo de VCN?

Si no está seguro de si un cluster ya es un cluster nativo de VCN, consulte la información sobre el cluster (por ejemplo, en el separador Detalles de cluster de la consola). Si el cluster ya es un cluster nativo de VCN, los detalles del cluster incluyen información de punto final de API de Kubernetes. Si el cluster aún no es un cluster nativo de VCN, los detalles del cluster simplemente incluyen la dirección de Kubernetes.

¿Tengo que migrar todos mis clusters existentes?

No, solo tiene que migrar los clusters existentes que desea convertir en clusters nativos de VCN. Si no desea integrar el punto final de API de Kubernetes de un cluster en su propia VCN, simplemente no migre ese cluster.

¿La migración implica algún tiempo de inactividad?

Mientras se migra un cluster a un cluster nativo de VCN, la API de Kubernetes del cluster sigue siendo accesible a través del punto final público original que no está integrado en su propia VCN. Sin embargo, las operaciones de ciclo de vida del cluster (como actualizaciones de cluster, creación y supresión de pools de nodos) no están disponibles.

¿Debo elegir la migración automática o la migración personalizada?

La migración automática crea una 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. La subred es pública y el punto final de API tiene asignada una dirección IP pública. La migración automática solo soporta clusters con pools de nodos en el mismo compartimento que el cluster. Para los clusters con pools de nodos en diferentes compartimentos, realice una migración personalizada.

La migración personalizada permite seleccionar una subred regional pública o privada existente para alojar el punto final de API de Kubernetes del cluster. Si selecciona una subred regional pública, puede mostrar opcionalmente el punto final de API de Kubernetes a Internet asignando una dirección IP pública al punto final. Opcionalmente, puede seleccionar el uso de grupos de seguridad de red.

¿Cómo configuro una subred de mi VCN para alojar el punto final de API de Kubernetes?

Consulte Configuración de recursos de red para la creación y el despliegue de clusters para obtener más información sobre la configuración de la subred de punto final de API de Kubernetes, las listas de seguridad y la tabla de rutas.

Quiero probar la migración a un cluster nativo de VCN. ¿Cómo puedo crear un cluster con un punto final de API de Kubernetes que no esté integrado en mi VCN?

En la ventana de terminal donde normalmente ejecuta los comandos de la CLI de Oracle Cloud Infrastructure (y hasta la fecha especificada en el anuncio de cambio de servicio aquí), ejecute el siguiente comando para crear un cluster de prueba con un punto final de API de Kubernetes que no esté integrado en la VCN:

oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version v<kubernetes-version-number> --name <cluster-name> --vcn-id <vcn-ocid>

donde:

  • --compartment-id <compartment-ocid> es el OCID del compartimento al que desea que pertenezca el cluster de prueba.
  • --kubernetes-version v<kubernetes-version-number> es una versión soportada de Kubernetes (consulte Versiones de Kubernetes actualmente soportadas). Por ejemplo, --kubernetes-version v1.19.7
  • --name <cluster-name> es el nombre que elija para el cluster de prueba. Por ejemplo, --name test-vcn-native-migration
  • --vcn-id <vcn-ocid> es el OCID de la VCN en la que se va a crear el cluster de prueba.

Una vez creado un cluster de prueba con un punto final de API de Kubernetes que no está integrado en la VCN, ahora puede migrar el cluster de prueba para convertirlo en un cluster nativo de VCN. Consulte Migración de un cluster existente para que sea nativo de VCN.

Recuerde suprimir el cluster de prueba cuando ya no lo necesite.