Migra contenedores a Google Cloud: migra proyectos de OpenShift a GKE Enterprise

Last reviewed 2022-01-24 UTC

Con este documento, podrás planificar, diseñar e implementar la migración de tus proyectos de OpenShift a GKE Enterprise. Si se hace de forma incorrecta, mover las cargas de trabajo de un entorno a otro puede ser una tarea desafiante, por lo que debes planificar y ejecutar la migración con cuidado.

Este documento es parte de una serie de varias partes sobre la migración a Google Cloud. Si te interesa ver una descripción general de la serie, consulta Migración a Google Cloud: elige tu ruta de migración.

Este documento es parte de una serie en la que se analiza la migración de contenedores a Google Cloud:

Migra contenedores a Google Cloud: Migra Kubernetes a Google Kubernetes Engine (GKE)
Migra contenedores a Google Cloud: Migra de OpenShift a GKE Enterprise
Migra contenedores a Google Cloud: Migra proyectos de OpenShift a GKE Enterprise (este documento)
Migra de OpenShift a GKE Enterprise: Migra las SCC de OpenShift a las restricciones de Policy Controller

Este documento es útil si planeas migrar proyectos de OpenShift a GKE Enterprise. Este documento también es útil si estás evaluando la posibilidad de migrar y deseas explorar cómo podría ser.

Este documento se basa en los conceptos que se analizan en Migración a Google Cloud: comienza ahora, Migra contenedores a Google Cloud: migra Kubernetes a GKE, Migra contenedores a Google Cloud: migra de OpenShift a GKE Enterprise, y Prácticas recomendadas para las herramientas de redes de GKE. Este documento vincula a los documentos anteriores cuando corresponde.

En la guía de este documento, suponemos que deseas ejecutar una migración lift-and-shift de tus cargas de trabajo. En una migración lift-and-shift, debes aplicar solo los cambios mínimos que necesitas para que las cargas de trabajo funcionen en el entorno de GKE Enterprise de destino.

Para migrar los recursos de OpenShift a GKE Enterprise, debes asignarlos y convertirlos en sus equivalentes de Kubernetes. En este documento, se describe la migración de los siguientes recursos de configuración del proyecto de OpenShift necesarios para implementar y operar las cargas de trabajo en GKE Enterprise:

Para migrar la configuración del proyecto de OpenShift y los recursos relacionados a GKE Enterprise, te recomendamos que hagas lo siguiente:

Exporta descriptores de recursos de configuración del proyecto de OpenShift.
Asigna los recursos de configuración del proyecto de OpenShift a los recursos de Kubernetes.
Crea recursos de Kubernetes que se asignen a los recursos de configuración del proyecto de OpenShift.
Administra los recursos de Kubernetes a través de Config Management.

En este documento, se proporcionan ejemplos de cómo puedes completar los pasos de migración.

Exporta descriptores de recursos de configuración del proyecto de OpenShift

Para exportar los recursos de configuración del proyecto de OpenShift, te recomendamos que hagas lo siguiente:

Exporta descriptores de proyectos de OpenShift.
Exporta descriptores de recursos con alcance de clúster.
Exporta descriptores de recursos con alcance de proyecto.

Los descriptores que exportas desde un clúster de OpenShift incluyen campos en los que se describen la configuración y el estado de los recursos, como los campos spec y status. Los descriptores también incluyen campos que contienen información de estado del recurso, como el campo metadata.managedFields. Kubernetes y OpenShift administran los campos que contienen información de estado de recursos y sus valores. A fin de simplificar la evaluación de los descriptores de recursos de OpenShift, te recomendamos que hagas lo siguiente para cada descriptor de recursos:

Registra los campos que contengan información de estado de recursos generados de forma dinámica junto con sus valores, como los siguientes:
- Cualquier campo anidado en metadata.annotations que comience con el prefijo openshift.io
- metadata.creationTimestamp
- metadata.generation
- metadata.managedFields
- metadata.resourceVersion
- metadata.selfLink
- metadata.uid
- status
Quita los campos que contienen información de estado de recursos generados de forma dinámica del descriptor de recursos.

