Como migrar contêineres para o Google Cloud: migrar projetos do OpenShift para o GKE Enterprise

Last reviewed 2022-01-24 UTC

Neste documento, ajudamos a planejar, projetar e implementar a migração de seus projetos do OpenShift para o GKE Enterprise. Se feita incorretamente, a migração das cargas de trabalho de um ambiente para outro pode ser uma tarefa desafiadora. Portanto, planeje e execute a migração com cuidado.

Este documento faz parte de uma série de várias partes sobre a migração para o Google Cloud. Se você tiver interesse em uma visão geral da série, consulte Migração para o Google Cloud: como escolher seu caminho de migração.

Este documento faz parte de uma série que discute a migração de contêineres para o Google Cloud:

Migração de contêineres para o Google Cloud: como migrar do Kubernetes para o Google Kubernetes Engine (GKE)
Como migrar contêineres para o Google Cloud: como migrar do OpenShift para o GKE Enterprise
Como migrar contêineres para o Google Cloud: migrar projetos do OpenShift para o GKE Enterprise (este documento)
Migração do OpenShift para o GKE Enterprise: migrar as SCCs do OpenShift para as restrições do Policy Controller

Este documento é útil se você planeja migrar projetos do OpenShift para o GKE Enterprise. É útil, além disso, se estiver considerando a oportunidade de migrar e quiser saber como funciona esse processo.

Este documento depende dos conceitos discutidos em Migração para o Google Cloud: primeiros passos em Como migrar contêineres para o Google Cloud: como migrar o Kubernetes para o GKE, em Como migrar contêineres para o Google Cloud: como migrar do OpenShift para o GKE Enterprise e em Práticas recomendadas para a rede do GKE. Este documento inclui links para os documentos anteriores, quando apropriado.

A orientação neste documento presume que você queira executar uma migração lift-and-shift das suas cargas de trabalho. Em uma migração lift-and-shift, aplique apenas as alterações mínimas necessárias para que as cargas de trabalho funcionem no ambiente GKE Enterprise do destino.

Para migrar os recursos do OpenShift para o GKE Enterprise, mapeie e converta os recursos em equivalentes do Kubernetes. Neste documento, descrevemos a migração dos seguintes recursos de configuração do projeto do OpenShift necessários para implantar e operar suas cargas de trabalho no GKE Enterprise:

Para migrar a configuração do projeto do OpenShift e recursos relacionados para o GKE Enterprise, recomendamos que você faça o seguinte:

Exportar descritores de recursos de configuração do projeto do OpenShift.
Mapear os recursos de configuração do projeto do OpenShift para os recursos do Kubernetes.
Crie recursos do Kubernetes que são mapeados para os recursos de configuração do projeto do OpenShift.
Gerencie os recursos do Kubernetes usando o Config Sync.

Este documento fornece exemplos de como concluir as etapas de migração.

Exportar descritores de recursos de configuração do projeto do OpenShift

Para exportar os recursos de configuração do projeto do OpenShift, recomendamos que você faça o seguinte:

Exportar descritores de projeto do OpenShift.
Exporte descritores de recursos com escopo de cluster.
Exporte descritores de recursos com escopo no projeto.

Os descritores exportados de um cluster do OpenShift incluem campos que descrevem a configuração e o status dos recursos, como os campos spec e status. Os descritores também incluem campos que contêm informações de status de recursos, como o campo metadata.managedFields. O Kubernetes e o OpenShift gerenciam os campos que contêm informações de status de recursos e os valores deles para você. Para simplificar a avaliação dos descritores de recursos do OpenShift, recomendamos que você faça o seguinte para cada descritor de recurso:

Registre os campos que contêm informações de status de recursos geradas dinamicamente com os respectivos valores, como:
- Qualquer campo aninhado em metadata.annotations que começa com o prefixo openshift.io
- metadata.creationTimestamp
- metadata.generation
- metadata.managedFields
- metadata.resourceVersion
- metadata.selfLink
- metadata.uid
- status
Remova os campos que contêm informações de status de recursos geradas dinamicamente do descritor de recursos.

