고정 IP 주소를 사용하도록 LoadBalancer 유형의 Kubernetes 서비스를 구성할 수 있습니다. 이 기능을 구현하기 전에 최소 구성 요소 요구 사항, 중요한 보안 고려 사항 및 클러스터 강화 지침을 알고 있어야 합니다.
최소 요구 사항
| 구성 요소 | 최소 요구 사항 | 추가 정보 |
|---|---|---|
| vCenter Server 및 ESXi | vSphere 7.0 업데이트 2 | 릴리스 정보를 참조하십시오. |
| 감독자 클러스터 | v1.19.1+vmware.2-vsc0.0.8-17610687 |
vSphere 네임스페이스 업데이트를 수행하여 감독자 클러스터 업데이트의 내용을 참조하십시오. |
| 로드 밸런서 | NSX-T Data Center v3.1 또는 NSX Advanced 20.1.x |
릴리스 정보를 참조하십시오. |
| Tanzu Kubernetes 릴리스 | 최신 Tanzu Kubernetes 릴리스 중 하나입니다. | 업데이트를 위한 Tanzu Kubernetes 클러스터 호환성 확인의 내용을 참조하십시오. |
LoadBalancer 유형의 서비스에 고정 IP 사용
일반적으로 LoadBalancer 유형의 Kubernetes 서비스를 정의할 때는 로드 밸런서에서 할당된 사용 후 삭제 IP 주소를 얻습니다. Tanzu Kubernetes 서비스 로드 밸런서 예의 내용을 참조하십시오.
또는 로드 밸런서에 대한 고정 IP 주소를 지정할 수 있습니다. 서비스를 생성할 때 로드 밸런서 인스턴스는 사용자가 할당한 고정 IP 주소로 프로비저닝됩니다.
loadBalancerIP 매개 변수와 IP 주소 값(이 예제의 경우
10.11.12.49)이 포함됩니다.
kind: Service
apiVersion: v1
metadata:
name: load-balancer-service-with-static-ip
spec:
selector:
app: hello-world
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
loadBalancerIP: 10.11.12.49
NSX Advanced Load Balancer의 경우 로드 밸런서가 설치될 때 구성된 IPAM 풀의 IP 주소를 사용합니다. 서비스가 생성되고 고정 IP 주소가 할당되면 로드 밸런서는 이 서비스를 할당된 것으로 표시하고 사용 후 삭제 IP 주소와 동일한 방식으로 IP 주소의 수명 주기를 관리합니다. 즉, 서비스가 제거되면 IP 주소 할당이 취소되고 재할당이 가능해집니다.
NSX-T 로드 밸런서의 경우 두 가지 옵션이 있습니다. 기본 메커니즘은 NSX Advanced Load Balancer와 동일합니다. 로드 밸런서가 설치될 때 구성된 IP 풀에서 가져온 IP 주소를 사용하는 것입니다. 고정 IP 주소가 할당되면 로드 밸런서는 자동으로 할당된 것으로 표시하고 해당 수명 주기를 관리합니다.
두 번째 NSX-T 옵션은 고정 IP 주소를 수동으로 미리 할당하는 것입니다. 이 경우 로드 밸런서에 할당된 외부 로드 밸런서 IP 풀의 일부가 아닌 부동 IP 풀에서 가져온 IP 주소를 대신 사용합니다. 이 경우 NSX Manager를 사용하여 IP 주소의 할당 및 수명 주기를 수동으로 관리합니다.
중요한 보안 고려 사항 및 강화 요구 사항
이 기능을 사용할 때 주의해야 할 잠재적인 보안 문제가 있습니다. 개발자가 Service.status.loadBalancerIP 값에 패치를 적용할 수 있으면 패치가 적용되어 있는 IP 주소로 향하는 클러스터의 트래픽을 개발자가 강탈할 수 있습니다. 특히, patch 권한이 있는 Role 또는 ClusterRole이 이 기능이 구현된 클러스터의 서비스 또는 사용자 계정에 바인딩된 경우 해당 계정 소유자는 자체 자격 증명을 사용하여 kubectl 명령을 실행하고 로드 밸런서에 할당된 고정 IP 주소를 변경할 수 있습니다.
로드 밸런서 서비스에 고정 IP 할당을 사용할 경우 발생할 수 있는 보안 위험을 피하려면 이 기능을 구현할 각 클러스터를 강화해야 합니다. 이렇게 하려면 개발자에 대해 정의한 Role 또는 ClusterRole이 apiGroups:"" 및 resources: services/status에 대한 patch 동사를 허용하지 않아야 합니다. 예제 역할 코드 조각은 이 기능을 구현할 때 하지 말아야 할 내용을 보여줍니다.
- apiGroups: - "" resources: - services/status verbs: - patch
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status
명령이 yes를 반환하면 사용자에게 패치 권한이 있습니다. 자세한 내용은 Kubernetes 설명서에서 API 액세스 확인을 참조하십시오.
개발자에게 클러스터에 대한 액세스 권한을 부여하려면 개발자에게 Tanzu Kubernetes 클러스터에 대한 액세스 권한 부여 항목을 참조하십시오. 사용자 지정할 수 있는 샘플 역할 템플릿에 대한 자세한 내용은 포드 보안 정책에 대한 역할 예 항목을 참조하십시오. 클러스터 액세스를 제한하는 방법에 대한 예는 https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example에서 참조하십시오.