Para exportar descriptores de recursos de configuración del proyecto de OpenShift, usa la interfaz de línea de comandos de OpenShift (CLI de oc). Para exportar descriptores de recursos en la CLI de oc, debes autenticarte con el rol de administrador de clúster. Para obtener una lista de todos los recursos de OpenShift que admite la CLI de oc, ejecuta el comando oc api-resources.

Exporta descriptores de proyectos de OpenShift

En esta sección, se describe cómo exportar los descriptores de proyectos. Te recomendamos excluir los proyectos de OpenShift que ejecutan componentes del sistema, como el componente istio-system y excluir los proyectos de OpenShift que tienen nombres que comienzan con openshift-, kube- o knative-. OpenShift administra estos proyectos de OpenShift por ti y están fuera del alcance de esta migración porque no los usas para implementar tus cargas de trabajo. Si deseas exportar descriptores de proyectos de OpenShift, haz lo siguiente para cada clúster de OpenShift:

En una terminal que tenga acceso al clúster de OpenShift, obtén la lista de proyectos de OpenShift mediante el comando oc get:
```
oc get projects
```
El resultado es similar a este:
```
NAME                 DISPLAY NAME      STATUS
example-project                        Active
...
```
El resultado muestra una lista de los proyectos de OpenShift que están configurados en ese momento en el clúster de OpenShift.
Para cada proyecto de OpenShift de la lista, exporta el descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo mediante el comando tee para su posterior procesamiento. Por ejemplo, exporta el descriptor de un proyecto example-project de OpenShift:
```
oc get project example-project -o yaml | tee project-example-project.yaml
```
El resultado es similar a este:
```
apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: example-project
spec:
  finalizers:
  - kubernetes
```
En el resultado, se muestra el descriptor del proyecto example-project de OpenShift en formato de archivo YAML. El resultado se guarda en el archivo project-example-project.yaml.

Exporta descriptores de recursos con alcance de clúster

En esta sección, se describe cómo exportar los descriptores para los recursos que tienen un alcance de clúster, sin incluir las restricciones de contexto de seguridad. Para obtener información sobre cómo migrar políticas de seguridad, consulta Migra de OpenShift a GKE Enterprise: Migra las SCC de OpenShift a las restricciones de Policy Controller. A fin de exportar otros descriptores de recursos, haz lo siguiente para cada clúster de OpenShift:

En tu terminal, obtén la lista de ClusterResourceQuotas:
```
oc get clusterresourcequotas
```
El resultado es similar a este:
```
NAME       AGE
for-name   6m15s
for-user   4s
...
```
En el resultado, se muestra una lista de ClusterResourceQuotas que están configuradas en la actualidad en tu clúster de OpenShift.
Por cada ClusterResourceQuota de la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para procesarlo más tarde. Por ejemplo, exporta el descriptor de la ClusterResourceQuota for-name:
```
oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml
```
El resultado es similar a este:
```
apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend
```
En el resultado, se muestra el descriptor del ClusterResourceQuota for-name en formato YAML. El resultado se guarda en el archivo clusterresourcequota-for-name.yaml.
Obtén la lista de ClusterRoles:
```
oc get clusterroles
```
El resultado es similar a este:
```
NAME                           CREATED AT
admin                          2021-02-02T06:17:02Z
aggregate-olm-edit             2021-02-02T06:17:59Z
aggregate-olm-view             2021-02-02T06:18:01Z
alertmanager-main              2021-02-02T06:48:26Z
basic-user                     2021-02-02T06:26:42Z
...
```
El resultado muestra una lista de ClusterRoles que están configurados en tu clúster de OpenShift. La lista de ClusterRoles incluye ClusterRoles predeterminados de OpenShift y ClusterRoles que hacen referencia a los componentes del sistema de OpenShift. Te recomendamos que evalúes todos los ClusterRoles en la lista para evaluar qué roles debes migrar y qué roles no son aplicables en el entorno de GKE Enterprise de destino.

Por cada ClusterRole en la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor de ClusterRole admin:

oc get clusterrole admin -o yaml | tee clusterrole-admin.yaml

El resultado es similar a este:

aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-admin: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: admin
rules:
- apiGroups:
  - operators.coreos.com
  resources:
  - subscriptions
  verbs:
  - create
  - update
  - patch
  - delete