Para exportar os descritores de recursos de configuração de projeto do OpenShift, use a interface de linha de comando do OpenShift (CLI do oc). Para exportar descritores de recursos na CLI oc, você precisa se autenticar com o papel cluster-admin. Para ver uma lista de todos os recursos do OpenShift compatíveis com a CLI oc, execute o comando oc api-resources.

Exportar descritores do projeto do OpenShift

Nesta seção, descrevemos como exportar descritores de projeto. Recomendamos excluir projetos do OpenShift que executam componentes do sistema, como o componente istio-system, e excluir projetos do OpenShift que tenham nomes começando com openshift-, kube- ou knative- O OpenShift gerencia esses projetos do OpenShift para você, e eles estão fora do escopo dessa migração porque não são usados para implantar as cargas de trabalho. Para exportar os descritores de projeto do OpenShift, faça o seguinte para cada cluster do OpenShift:

Em um terminal que tenha acesso ao cluster do OpenShift, confira a lista de projetos do OpenShift usando o oc get comando:
```
oc get projects
```
A saída será assim:
```
NAME                 DISPLAY NAME      STATUS
example-project                        Active
...
```
A saída exibe uma lista dos projetos do OpenShift que estão configurados no seu cluster do OpenShift.
Para cada projeto do OpenShift na lista, exporte o descritor dele no formato de arquivo YAML, exiba a saída e salve-a em um arquivo usando o comando tee: para processamento posterior. Por exemplo, exporte o descritor de um projeto example-project do OpenShift:
```
oc get project example-project -o yaml | tee project-example-project.yaml
```
A saída será assim:
```
apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: example-project
spec:
  finalizers:
  - kubernetes
```
A saída exibe o descritor do projeto do OpenShift example-project no formato de arquivo YAML. A saída é salva no arquivo project-example-project.yaml.

Exportar descritores de recursos com escopo de cluster

Nesta seção, descrevemos como exportar os descritores para recursos que têm escopo de cluster, sem incluir restrições de contexto de segurança. Para mais informações sobre como migrar políticas de segurança, consulte Como migrar do OpenShift para o GKE Enterprise: migrar as SCCs do OpenShift para as restrições do Controlador de Políticas. Para exportar outros descritores de recursos, faça o seguinte para cada cluster do OpenShift:

No seu terminal, veja a lista de ClusterResourceQuotas:
```
oc get clusterresourcequotas
```
A saída será assim:
```
NAME       AGE
for-name   6m15s
for-user   4s
...
```
A saída exibe uma lista de ClusterResourceQuotas que estão configurados no cluster do OpenShift.
Para cada ClusterResourceQuota na lista, exporte o descritor no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exporte o descritor para o ClusterResourceQuota for-name:
```
oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml
```
A saída será assim:
```
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
```
A saída exibe o descritor do ClusterResourceQuota for-name no formato YAML. A saída é salva no arquivo clusterresourcequota-for-name.yaml.
Consiga a lista de ClusterRoles:
```
oc get clusterroles
```
A saída será assim:
```
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
...
```
A saída exibe uma lista de ClusterRoles configurados no cluster do OpenShift. A lista de ClusterRoles inclui ClusterRoles padrão do OpenShift e ClusterRoles que se referem aos componentes do sistema do OpenShift. Recomendamos que você avalie todos os ClusterRoles na lista para avaliar quais papéis precisa migrar e quais não são aplicáveis no ambiente de destino do GKE Enterprise.

Para cada ClusterRole na lista, exporte o descritor dele no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exportar o descritor do ClusterRole admin:

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

A saída será assim:

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
...

A saída exibe o descritor do ClusterRole admin no formato YAML. A saída é salva no arquivo clusterrole-admin.yaml.

Receba a lista de ClusterRoleBindings:

oc get clusterrolebindings

A saída será assim:

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
...

A saída exibe uma lista de ClusterRoleBindings configurados no cluster do OpenShift. A lista de ClusterRoleBindings inclui ClusterRoleBindings que se referem aos componentes do sistema do OpenShift. Recomendamos que você avalie todos os ClusterRoleBindings na lista para avaliar quais vinculações você precisa migrar e quais vinculações não são aplicáveis no ambiente de destino do GKE Enterprise.

