Definindo sub-redes customizadas ao criar seu local

Durante a criação do local

Ao criar seu local na CLI, é possível definir os seguintes parâmetros para customizar a rede em seu local. Para obter mais informações, consulte a ibmcloud sat location create referência de comandos.

É possível especificar a opção --pod-subnet para especificar um CIDR de sub-rede customizado para fornecer endereços IP privados para os pods Essa opção só pode ser usada se você também ativar Red Hat CoreOS com o sinalizador --coreos-enabled. A sub-rede deve ter, no mínimo, o tamanho de /23 ou mais. O valor padrão é 172.16.0.0/16.

Também é possível especificar a opção --service-subnet para especificar um CIDR de sub-rede customizado para fornecer endereços IP privados para serviços.. Essa opção só pode ser usada se você também ativar Red Hat CoreOS com o sinalizador --coreos-enabled. A sub-rede deve ter, no mínimo, o tamanho de /24 ou mais. O valor padrão é 172.20.0.0/16.

Definindo a interface de rede do pod ao criar seu local

Durante a criação do local

Ao criar seu local na CLI, é possível definir o --pod-network-interface para configurar a interface de rede do pod.. Os métodos disponíveis são can-reach e interface.

• Para fornecer um endereço IP ou URL direto, especifique can-reach=<url> ou can-reach=<ip_address>. Se a interface de rede puder acessar o endereço URL ou IP fornecido, essa opção será usada. Por exemplo, use can-reach=www.exampleurl.com para especificar um endereço URL e can-reach=172.19.0.0 para especificar um endereço IP.
• Para escolher uma interface com uma sequência de Regex, especifique interface=<regex_string>; por exemplo, interface=eth.*

Para obter mais informações, consulte a ibmcloud sat location create referência de comandos.

Definindo a interface de rede do pod ao criar seu cluster

Durante a criação do cluster

Ao criar seu cluster na CLI, é possível definir o --pod-network-interface para configurar a interface de rede do pod.. Os métodos disponíveis são can-reach e interface.

• Para fornecer um endereço IP ou URL direto, especifique can-reach=<url> ou can-reach=<ip_address>. Se a interface de rede puder acessar o endereço URL ou IP fornecido, essa opção será usada. Por exemplo, use can-reach=www.exampleurl.com para especificar um endereço URL e can-reach=172.19.0.0 para especificar um endereço IP.
• Para escolher uma interface com uma sequência de Regex, especifique interface=<regex_string>; por exemplo, interface=eth.*

Para obter mais informações, consulte a ibmcloud oc cluster create satellite referência de comandos.

Limitando o acesso ao cluster do Satellite

Após a localização e a criação do cluster

Depois de criar seu local e cluster, é possível usar o comando ibmcloud ks cluster master satellite-service-endpoint allowlist add para incluir uma sub-rede em uma lista de permissões do terminal em serviço do cluster do Satellite. As solicitações autorizadas ao mestre do cluster que se originam da sub-rede são permitidas por meio do ponto de extremidade do serviço Satellite. A lista de permissões deve ser ativada, para que as restrições sejam aplicadas

Criando políticas de rede usando terminais de host do Calico

Após a localização e a criação do cluster

Se você criar um cluster do Satellite na versão 4.12 e mais recente, haverá instâncias do Calico Hostendpoint que serão implementadas no cluster para cada interface de rede do nó do trabalhador.

É possível usar essas instâncias do Hostendpoint para definir políticas de rede globais com a ajuda do rótulo “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” que é incluído em cada instância do Hostendpoint

Além dessa etiqueta, todas as etiquetas do nó do trabalhador são incluídas para opções de customização adicionais

Esses Hostendpoints têm o perfil “projectcalico-default-allow", o que significa que esses Hostendpoints podem alterar o comportamento esperado anteriormente quando você atualizar para 4.12.

Antes de atualizar para 4.12, certifique-se de que todas as regras de rede, políticas Hostendpoints esperadas anteriormente funcionem da mesma forma após a atualização.

Para obter mais informações, consulte a documentação doCalico

Restringindo o acesso ao serviço NodePort

Após a localização e a criação do cluster

Por padrão, os serviços NodePort são acessíveis em todas as interfaces de rede que estão disponíveis para o cluster, por exemplo 0.0.0.0.

No entanto, em locais Satellite locais onde várias redes estão disponíveis para os hosts, você pode limitar as interfaces de rede disponíveis para seus serviços.

Para limitar o intervalo, você restringe os endereços de atendimento para serviços NodePort no nível do cluster. Esta restrição permite que o administrador do cluster limite o acesso a uma interface de rede específica usando a sub-rede IP como a faixa de endereço de atendimento permitido. Complete as etapas a seguir para reconfigurar o componente kube-proxy para limitar a faixa de endereço de atendimento para seus serviços NodePort.

Configurar incorretamente o node-port-addresses pode isolar seus serviços de fontes válidas. Certifique-se de planejar todas as sub-redes necessárias para o serviço. O site IBM Cloud não exige acesso a nenhuma sub-rede para gerenciar os clusters.

1. Acesse o seu Red Hat OpenShift cluster.

2. Prepare sua lista de subnet CIDR de fonte planejada que você deseja permitir acessar os Serviços NodePort.

3. Execute o seguinte comando para obter a configuração network.operator.openshift.io e salve uma cópia no caso de você precisar reverter as alterações.

   kubectl get network.operator.openshift.io cluster -o yaml
   

4. Edite a configuração network.operator.openshift.io e configure a lista de sub-net sob a seção spec e inclua as sub-redes necessárias para o seu serviço NodePort.

   spec:
     kubeProxyConfig:
       proxyArguments:
         node-port-addresses:
         - 192.0.2.0/24
         - 198.51.100.0/24
   

5. Salve suas alterações e aplique-as no cluster.

   oc apply -f updated-network-config.yaml
   

6. Para a versão cluster 4.10.x e anterior, configure o estado de gerenciamento do operador de rede de cluster para Unmanaged.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Unmanaged"}}'
   

7. Reinicie o serviço “ kube-proxy ” ( DaemonSet ) para aplicar as alterações. Essa operação não causa interrupções.

   oc rollout restart ds -n openshift-kube-proxy openshift-kube-proxy
   

8. Aguarde até que todos os seus pods kube-proxy sejam reiniciados. Verifique o status executando o comando a seguir.

   oc get po -n openshift-kube-proxy --selector app=kube-proxy
   

9. Para versão de cluster do 4.10.x e anterior, reajuste o estado de gerenciamento do operador da rede de cluster para Managed. Observe que esta ação pode reiniciar os pods de proxy.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Managed"}}'
   

Depois que todos os pods são reiniciados, seu cluster é configurado com as sub-redes restritas. Você pode repetir essas etapas para atualizar ou remover a lista de subnet conforme necessário.

Você pode restringir ainda mais o tráfego usando NetworkPolicies em uma base por serviço.