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:
- Projetos do OpenShift
- Cotas de recursos para cada projeto do OpenShift e cotas de recursos em vários projetos do OpenShift
- Papéis e ClusterRoles
- RoleBindings e ClusterRoleBindings
- Configuração de namespaces de rede do OpenShift e NetworkPolicies
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 prefixoopenshift.io
metadata.creationTimestamp
metadata.generation
metadata.managedFields
metadata.resourceVersion
metadata.selfLink
metadata.uid
status
- Qualquer campo aninhado em
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 projetoexample-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 arquivoproject-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 arquivoclusterresourcequota-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 arquivoclusterrole-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 arquivoclusterrolebinding-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 arquivonetnamespace-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 arquivoresourcequota-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 arquivorole-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 arquivorolebinding-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
default
EgressNetworkPolicy: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 arquivoegressnetworkpolicy-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 arquivonetworkpolicy-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 campospec.selector
do ClusterResourceQuota. Por exemplo, a ClusterResourceQuotafor-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 campospec.selector
impõe esses limites no projetofrontend
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 ClusterResourceQuotafor-name
. O projeto corresponde ao namespacefrontend
do Kubernetes. Portanto, você mapeia o ClusterResourceQuotafor-name
para o namespacefrontend
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 ClusterResourceQuotafor-name
igualmente entre os namespacesfrontend
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
eexample-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 NetNamespacesexample-project-2
definem uma rede de sobreposição com o mesmo valor denetid
de1234
. Portanto, os pods no projetoexample-project
do OpenShift podem se comunicar com os pods no projetoexample-project-2
do OpenShift e vice-versa.os
default
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;
- Permitir tráfego de saída para a sub-rede
Crie políticas de NetworkPolicies e OPA para corresponder aos requisitos de restrição de tráfego de rede. Por exemplo,
default-np
edefault-np-2
implementam as seguintes políticas:- As políticas aplicadas pela EgressNetworkPolicy de
default
. - As políticas aplicadas pelos NetNamespaces
example-project
eexample-project-2
em namespaces com o rótulonetid
definido comoexample-project
eexample-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
- As políticas aplicadas pela EgressNetworkPolicy de
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.