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:
- Proyectos de OpenShift
- Cuotas de recursos para cada proyecto de OpenShift y cuotas de recursos en varios proyectos de OpenShift
- Roles y ClusterRoles
- RoleBindings y ClusterRoleBindings
- Configuración de espacios de nombres de red de OpenShift y NetworkPolicies
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 prefijoopenshift.io
metadata.creationTimestamp
metadata.generation
metadata.managedFields
metadata.resourceVersion
metadata.selfLink
metadata.uid
status
- Cualquier campo anidado en
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 proyectoexample-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 archivoproject-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 archivoclusterresourcequota-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 archivoclusterrole-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 archivoclusterrolebinding-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 archivonetnamespace-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 archivoresourcequota-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 archivorole-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 archivorolebinding-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 archivoegressnetworkpolicy-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 archivonetworkpolicy-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 campospec.selector
de ClusterResourceQuota. Por ejemplo, la ClusterResourceQuotafor-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 campospec.selector
aplica esos límites en el proyectofrontend
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 ClusterResourceQuotafor-name
. El proyecto corresponde al espacio de nombresfrontend
de Kubernetes, por lo que debes asignar la ClusterResourceQuotafor-name
al espacio de nombres de Kubernetesfrontend
.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 ClusterResourceQuotafor-name
de manera equitativa entre los espacios de nombres de Kubernetesfrontend
.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
yexample-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
yexample-project-2
definen una red superpuesta con el mismo valornetid
de1234
. Por lo tanto, los Pods en el proyectoexample-project
de OpenShift se pueden comunicar con los Pods en el proyectoexample-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
- Permitir el tráfico de salida a la subred
Crea NetworkPolicies y políticas OPA para que coincidan con tus requisitos de restricción de tráfico de red. Por ejemplo,
default-np
ydefault-np-2
implementan las siguientes políticas:- Las políticas que aplica la EgressNetworkPolicy
default
- Las políticas que aplican los NetNamespaces
example-project
yexample-project-2
en los espacios de nombres que tienen la etiquetanetid
configurada enexample-project
yexample-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
- Las políticas que aplica la EgressNetworkPolicy
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.