...

El resultado muestra el descriptor del ClusterRole admin en formato YAML. El resultado se guarda en el archivo clusterrole-admin.yaml.

Obtén la lista de ClusterRoleBindings:

oc get clusterrolebindings

El resultado es similar a este:

NAME                                        ROLE                                             AGE
alertmanager-main                           ClusterRole/alertmanager-main                    21d
basic-users                                 ClusterRole/basic-user                           21d
cloud-credential-operator-rolebinding       ClusterRole/cloud-credential-operator-role       21d
cluster-admin                               ClusterRole/cluster-admin                        21d
cluster-admins                              ClusterRole/cluster-admin                        21d
cluster-autoscaler                          ClusterRole/cluster-autoscaler                   21d
cluster-autoscaler-operator                 ClusterRole/cluster-autoscaler-operator          21d
cluster-monitoring-operator                 ClusterRole/cluster-monitoring-operator          21d
...

El resultado muestra una lista de ClusterRoleBindings que están configuradas en tu clúster de OpenShift. La lista de ClusterRoleBindings incluye ClusterRoleBindings que hacen referencia a los componentes del sistema de OpenShift. Te recomendamos que evalúes todas las ClusterRoleBindings en la lista para evaluar qué vinculaciones necesitas migrar y cuáles no son aplicables en el entorno de GKE Enterprise de destino.

Para cada ClusterRoleBinding en la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor del ClusterRoleBinding cluster-admin:

oc get clusterrolebinding cluster-admin -o yaml | tee clusterrolebinding-cluster-admin.yaml

El resultado es similar a este:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

En el resultado, se muestra el descriptor del ClusterRoleBinding cluster-admin en formato YAML. El resultado se guarda en el archivo clusterrolebinding-cluster-admin.yaml.

Exporta NetNamespaces personalizados

En esta sección, se describe cómo evaluar la configuración del aislamiento multiusuario. Esta sección se aplica si creaste NetNamespaces personalizados para cualquier proyecto de OpenShift en tu clúster a fin de aislar o unir espacios de nombres de red. Si no creaste NetNamespaces personalizados, ve a Exporta descriptores de recursos con alcance de proyecto.

OpenShift crea y administra NetNamespaces de forma automática para proyectos administrados de OpenShift. Los NetNamespaces para proyectos administrados por OpenShift están fuera del alcance de esta migración.

Para exportar NetNamespaces personalizados, haz lo siguiente:

Obtén la lista de NetNamespaces:

oc get netnamespaces

El resultado es similar al siguiente.

NAME                                          NETID      EGRESS IPS
default                                       0
kube-node-lease                               13240579
kube-public                                   15463168
kube-system                                   16247265
openshift                                     9631477
openshift-apiserver                           12186643
openshift-apiserver-operator                  6097417
openshift-authentication                      2862939
openshift-authentication-operator             723750
openshift-cloud-credential-operator           11544971
openshift-cluster-csi-drivers                 7650297
openshift-cluster-machine-approver            7836750
openshift-cluster-node-tuning-operator        7531826
...

En el resultado se muestra una lista de NetNamespaces que están configurados en tu clúster de OpenShift.

Por cada NetNamespace de la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para procesarlo más tarde. Por ejemplo, exporta el descriptor de NetNamespace default:
```
oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml
```
Para los NetNamespaces que no tienen el mismo valor netid, el resultado es similar al siguiente:
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project
```
En el resultado se muestra el descriptor del NetNamespace example-project en formato de archivo YAML. El resultado se guarda en el archivo netnamespace-example-project.yaml.

Para los NetNamespaces que tienen el mismo valor netid, el resultado es similar al siguiente:
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2
```

Exporta descriptores de recursos con alcance de proyecto

Si deseas exportar los descriptores de los recursos que tienen un permiso de proyecto, haz lo siguiente para cada proyecto de OpenShift.