Para cada ClusterRoleBinding na lista, exporte o descritor dele no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exporte o descritor do ClusterRoleBinding cluster-admin:

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

A saída será assim:

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

A saída exibe o descritor do ClusterRoleBinding cluster-admin no formato YAML. A saída é salva no arquivo clusterrolebinding-cluster-admin.yaml.

Exportar NetNamespaces personalizados

Nesta seção, você verá como avaliar a configuração do isolamento de vários locatários. Esta seção se aplica caso você tenha criado NetNamespaces personalizados para qualquer projeto do OpenShift no cluster para isolar ou mesclar namespaces de rede. Se você não criou NetNamespaces personalizados, pule para Exportar descritores de recursos com escopo no projeto.

O OpenShift cria e gerencia automaticamente o NetNamespaces para projetos gerenciados do OpenShift. Os NetNamespaces para projetos gerenciados pelo OpenShift estão fora do escopo dessa migração.

Para exportar NetNamespaces personalizados, faça o seguinte:

Receba a lista de NetNamespaces:

oc get netnamespaces

A resposta será semelhante a esta:

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
...

A saída exibe uma lista de NetNamespaces configurados no cluster do OpenShift.

Para cada NetNamespace na lista, exporte o descritor no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exporte o descritor da default NetNamespace:
```
oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml
```
Para NetNamespaces que não têm o mesmo valor netid, a saída é semelhante à seguinte:
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project
```
A saída exibe o descritor do NetNamespace example-project no formato de arquivo YAML. A saída é salva no arquivo netnamespace-example-project.yaml.

Para NetNamespaces que têm o mesmo valor de netid, a saída é semelhante à seguinte:
```
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
```

Exportar descritores de recursos com escopo no projeto

Para exportar os descritores dos recursos que têm um escopo de projeto, faça o seguinte para cada projeto do OpenShift.

No terminal, selecione o projeto do OpenShift que você quer avaliar. Por exemplo, selecione o projeto example-project do OpenShift:
```
oc project example-project
```
Veja a lista de ResourceQuotas:
```
oc get resourcequotas
```
A saída será assim:
```
NAME        AGE   REQUEST                        LIMIT
gpu-quota   6s    requests.nvidia.com/gpu: 1/1
...
```
A saída exibe uma lista de ResourceQuotas que estão configuradas no cluster do OpenShift.
Para cada ResourceQuota na lista, exporte o descritor no formato YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exportar o descritor de ResourceQuota gpu-quota:
```
oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml
```
A saída será assim:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: example-project
spec:
  hard:
    requests.nvidia.com/gpu: "1"
```
A saída exibe o descritor do ResourceQuota gpu-quota no formato de arquivo YAML. A saída é salva no arquivo resourcequota-gpu-quota.yaml.
Veja a lista de Papéis:
```
oc get roles
```
A saída será assim:
```
NAME             CREATED AT
example          2021-02-02T06:48:27Z

...
```
A saída exibe uma lista de papéis que estão configurados no cluster do OpenShift. A lista de Roles inclui Roles que se referem aos componentes do sistema do OpenShift. Recomendamos que você avalie todos os papéis na lista para avaliar quais papéis precisam migrar e quais não são aplicáveis no ambiente de destino do GKE Enterprise.
Para cada papel na lista, exporte o descritor em formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exporte o descritor do papel example:
```
oc get role example -o yaml | tee role-example.yaml
```
A saída será assim:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: example-project
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch
```
A saída exibe o descritor do papel example no formato de arquivo YAML. A saída é salva no arquivo role-example.yaml.

Veja a lista de RoleBindings:

oc get rolebindings

A saída será assim:

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
...

A saída exibe uma lista de RoleBindings configurados no cluster do OpenShift para o projeto selecionado do OpenShift. A lista de RoleBindings inclui RoleBindings que se referem aos componentes do sistema do OpenShift. Recomendamos que você avalie todos os RoleBindings na lista para avaliar quais vinculações você precisa migrar e quais vinculações não são aplicáveis no ambiente de destino do GKE Enterprise.

Para cada RoleBinding na lista, exporte o descritor dele no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exportar o descritor do RoleBinding example:
```
oc get rolebinding example -o yaml | tee rolebinding-example.yaml
```
A saída será assim:
```
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
```
A saída exibe o descritor do RoleBinding example no formato de arquivo YAML. A saída é salva no arquivo rolebinding-example.yaml.
Veja a lista de EgressNetworkPolicies:
```
oc get egressnetworkpolicies
```
A saída será assim:
```
NAME      AGE
default   2m2s
...
```
A saída exibe uma lista de EgressNetworkPolicies que estão configuradas atualmente no cluster do OpenShift para o projeto selecionado do OpenShift.
Para cada EgressNetworkPolicy na lista, exporte o descritor em formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exporte o descritor da defaultEgressNetworkPolicy:
```
oc get egressnetworkpolicy default -o yaml | tee egressnetworkpolicy-default.yaml
```
A saída será assim:
```
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
```
A saída exibe o descritor de EgressNetworkPolicy default no formato YAML. A saída também é salva no arquivo egressnetworkpolicy-default.yaml.
Veja a lista de NetworkPolicies:
```
oc get networkpolicies
```
A saída será assim:
```
NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...
```
O resultado exibe uma lista de NetworkPolicies atualmente configuradas no cluster do OpenShift para o projeto selecionado do OpenShift.

Para cada NetworkPolicy na lista, exporte o descritor no formato de arquivo YAML, exiba a saída e salve-a em um arquivo para processamento posterior. Por exemplo, exportar o descritor da NetworkPolicy test-policy:

oc get networkpolicy test-policy -o yaml | tee networkpolicy-test-policy.yaml

A saída será assim:

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

A saída exibe o descritor de NetworkPolicy test-policy no formato de arquivo YAML. A saída é salva no arquivo networkpolicy-test-policy.yaml.

Mapear recursos de configuração de projeto do OpenShift para recursos do Kubernetes

Depois de concluir o inventário dos recursos de configuração do projeto do OpenShift, avalie esses recursos da seguinte maneira:

Avalie quais recursos no inventário são recursos do Kubernetes e que são recursos do OpenShift.
Mapear recursos do OpenShift para os equivalentes do Kubernetes, GKE e GKE Enterprise.

A lista a seguir ajuda a avaliar quais recursos provisionados nos clusters do OpenShift são recursos do Kubernetes e quais recursos estão disponíveis apenas no OpenShift:

Os projetos do OpenShift são namespaces do Kubernetes com outras anotações.
Roles, ClusterRoles, RoleBindings e ClusterRoleBindings são recursos do Kubernetes (em inglês).
ResourceQuotas são recursos do Kubernetes.
NetworkPolicies são recursos do Kubernetes.
ClusterResourceQuotas não são recursos do Kubernetes; elas estão disponíveis apenas no OpenShift.
NetNamespaces e EgressNetworkPolicies não são recursos do Kubernetes e estão disponíveis apenas no OpenShift.

A tabela a seguir fornece um resumo de como mapear os recursos de configuração do projeto do OpenShift para os recursos usados no GKE Enterprise.

OpenShift	GKE Enterprise
Projetos	Converta para namespaces do Kubernetes com anotações adicionais
Roles, ClusterRoles, RoleBindings e ClusterRoleBindings	Recursos do RBAC do Kubernetes
ResourceQuotas	Recursos do RBAC do Kubernetes
ClusterResourceQuotas	Converter em ResourceQuotas ou usar cotas de recursos hierárquicas.
NetworkPolicies	Recursos de rede do Kubernetes
NetNamespaces, EgressNetworkPolicies	Converter para NetworkPolicies

Depois de avaliar os recursos do ambiente do OpenShift, mapeie-os para os recursos que podem ser provisionados e configurados no GKE e no GKE Enterprise. Não é necessário mapear os recursos do Kubernetes que você está usando nos clusters do OpenShift, porque o GKE Enterprise é diretamente compatível com eles. Conforme descrito em Resumo do mapeamento de recursos do OpenShift para o GKE Enterprise, recomendamos que você mapeie o seguinte:

Projetos do OpenShift para namespaces do Kubernetes.
ClusterResourceQuotas para ResourceQuotas.
NetNamespaces e EgressNetworkPolicies para NetworkPolicies.

Criar recursos do Kubernetes que são mapeados para os recursos de configuração do projeto do OpenShift

Depois de concluir o mapeamento, crie os recursos do Kubernetes mapeados para os recursos do OpenShift. Recomendamos que você crie o seguinte:

Um namespace do Kubernetes para cada projeto do OpenShift.
Um ResourceQuota para cada namespace do Kubernetes que seu ClusterResourceQuotas está limitando.
NetworkPolicies para corresponder aos seus NetNamespaces e EgressNetworkPolicies.

Crie namespaces do Kubernetes

Os projetos do OpenShift são namespaces do Kubernetes com anotações adicionais. A API do projeto do OpenShift corresponde aproximadamente à API Namespace do Kubernetes. Para migrar seus projetos do OpenShift, recomendamos que você crie um namespace do Kubernetes para cada projeto do OpenShift. As APIs são compatíveis, portanto, você pode criar um namespace do Kubernetes a partir de um projeto do OpenShift.

Para criar um namespace do Kubernetes a partir de um projeto do OpenShift, recomendamos que você altere os valores no descritor de projeto do OpenShift para a versão correspondente da API Namespace do Kubernetes para cada projeto do OpenShift. Para isso, mude o valor do campo apiVersion no descritor de projeto do OpenShift da versão da API do objeto do projeto do OpenShift e o valor do campo kind para o Versão da API de objeto de namespace do Kubernetes. Por exemplo, o projeto do OpenShift que você avaliou na seção anterior é semelhante ao seguinte:

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

Para migrar o projeto, altere o valor do campo apiVersion de project.openshift.io/v1 para v1 e altere o valor do campo kind de Project para Namespace:

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

Criar ResourceQuotas do Kubernetes

Com as ClusterResourceQuotas do OpenShift, é possível compartilhar cotas em vários projetos do OpenShift. Ao criar um ClusterResourceQuota, você define a cota e define o seletor correspondente aos projetos do OpenShift aos quais quer aplicar a cota. Nesta seção, você migra suas ClusterResourceQuotas do OpenShift para os ResourceQuotas do Kubernetes nos namespaces criados anteriormente.

Para migrar o ClusterResourceQuotas, recomendamos que você faça o seguinte para cada ClusterResourceQuota:

Mapeie o ClusterResourceQuota para projetos do OpenShift avaliando o campo spec.quota e o campo spec.selector do ClusterResourceQuota. Por exemplo, a ClusterResourceQuota for-name exportada na seção anterior era semelhante a esta:
```
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
```
O ClusterResourceQuota for-name impõe limites de cota de pod e secret. O campo spec.selector impõe esses limites no projeto frontend do OpenShift.
Antes da criação, você criou namespaces do Kubernetes (em inglês) e criou os namespaces do Kubernetes que correspondem aos seus projetos do OpenShift. Use essas informações para mapear o ClusterResourceQuota para o novo Namespaces do Kubernetes. Por exemplo, o projeto frontend do OpenShift contém o ClusterResourceQuota for-name. O projeto corresponde ao namespace frontend do Kubernetes. Portanto, você mapeia o ClusterResourceQuota for-name para o namespace frontend do Kubernetes.
Para cada definição de cota no campo quota, divida o valor da cota entre os namespaces do Kubernetes para os quais você mapeou a ClusterResourceQuota, de acordo com os critérios de interesse. Por exemplo, é possível dividir os valores de cota definidos pelo ClusterResourceQuota for-name igualmente entre os namespaces frontend do Kubernetes.
Para cada namespace do Kubernetes mapeado para o ClusterResourceQuota, você cria um ResourceQuota do Kubernetes que aplica a cota nesse namespace. Você define os valores da cota de acordo com as informações coletadas na etapa anterior. Por exemplo, você cria um ResourceQuota para o namespace frontend do Kubernetes:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"
```
Como outro exemplo, você mapeia o ClusterResourceQuota for-name para dois namespaces distintos do Kubernetes, example-1 e example-2. Para concluir o mapeamento, divida os recursos igualmente entre eles criando um ResourceQuota para os namespaces do Kubernetes. Aloque a primeira metade da ResourceQuota:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-1
spec:
  hard:
    pods: "5"
    secrets: "10"
