Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/articles/2024/12/04/hosted-control-plane-operations
API hypershift.openshift.io를 통해 Hosted control plane (HCP) 기술을 사용하면 가볍고 유연하며 이기종 Red Hat OpenShift Container Platform 클러스터를 대규모로 생성하고 관리할 수 있습니다. 이 API는 HostedCluster와 NodePool이라는 두 가지 사용자 대상 리소스를 제공합니다. HostedCluster 리소스는 제어 플레인과 공통 데이터 플레인 구성을 캡슐화합니다. HostedCluster 리소스를 생성하면 연결된 노드 없이 완벽하게 작동하는 제어 플레인이 생성됩니다. NodePool 리소스는 HostedCluster 리소스에 연결된 확장 가능한 작업자 노드 집합입니다.
이 문서에서는 Red Hat OpenShift Virtualization 과 kubevirt 공급자를 사용하여 HostedCluster의 NodePool 워커 노드를 프로비저닝하는 호스팅 제어 플레인 토폴로지에 중점을 둡니다. 이는 현재 OpenShift Virtualization 기반에서 OpenShift 클러스터를 실행하는 데 지원되는 유일한 방법입니다.
이 작업은 처음에는 복잡해 보일 수 있으므로, NodePort 서비스를 사용하여 호스팅된 클러스터에서 실행되는 애플리케이션을 노출하고 외부에서 접근할 수 있도록 하는 방법을 설명하겠습니다.
OpenShift 클러스터의 하이퍼바이저로 OpenShift Virtualization을 사용하고 HCP 폼 팩터를 사용하면 다음과 같은 몇 가지 주요 이점이 있습니다.
- 동일한 기본 베어 메탈 인프라에 호스팅된 클러스터를 통합하여 리소스 활용도를 높였습니다.
- 호스팅된 제어 평면과 호스팅된 클러스터 간의 강력한 격리.
- 베어 메탈 노드 부트스트래핑 프로세스를 제거하여 클러스터 프로비저닝을 더 빠르게 수행할 수 있습니다.
- 단일 기반 OpenShift Container Platform 클러스터에서 여러 릴리스를 간편하게 관리합니다.
kubevirt 공급자를 사용하여 호스팅 클러스터를 설치하려면 이 문서를 참조하세요 .
그림 1은 Kubevirt 공급자의 고수준 설계를 적용한 호스팅 제어 평면을 나타냅니다.
그림 2에 표시된 대로, 이제 YAML 파일을 사용하여 호스팅된 클러스터에 “petclinic”이라는 애플리케이션을 배포해 보겠습니다 .
YAML 파일은 애플리케이션이 TCP 포트 8080, 8443, 8778에서 수신한다는 것을 보여줍니다.
ports:
- containerPort: 8080
protocol: TCP
- containerPort: 8443
protocol: TCP
- containerPort: 8778
protocol: TCP 일반적인 OpenShift 설치에서 다음 단계는 다음 Kubernetes 서비스 중 하나를 사용하여 애플리케이션을 노출하는 것입니다.
- ClusterIP
- NodePort
- LoadBalancer
b 클러스터가 OpenShift 베어 메탈 클러스터의 소프트웨어 정의 네트워크(SDN) 내에서 가상 머신(포드)으로 실행된다는 점을 고려할 때, 외부 세계에서 클러스터에서 실행되는 애플리케이션에 도달하는 간단한 방법을 찾아야 합니다.
클러스터에서 실행 중인 애플리케이션이 ClusterIP 서비스를 통해 노출된다고 가정해 보겠습니다. 이 경우, 수신된 클러스터 IP 주소는 격리된 호스팅 클러스터 네트워크에 속하며, 외부에서는 해당 IP 주소에 그대로 접근할 수 없습니다.
LoadBalancer Kubernetes 서비스를 사용하여 호스팅된 클러스터에서 실행되는 애플리케이션을 노출하는 경우 구성하기 전에 다음과 같은 다양한 요구 사항을 충족해야 합니다.
- MetalLB는 호스팅 클러스터에 설치되어야 합니다.
- 호스팅 클러스터에 보조 네트워크 인터페이스 컨트롤러(NIC)를 구성해야 합니다.
- 호스팅 클러스터에서 네트워크 연결 정의를 구성해야 합니다.
- 호스팅된 클러스터의 작업자 노드 역할을 하는 가상 머신에 보조 NIC를 구성해야 합니다.
- 클러스터에 올바른 IPAddressPool을 구성해야 합니다 (2계층 모드에서는 호스트 인터페이스를 지정할 필요가 없습니다) .
NodePort 서비스를 사용하여 호스팅된 클러스터에서 실행 중인 애플리케이션을 노출하는 것이, 특히 http/https가 아닌 서비스의 경우, 더 간단한 해결책이 될 수 있습니다. 이 경우 필요한 단계는 다음과 같습니다.
- Pod 애플리케이션을 타겟으로 하는 호스팅 클러스터에서 NodePort 서비스를 생성합니다.
- 클러스터의 워커 노드 역할을 하는 가상 머신의 포드를 대상으로 하는 호스팅 클러스터에 NodePort 서비스를 만듭니다.
NodePort 설명 시나리오에 초점을 맞춰 필요한 단계를 구현하는 방법을 살펴보겠습니다.
호스팅된 클러스터에서 NodePort 서비스를 만듭니다.
그림 3과 같이 호스팅된 클러스터에 NodePort 서비스 YAML 파일을 적용합니다 .
서비스는 각 OpenShift 노드의 IP 주소와 지정된 고정 포트(이 예에서는 TCP 30001, 30002, 30003)를 통해 액세스할 수 있으며, 이를 NodePort라고 합니다. 노드 포트의 가용성을 높이기 위해 쿠버네티스는 ClusterIP 유형의 서비스가 요청될 때 따르는 프로세스와 유사하게 클러스터 IP 주소를 설정합니다.
호스팅된 클러스터 노드는 그림 4에 표시되어 있습니다.
호스팅된 클러스터 노드의 IP 주소는 다음과 같습니다.
$oc get nodes -o wide | awk {'print $1" "$3" "$6'} | column -t
NAME ROLES INTERNAL-IP
cluster1-985defa1-cqv97 worker 10.131.0.192
cluster1-985defa1-cvmn6 worker 10.128.2.82HCP kubevirt 공급자를 사용하고 있으므로, 호스팅 클러스터의 노드는 호스팅 클러스터 관점에서는 가상 머신입니다. 그림 5를 참조하세요.
호스팅된 클러스터 노드에 할당된 IP 10.131.0.192주소는 10.128.2.82호스팅 클러스터에서 실행되는 가상 머신의 IP 주소와 동일하다는 점에 유의하세요.
이제 호스팅 클러스터에서 NodePort 서비스를 생성할 때 호스팅 클러스터에서 실행 중인 가상 머신의 일부 포트를 열게 된다는 점이 명확해졌을 것입니다. 호스팅에서 실행 중인 가상 머신은 포드(pod)로 실행되며 기본적으로 호스팅 클러스터의 포드 네트워크에 연결됩니다. 그림 6을 참조하십시오.
확인을 위해, 한 가상 머신의 virt-launcher 포드는 동일한 IP 주소(10.131.0.192)를 가지고 있으며, 이는 그림 7에 나와 있는 것처럼 호스팅 클러스터의 포드 네트워크의 일부입니다.
호스팅 클러스터에 NodePort 서비스를 만듭니다.
이제 호스팅 클러스터에 NodePort 서비스를 생성하여 가상 머신 포드에서 수신 대기하는 TCP 포트 30001, 30002, 30003을 노출해야 합니다. 서비스의 podSelector 레이블에는 여러 옵션이 있는데, 이는 호스팅 제어 플레인 프로세스가 설치 시 각 노드 풀에 다른 레이블을 추가하기 때문입니다. 이 경우, 호스팅 클러스터의 OpenShift 노드 역할을 하는 모든 가상 머신(포드)을 선택하기 때문에 다음 레이블이 선택되었습니다.
cluster.x-k8s.io/cluster-name=cluster1-8p5rc
이 YAML 파일을 사용하여 호스팅 클러스터에 NodePort 서비스를 만든 후, 그림 8에서 볼 수 있듯이 NodePort 서비스가 호스팅 클러스터의 노드에서 TCP 포트 30001, 30002, 30003을 열었음을 확인할 수 있습니다.
또한 NodePort 서비스가 가상 머신 포드를 올바르게 선택했음을 알 수 있습니다(그림 9).
호스팅 클러스터 노드에는 다음과 같은 IP 주소가 있습니다.
$oc get nodes -o wide | awk {'print $1" "$3" "$6'} | column -t
NAME ROLES INTERNAL-IP
ocp4-master1.aio.example.com control-plane,master 192.168.123.101
ocp4-master2.aio.example.com control-plane,master 192.168.123.102
ocp4-master3.aio.example.com control-plane,master 192.168.123.103
ocp4-worker1.aio.example.com worker 192.168.123.104
ocp4-worker2.aio.example.com worker 192.168.123.105
ocp4-worker3.aio.example.com worker 192.168.123.106
호스팅 워커 노드에서 포트가 올바르게 열려 있는지 확인하려면 노드 중 하나에서 디버그 포드를 열어 원하는 포트 중 하나가 수신 상태인지 확인해 보겠습니다.
$oc debug node/ocp4-worker3.aio.example.com
Temporary namespace openshift-debug-cphkq is created for debugging node... Starting pod/ocp4-worker3aioexamplecom-debug-mzrzx
To use host binaries, run `chroot/host`
Pod IP: 192.168.123.106
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot/host
sh-5.1# ss -tlnp | grep 30002
LISTEN Ø 4096 *:30002 *:* users: (("ovnkube", pid=6177, fd=26))이제 호스팅된 클러스터에서 실행되는 “petclinic” 애플리케이션이 호스팅 워커 노드 IP 주소( 192.168.123.104, 192.168.123.105, 192.168.123.106)와 30001 TCP 포트를 통해 외부에서 접근 가능한지 확인할 시간입니다 .
[root@ocp4-bastion ~]# curl -s 192.168.123.104:30001 | grep "pet" <img class="img-responsive" src="/resources/images/pets.png"/> [root@ocp4-bastion ~]# curl -s 192.168.123.105:30001 | grep "pet" <img class="img-responsive" src="/resources/images/pets.png"/> [root@ocp4-bastion ~]# curl -s 192.168.123.106:30001 | grep "pet" <img class="img-responsive" src="/resources/images/pets.png"/>
보시다시피, 호스팅된 클러스터에서 실행되는 “petclinic” 애플리케이션은 이제 외부에서도 접근할 수 있습니다.
결론
kubevirt 공급자를 사용하여 NodePort 서비스를 통해 호스팅된 콘트롤 플레인 에서 생성된 호스팅된 클러스터에서 실행되는 애플리케이션을 노출하면 많은 기회가 생기고(물론) 설명된 모든 절차는 Red Hat Advanced Cluster Management 및 OpenShift Gitops 기술 덕분에 GitOps 접근 방식을 사용하여 완전히 자동화될 수 있습니다 .
즐거운 시간 보내세요!