En tu terminal, selecciona el proyecto de OpenShift que deseas evaluar. Por ejemplo, selecciona el proyecto example-project de OpenShift:
```
oc project example-project
```
Obtén la lista de ResourceQuotas:
```
oc get resourcequotas
```
El resultado es similar a este:
```
NAME        AGE   REQUEST                        LIMIT
gpu-quota   6s    requests.nvidia.com/gpu: 1/1
...
```
En el resultado se muestra una lista de ResourceQuotas que están configuradas en tu clúster de OpenShift para el proyecto de OpenShift seleccionado.
Por cada ResourceQuota en la lista, exporta su descriptor en formato YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor de ResourceQuota gpu-quota:
```
oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml
```
El resultado es similar a este:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: example-project
spec:
  hard:
    requests.nvidia.com/gpu: "1"
```
En el resultado, se muestra el descriptor de la ResourceQuota gpu-quota en formato de archivo YAML. El resultado se guarda en el archivo resourcequota-gpu-quota.yaml.
Obtén la lista de Roles:
```
oc get roles
```
El resultado es similar a este:
```
NAME             CREATED AT
example          2021-02-02T06:48:27Z

...
```
En el resultado, se muestra una lista de las Roles configurados actualmente en tu clúster de OpenShift para el proyecto de OpenShift seleccionado. La lista de Roles incluye Roles que hacen referencia a componentes del sistema de OpenShift. Te recomendamos que evalúes todos los Roles de la lista para evaluar qué roles necesitas migrar y cuáles no son aplicables en el entorno de GKE Enterprise de destino.
Por cada Rol de la lista, exporta el descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para procesarlo más tarde. Por ejemplo, exporta el descriptor del Role example:
```
oc get role example -o yaml | tee role-example.yaml
```
El resultado es similar a este:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: example-project
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch
```
En el resultado, se muestra el descriptor del Role example en formato de archivo YAML. El resultado se guarda en el archivo role-example.yaml.

Obtén la lista de RoleBindings:

oc get rolebindings

El resultado es similar a este:

NAME                               ROLE                                           AGE
machine-config-controller-events   ClusterRole/machine-config-controller-events   21d
machine-config-daemon-events       ClusterRole/machine-config-daemon-events       21d
example                            Role/example                                   21d
system:deployers                   ClusterRole/system:deployer                    21d
system:image-builders              ClusterRole/system:image-builder               21d
system:image-pullers               ClusterRole/system:image-puller                21d
...

En el resultado se muestra una lista de RoleBindings configuradas en el clúster de OpenShift para el proyecto de OpenShift seleccionado. La lista de RoleBindings incluye RoleBindings que hacen referencia a los componentes del sistema de OpenShift. Te recomendamos que evalúes todas las RoleBindings de la lista para evaluar qué vinculaciones debes migrar y cuáles no son aplicables en el entorno de GKE Enterprise de destino.

Por cada RoleBinding en la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor del RoleBinding example:
```
oc get rolebinding example -o yaml | tee rolebinding-example.yaml
```
El resultado es similar a este:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: example-project
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: example
subjects:
- kind: ServiceAccount
  name: example
  namespace: example-ns
```
En el resultado se muestra el descriptor del RoleBinding example en formato de archivo YAML. El resultado se guarda en el archivo rolebinding-example.yaml.
Obtén la lista de EgressNetworkPolicies:
```
oc get egressnetworkpolicies
```
El resultado es similar a este:
```
NAME      AGE
default   2m2s
...
```
En el resultado se muestra una lista de EgressNetworkPolicies que están configuradas en tu clúster de OpenShift para el proyecto de OpenShift seleccionado.
Por cada EgressNetworkPolicy de la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor de la EgressNetworkPolicy default:
```
oc get egressnetworkpolicy default -o yaml | tee egressnetworkpolicy-default.yaml
```
El resultado es similar a este:
```
apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      dnsName: www.example.com
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny
```
En el resultado, se muestra el descriptor de la EgressNetworkPolicy default en formato YAML. El resultado también se guarda en el archivo egressnetworkpolicy-default.yaml.
Obtén la lista de NetworkPolicies:
```
oc get networkpolicies
```
El resultado es similar a este:
```
NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...
```
En el resultado se muestra una lista de NetworkPolicies que están configuradas en tu clúster de OpenShift para el proyecto de OpenShift seleccionado.
Por cada NetworkPolicy de la lista, exporta su descriptor en formato de archivo YAML, muestra el resultado y guárdalo en un archivo para su posterior procesamiento. Por ejemplo, exporta el descriptor de la NetworkPolicy test-policy:
```
oc get networkpolicy test-policy -o yaml | tee networkpolicy-test-policy.yaml
```
El resultado es similar a este:
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-policy
  namespace: example-project
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - port: 27017
      protocol: TCP
  podSelector:
    matchLabels:
      app: mongodb
  policyTypes:
  - Ingress
```
En el resultado, se muestra el descriptor de la NetworkPolicy test-policy en formato de archivo YAML. El resultado se guarda en el archivo networkpolicy-test-policy.yaml.