```
Depois de alocar a primeira metade da ResourceQuota, aloque a segunda metade da ResourceQuota:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-2
spec:
  hard:
    pods: "5"
    secrets: "10"
```
Essa abordagem permite impor limites em cada namespace do Kubernetes em que você cria ResourceQuotas, em vez de definir um único limite para vários namespaces do Kubernetes.

Usar ResourceQuotas para aplicar cotas nos namespaces do Kubernetes não é o mesmo que usar um ClusterResourceQuota para aplicar uma cota em todos os namespaces do Kubernetes. Dividir uma cota com escopo de cluster entre diferentes namespaces do Kubernetes pode estar abaixo do ideal: a divisão pode superprovisionar cotas para alguns namespaces do Kubernetes e subprovisionar cotas para outros namespaces do Kubernetes.

Recomendamos que você otimize a alocação de cota ajustando dinamicamente a configuração de ResourceQuotas nos namespaces do Kubernetes, respeitando a quantidade total que a ClusterResourceQuota correspondente estabelece. Por exemplo, é possível aumentar ou diminuir dinamicamente os valores de cota aplicados pelo ResourceQuotas pods-secrets para evitar valores de provisionamento excessivo ou não para example-1 e example-2 namespaces do Kubernetes Os valores totais da cota para ResourceResources pods-secrets não podem exceder os valores da cota no ClusterResourceQuota correspondente.

