Satellite 위치 및 클러스터에서 네트워크 설정 사용자 정의

Satellite Red Hat CoreOS

Satellite 네트워크 설정을 사용자 정의하여 사용자 위치에서 실행 중인 서비스 및 워크로드를 보다 잘 분리하고 세그먼트화하는 데 사용할 수 있는 여러 기능이 있습니다. 자세한 내용은 다음 섹션을 참고하십시오.

이러한 사용자 지정은 Red Hat CoreOS-enabled 위치에서만 사용할 수 있습니다.

적용할 네트워킹 사용자 정의에 따라 위치를 작성할 때, 클러스터를 작성할 때 또는 위치 및 클러스터를 설정한 후 CLI에서 특정 옵션을 지정해야 할 수 있습니다. 다음 태그는 사용자 정의를 적용할 시기를 표시합니다.

  • 위치 작성 중: 이러한 사용자 정의는 위치 작성 중에 CLI에서 적용되어야 합니다.
  • 클러스터 작성 중: 이러한 사용자 정의는 클러스터 작성 중에 CLI에서 적용할 수 있습니다.
  • 위치 및 클러스터 작성 후: 이러한 사용자 정의는 위치 및 클러스터를 작성한 후에 적용할 수 있습니다.

위치 작성 시 사용자 정의 서브넷 정의

위치 생성 중

CLI에서 위치를 작성할 때 다음 매개변수를 정의하여 위치에서 네트워킹을 사용자 정의할 수 있습니다. 자세한 정보는 ibmcloud sat location create 명령 참조를 참조하십시오.

--pod-subnet 옵션을 지정하여 팟 (Pod) 에 대한 사설 IP 주소를 제공하도록 사용자 정의 서브넷 CIDR을 지정할 수 있습니다. 이 옵션은 --coreos-enabled 플래그를 사용하여 Red Hat CoreOS 도 함께 활성화한 경우에만 사용할 수 있습니다. 서브넷의 크기는 최소한 /23 이상이어야 합니다. 기본값은 172.16.0.0/16입니다.

또한 --service-subnet 옵션을 지정하여 서비스에 대한 사설 IP 주소를 제공하도록 사용자 정의 서브넷 CIDR을 지정할 수 있습니다. 이 옵션은 --coreos-enabled 플래그를 사용하여 Red Hat CoreOS 도 함께 활성화한 경우에만 사용할 수 있습니다. 서브넷의 크기는 최소한 /24 이상이어야 합니다. 기본값은 172.20.0.0/16입니다.

위치 작성 시 팟 (Pod) 네트워크 인터페이스 정의

위치 생성 중

CLI에서 위치를 작성할 때 --pod-network-interface 를 정의하여 팟 (Pod) 네트워크 인터페이스를 설정할 수 있습니다. 사용 가능한 메소드는 can-reach 및 interface 입니다.

  • 직접 URL 또는 IP 주소를 제공하려면 can-reach=<url> 또는 can-reach=<ip_address> 을 지정합니다. 네트워크 인터페이스가 제공된 URL 또는 IP 주소에 연결할 수 있는 경우 이 옵션이 사용됩니다. 예를 들어 URL 을 지정하려면 can-reach=www.exampleurl.com, IP 주소를 지정하려면 can-reach=172.19.0.0 을 사용합니다.
  • Regex 문자열이 있는 인터페이스를 선택하려면 interface=<regex_string> 를 지정하십시오. 예를 들어, interface=eth.* 입니다.

자세한 정보는 ibmcloud sat location create 명령 참조를 참조하십시오.

클러스터 작성 시 팟 (Pod) 네트워크 인터페이스 정의

클러스터 생성 중

CLI에서 클러스터를 작성할 때 --pod-network-interface 를 정의하여 팟 (Pod) 네트워크 인터페이스를 설정할 수 있습니다. 사용 가능한 메소드는 can-reach 및 interface 입니다.

  • 직접 URL 또는 IP 주소를 제공하려면 can-reach=<url> 또는 can-reach=<ip_address> 을 지정합니다. 네트워크 인터페이스가 제공된 URL 또는 IP 주소에 연결할 수 있는 경우 이 옵션이 사용됩니다. 예를 들어 URL 을 지정하려면 can-reach=www.exampleurl.com, IP 주소를 지정하려면 can-reach=172.19.0.0 을 사용합니다.
  • Regex 문자열이 있는 인터페이스를 선택하려면 interface=<regex_string> 를 지정하십시오. 예를 들어, interface=eth.* 입니다.

자세한 정보는 ibmcloud oc cluster create satellite 명령 참조를 참조하십시오.

Satellite 클러스터에 대한 액세스 제한

위치 및 클러스터 생성 후