Asigna recursos de configuración de proyectos de OpenShift a recursos de Kubernetes

Después de completar el inventario de los recursos de configuración del proyecto de OpenShift, evalúa esos recursos de la siguiente manera:

Evalúa qué recursos del inventario son recursos de Kubernetes y cuáles son de OpenShift.
Asigna los recursos de OpenShift a sus equivalentes de Kubernetes, GKE y GKE Enterprise.

La siguiente lista te ayuda a evaluar qué recursos aprovisionados en los clústeres de OpenShift son recursos de Kubernetes y cuáles están disponibles solo en OpenShift:

Los proyectos de OpenShift son espacios de nombres de Kubernetes con anotaciones adicionales.
Los Roles, ClusterRoles, RoleBindings y ClusterRoleBindings son recursos de Kubernetes.
Las ResourceQuotas son recursos de Kubernetes.
Las NetworkPolicies son recursos de Kubernetes.
Los ClusterResourceQuotas no son recursos de Kubernetes; solo están disponibles en OpenShift.
Los NetNamespaces y las EgressNetworkPolicies no son recursos de Kubernetes; solo están disponibles en OpenShift.

En la siguiente tabla, se proporciona un resumen de cómo asignar los recursos de configuración del proyecto de OpenShift a los recursos que usaste en GKE Enterprise.

OpenShift	GKE Enterprise
Proyectos	Convertir en espacios de nombres de Kubernetes con anotaciones adicionales
Roles, ClusterRoles, RoleBindings y ClusterRoleBindings	Recursos de RBAC de Kubernetes
ResourceQuotas	Recursos de RBAC de Kubernetes
ClusterResourceQuotas	Convertir en ResourceQuotas o usar cuotas de recursos jerárquicas
NetworkPolicies	Recursos de red de Kubernetes
NetNamespaces, EgressNetworkPolicies	Convertir en NetworkPolicies

Después de evaluar los recursos de tu entorno de OpenShift, asigna los recursos de OpenShift a los que puedes aprovisionar y configurar en GKE y GKE Enterprise. No es necesario asignar los recursos de Kubernetes que usas en los clústeres de OpenShift, ya que GKE Enterprise los admite directamente. Como se describe en Resumen de la asignación de capacidades de OpenShift a GKE Enterprise, te recomendamos que asignes lo siguiente:

Proyectos de OpenShift a espacios de nombres de Kubernetes
ClusterResourceQuotas a ResourceQuotas
NetNamespaces y EgressNetworkPolicies a NetworkPolicies

Crea recursos de Kubernetes que se asignen a los recursos de configuración del proyecto de OpenShift

Después de completar la asignación, crea los recursos de Kubernetes que asignaste a los recursos de OpenShift. Te recomendamos que crees lo siguiente:

Un espacio de nombres de Kubernetes para cada proyecto de OpenShift
Una ResourceQuota para cada espacio de nombres de Kubernetes que limitan tus ClusterResourceQuotas
NetworkPolicies para que coincidan con tus NetNamespaces y EgressNetworkPolicies.

Cree espacios de nombres de Kubernetes

Los proyectos de OpenShift son espacios de nombres de Kubernetes con anotaciones adicionales. La API del proyecto OpenShift coincide de forma estrecha con la API de espacio de nombres de Kubernetes. A fin de migrar tus proyectos de OpenShift, te recomendamos que crees un espacio de nombres de Kubernetes para cada proyecto de OpenShift. Las API son compatibles, por lo que puedes crear un espacio de nombres de Kubernetes a partir de un proyecto de OpenShift.