Ao configurar o ResourceQuotas, considere as cotas e limites do GKE e as cotas e limites do GKE no VMware. Essas cotas e limites podem impor limites mais baixos do que os ResourceQuotas. Por exemplo, o GKE limita o número máximo de pods por nó, independentemente de como você configurou as ResourceQuotas.

Criar NetworkPolicies

O NetNamespaces do OpenShift permite configurar o isolamento de rede entre projetos do OpenShift. Com o OpenShift EgressNetworkPolicies, é possível controlar o tráfego de saída dos clusters do OpenShift. Nesta seção, usamos conceitos de restrição de tráfego.

Para migrar seus NetNamespaces e EgressNetworkPolicies, faça o seguinte:

Avalie os NetNamespaces e o EgressNetworkPolicies para entender como eles estão regulando o tráfego de rede entre projetos do OpenShift e de saída que saem dos clusters do OpenShift. Por exemplo, avalie o NetNamespace e o EgressNetworkPolicy que você exportou na seção 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
```
O example-project e o NetNamespaces example-project-2 definem uma rede de sobreposição com o mesmo valor de netid de 1234. Portanto, os pods no projeto example-project do OpenShift podem se comunicar com os pods no projeto example-project-2 do OpenShift e vice-versa.

osdefault EgressNetworkPolicy define as seguintes regras de tráfego de rede de saída:
- Permitir tráfego de saída para a sub-rede 1.2.3.0/24.
- negar o tráfego de saída que não corresponde a outras regras;

Crie políticas de NetworkPolicies e OPA para corresponder aos requisitos de restrição de tráfego de rede. Por exemplo, default-np e default-np-2 implementam as seguintes políticas:

As políticas aplicadas pela EgressNetworkPolicy de default.
As políticas aplicadas pelos NetNamespaces example-project e example-project-2 em namespaces com o rótulo netid definido como example-project e example-project-2:

As políticas são semelhantes às seguintes:

---
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

Gerenciar recursos do Kubernetes usando o Config Sync

Para gerenciar os recursos do Kubernetes e a configuração dos clusters do GKE, recomendamos que você use o Config Sync.

Para saber como ativar o Config Sync nos clusters do GKE, consulte Instalar o Config Sync.

Depois de provisionar e configurar o Config Sync no ambiente do GKE Enterprise, use-o para criar e aplicar automaticamente a configuração aos seus clusters do GKE.

A seguir

Leia sobre como começar a migração para o Google Cloud.
Saiba mais sobre as práticas recomendadas para criar e operar contêineres.
Conheça as práticas recomendadas para redes do GKE.
Entenda como aumentar a segurança do cluster.
Leia a visão geral de segurança do GKE.
Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.