위치 및 클러스터를 작성한 후 ibmcloud ks cluster master satellite-service-endpoint allowlist add 명령을 사용하여 Satellite 클러스터의 서비스 엔드포인트 허용 목록에 서브넷을 추가할 수 있습니다. 해당 서브넷에서 발신된 클러스터 마스터에 대한 인증된 요청은 ‘ Satellite ’ 서비스 엔드포인트를 통해 허용됩니다. 제한사항을 적용하려면 허용 목록을 사용 으로 설정해야 합니다.

Calico 호스트 엔드포인트를 사용하여 네트워크 정책 작성

위치 및 클러스터 생성 후

버전 4.12 이상에서 Satellite 클러스터를 작성하는 경우, 모든 작업자 노드의 네트워크 인터페이스에 대해 클러스터에 배치되는 Calico Hostendpoint 인스턴스가 있습니다.

이러한 Hostendpoint 인스턴스를 사용하여 각 Hostendpoint 인스턴스에 추가되는 “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” 레이블을 사용하여 글로벌 네트워크 정책을 정의할 수 있습니다.

이 레이블 외에도 추가 사용자 정의 옵션을 위해 모든 작업자 노드의 레이블이 추가됩니다.

이 Hostendpoints 에는 “projectcalico-default-allow" 프로필이 있으므로 Hostendpoints 으로 업데이트하면 이전에 예상했던 동작이 4.12 으로 변경될 수 있습니다.

4.12로 업데이트하기 전에 이전에 예상한 모든 네트워킹 규칙, 정책 Hostendpoints 도 업데이트 후에 동일하게 작동하는지 확인하십시오.

자세한 정보는 Calico 문서를 참조하십시오.

NodePort 서비스 액세스 제한

위치 및 클러스터 생성 후

기본적으로 NodePort 서비스는 클러스터에 사용 가능한 모든 네트워크 인터페이스에서 액세스할 수 있습니다 (예: 0.0.0.0).

그러나 호스트에 여러 네트워크를 사용할 수 있는 Satellite 위치에서 서비스에 사용 가능한 네트워크 인터페이스를 제한할 수 있습니다.

범위를 제한하려면 클러스터 레벨에서 NodePort 서비스의 청취 주소를 제한합니다. 이 제한사항으로 인해 클러스터 관리자는 IP 서브넷을 허용된 청취 주소 범위로 사용하여 특정 네트워크 인터페이스에 대한 액세스를 제한할 수 있습니다. NodePort 서비스의 청취 주소 범위를 제한하도록 kube-proxy 구성요소를 재구성하려면 다음 단계를 완료하십시오.

node-port-addresses 를 잘못 구성하면 서비스가 올바른 소스에서 분리될 수 있습니다. 서비스에 필요한 모든 필수 서브넷을 계획해야 합니다. IBM Cloud 클러스터를 관리하기 위해 서브넷에 액세스할 필요가 없습니다.

  1. Red Hat OpenShift 클러스터에 액세스하십시오.

  2. NodePort 서비스에 액세스하도록 허용할 계획된 소스 서브넷 CIDR 목록을 준비하십시오.

  3. 다음 명령을 실행하여 network.operator.openshift.io 구성을 가져오고 변경사항을 되돌려야 하는 경우에 대비하여 사본을 저장하십시오.

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

  4. network.operator.openshift.io 구성을 편집하고 spec 섹션 아래에 서브넷 목록을 설정하고 NodePort 서비스에 대한 필수 서브넷을 포함하십시오.

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

  5. 변경사항을 저장하고 클러스터에 적용하십시오.

    oc apply -f updated-network-config.yaml

  6. 클러스터 버전 4.10.x 이하의 경우 클러스터 네트워크 운영자의 관리 상태를 Unmanaged 로 설정하십시오.

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

  7. 변경 사항을 적용하려면 kube-proxy DaemonSet 를 다시 시작하십시오. 이 작업은 업무에 지장을 주지 않습니다.

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

  8. 모든 kube-proxy 팟 (Pod) 이 다시 시작될 때까지 기다리십시오. 다음 명령을 실행하여 상태를 확인하십시오.

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

  9. 4.10.x 이전의 클러스터 버전의 경우, 클러스터 네트워크 운영자의 관리 상태를 Managed 로 재설정하십시오. 이 조치는 프록시 팟 (Pod) 을 다시 시작할 수 있습니다.

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

모든 팟 (Pod) 이 다시 시작되면 제한된 서브넷으로 클러스터가 구성됩니다. 이러한 단계를 반복하여 필요에 따라 서브넷 목록을 업데이트하거나 제거할 수 있습니다.

서비스별로 NetworkPolicies 를 사용하여 트래픽을 추가로 제한할 수 있습니다.