Para crear un espacio de nombres de Kubernetes a partir de un proyecto de OpenShift, te recomendamos cambiar los valores del descriptor de proyectos de OpenShift a la versión de la API de espacio de nombres de Kubernetes correspondiente para cada proyecto de OpenShift. Para hacerlo, cambia el valor del campo apiVersion en el descriptor de proyectos de OpenShift de la versión de la API del objeto de proyecto de OpenShift y el valor del campo kind al valor correspondiente Versión de la API del objeto de espacio de nombres de Kubernetes. Por ejemplo, el proyecto de OpenShift que evaluaste en la sección anterior es similar al siguiente:

apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

Para migrar el proyecto, cambia el valor del campo apiVersion de project.openshift.io/v1 a v1 y el valor del campo kind de Project a Namespace:

apiVersion: v1
kind: Namespace
Metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

Crea ResourceQuotas de Kubernetes

Las ClusterResourceQuotas de OpenShift te permiten compartir cuotas en varios proyectos de OpenShift. Cuando creas una ClusterResourceQuota, debes definir la cuota y el selector para que coincidan con los proyectos de OpenShift a los que deseas aplicar la cuota. En esta sección, migrarás ClusterResourceQuotas de OpenShift a ResourceQuotas de Kubernetes en los espacios de nombres que creaste antes.

A fin de migrar tus ClusterResourceQuotas, te recomendamos que hagas lo siguiente para cada ClusterResourceQuota:

Asigna las ClusterResourceQuota a los proyectos de OpenShift mediante la evaluación del campo spec.quota y el campo spec.selector de ClusterResourceQuota. Por ejemplo, la ClusterResourceQuota for-name que exportaste en la sección anterior se veía de la siguiente manera:
```
apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend
```
La ClusterResourceQuota for-name aplica límites de cuota de Pods y Secrets. El campo spec.selector aplica esos límites en el proyecto frontend de OpenShift.
En Crea espacios de nombres de Kubernetes, creaste espacios de nombres de Kubernetes que corresponden a tus proyectos de OpenShift. Usa esa información para asignar la ClusterResourceQuota a los nuevos espacios de nombres de Kubernetes. Por ejemplo, el proyecto frontend de OpenShift contiene la ClusterResourceQuota for-name. El proyecto corresponde al espacio de nombres frontend de Kubernetes, por lo que debes asignar la ClusterResourceQuota for-name al espacio de nombres de Kubernetes frontend.
Para cada definición de cuota en el campo quota de ClusterResourceQuota, divide la cantidad de la cuota entre los espacios de nombres de Kubernetes a los que asignaste la ClusterResourceQuota, de acuerdo con los criterios de interés. Por ejemplo, puedes dividir las cantidades de la cuota establecidas por la ClusterResourceQuota for-name de manera equitativa entre los espacios de nombres de Kubernetes frontend.
Por cada espacio de nombres de Kubernetes que hayas asignado a la ClusterResourceQuota, debes crear una ResourceQuota de Kubernetes que aplique la cuota en ese espacio de nombres. Establece las cantidades de la cuota de acuerdo con la información que recopilaste en el paso anterior. Por ejemplo, debes crear una ResourceQuota para el espacio de nombres de Kubernetes frontend:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"
```
Como otro ejemplo, asigna la ClusterResourceQuota for-name a dos espacios de nombres de Kubernetes distintos, example-1 y example-2. A fin de completar la asignación, divide los recursos de forma equitativa entre ellos mediante la creación de una ResourceQuota para los espacios de nombres de Kubernetes. Asigna la primera mitad de ResourceQuota:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-1
spec:
  hard:
    pods: "5"
    secrets: "10"
```
Después de asignar la primera mitad de ResourceQuota, asigna la segunda mitad de ResourceQuota:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-2
spec:
  hard:
    pods: "5"
    secrets: "10"
```
Este enfoque te permite aplicar límites en cada espacio de nombres de Kubernetes en el que creas ResourceQuotas, en lugar de configurar un solo límite para varios espacios de nombres de Kubernetes.

Usar ResourceQuotas para aplicar cuotas en los espacios de nombres de Kubernetes no es lo mismo que usar una ClusterResourceQuota para aplicar una cuota en todos los espacios de nombres de Kubernetes. La división de una cuota con alcance de clúster entre diferentes espacios de nombres de Kubernetes podría no ser óptima: la división podría aprovisionar en exceso las cuotas para algunos espacios de nombres de Kubernetes y aprovisionar de forma insuficiente las cuotas para otros espacios de nombres de Kubernetes.

Recomendamos que optimices la asignación de cuotas mediante el ajuste dinámico de la configuración de ResourceQuotas en tus espacios de nombres de Kubernetes, de modo que se respete la cantidad total de la cuota que estableció la ClusterResourceQuota correspondiente. Por ejemplo, puedes aumentar o disminuir de forma dinámica las cantidades de la cuota que aplican las ResourceQuotas pods-secrets a fin de evitar el aprovisionamiento excesivo o el aprovisionamiento insuficiente de cuotas para los espacios de nombres de Kubernetes example-1 y example-2. Las cantidades totales de la cuota de ResourceQuotas pods-secrets no deberían exceder las cantidades de la cuota en el ClusterResourceQuota correspondiente.

Cuando configures tus ResourceQuotas, considera cuotas y límites de GKE y cuotas y límites de GKE en VMware. Es posible que estas cuotas y límites impongan límites más bajos que tus ResourceQuotas. Por ejemplo, GKE limita la cantidad máxima de Pods por nodo, sin importar cómo configuraste las ResourceQuotas.

Crea NetworkPolicies

Los NetNamespaces de OpenShift te permiten configurar el aislamiento de red entre proyectos de OpenShift. Las EgressNetworkPolicies de OpenShift te permiten regular el tráfico de salida que sale de los clústeres de OpenShift. Esta sección se basa en los conceptos de restricción de tráfico.

Para migrar tus NetNamespaces y EgressNetworkPolicies, haz lo siguiente:

Evalúa tus NetNamespaces y EgressNetworkPolicies para comprender cómo regulan el tráfico de red entre proyectos de OpenShift y el tráfico de salida que sale de los clústeres de OpenShift. Por ejemplo, evalúa el NetNamespace y la EgressNetworkPolicy que exportaste en la sección anterior:
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny
```
Los NetNamespaces example-project y example-project-2 definen una red superpuesta con el mismo valor netid de 1234. Por lo tanto, los Pods en el proyecto example-project de OpenShift se pueden comunicar con los Pods en el proyecto example-project-2 de OpenShift y viceversa.

La EgressNetworkPolicy default define las siguientes reglas de tráfico de red saliente:
- Permitir el tráfico de salida a la subred 1.2.3.0/24
- Rechazar el tráfico de salida que no coincida con otras reglas

Crea NetworkPolicies y políticas OPA para que coincidan con tus requisitos de restricción de tráfico de red. Por ejemplo, default-np y default-np-2 implementan las siguientes políticas:

Las políticas que aplica la EgressNetworkPolicy default
Las políticas que aplican los NetNamespaces example-project y example-project-2 en los espacios de nombres que tienen la etiqueta netid configurada en example-project y example-project-2:

Las políticas son similares a las siguientes:

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np
  namespace: example-project
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project-2

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np-2
  namespace: example-project-2
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project

Administra recursos de Kubernetes a través del Sincronizador de configuración

Para administrar los recursos de Kubernetes y la configuración de tus clústeres de GKE, te recomendamos usar el Sincronizador de configuración.

Para obtener información sobre cómo habilitar el Sincronizador de configuración en tus clústeres de GKE, consulta Instala el Sincronizador de configuración.

Después de aprovisionar y configurar el Sincronizador de configuración en tu entorno de GKE Enterprise, úsalo para crear y aplicar de forma automática la configuración a tus clústeres de GKE.

¿Qué sigue?

Consulta Primeros pasos de la migración a Google Cloud.
Lee acerca de las prácticas recomendadas para compilar y operar contenedores.
Obtén más información sobre las prácticas recomendadas para las herramientas de redes de GKE.
Obtén más información para endurecer la seguridad del clúster.
Lee la descripción general de seguridad de GKE.
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.