이 문서에서는 Google Distributed Cloud를 설치하고 운영하기 위한 네트워킹 요구사항을 개략적으로 설명합니다.
이 페이지는 기본 기술 인프라의 수명 주기를 관리하고 조직 네트워크를 설계하는 관리자 및 설계자, 운영자, 네트워킹 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 작업에 대해 자세히 알아보려면 일반 GKE 기업 사용자 역할 및 태스크를 참조하세요.
외부 네트워크 요구사항
Google Distributed Cloud는 운영을 위해 인터넷 연결이 필요합니다. Google Distributed Cloud는 Container Registry에서 클러스터 구성요소를 검색하고 클러스터는 Connect를 통해 등록됩니다.
HTTPS, 가상 사설망(VPN) 또는 Dedicated Interconnect 연결을 통해 공개 인터넷을 사용하여 Google에 연결할 수 있습니다.
관리 워크스테이션 및 클러스터 노드에 사용 중인 머신이 프록시 서버를 사용하여 인터넷에 액세스하는 경우 프록시 서버에서 특정 연결이 허용되어야 합니다. 자세한 내용은 프록시 뒤에 설치의 기본 요건 섹션을 참조하세요.
내부 네트워크 요구사항
Google Distributed Cloud는 클러스터 노드 간의 계층 2 또는 계층 3 연결로 작동할 수 있습니다. 부하 분산기 노드는 제어 영역 노드 또는 전용 노드 집합이 될 수 있습니다. 자세한 내용은 부하 분산기 선택 및 구성을 참조하세요.
MetalLB가 포함된 번들 계층 2 부하 분산(spec.loadBalancer.mode: bundled 및 spec.loadBalancer.type: layer2)을 사용하는 경우 부하 분산기 노드에 계층 2 인접성이 필요합니다. 부하 분산기를 제어 영역 노드에서 실행하든 전용 부하 분산 노드 집합에서 실행하든 계층 2 인접성 요구사항이 적용됩니다.
BGP를 사용한 번들 부하 분산은 계층 3 프로토콜을 지원하므로 엄격한 계층 2 인접성이 필요하지 않습니다.
부하 분산기 머신 요구사항은 다음과 같습니다.
- 번들 계층 2 부하 분산의 경우 특정 클러스터의 모든 부하 분산기가 동일한 계층 2 도메인에 있습니다. 제어 영역 노드도 동일한 계층 2 도메인에 있어야 합니다.
- 번들 계층 2 부하 분산의 경우 모든 가상 IP 주소(VIP)가 부하 분산기 머신 서브넷에 있고 서브넷의 게이트웨이로 라우팅할 수 있어야 합니다.
- 사용자가 인그레스 부하 분산기 트래픽을 허용해야 합니다.
포드 네트워킹
Google Distributed Cloud를 사용하면 노드당 포드를 최대 250개까지 구성할 수 있습니다. Kubernetes는 각 포드가 고유 IP 주소를 가질 수 있도록 각 노드에 클래스 없는 도메인 간 라우팅(CIDR) 블록을 할당합니다. CIDR 블록의 크기는 노드당 최대 포드 수에 해당합니다. 다음 표에는 노드당 구성된 최대 포드를 기준으로 Kubernetes가 각 노드에 할당하는 CIDR 블록의 크기가 나와 있습니다.
| 노드당 최대 포드 | 노드당 CIDR 블록 | IP 주소 수 |
|---|---|---|
| 32 | /26 | 64 |
| 33 – 64 | /25 | 128 |
| 65 – 128 | /24 | 256 |
| 129 - 250 | /23 | 512 |
노드당 250개 포드를 실행하려면 Kubernetes가 각 노드에 /23 CIDR 블록을 예약해야 합니다. 클러스터가 clusterNetwork.pods.cidrBlocks 필드에 기본값 /16을 사용한다고 가정하면 클러스터의 한도는 (2(23-16))=128개 노드가 됩니다. 이 한도를 초과하여 클러스터를 확장하려면 clusterNetwork.pods.cidrBlocks의 값을 늘리거나 nodeConfig.podDensity.maxPodsPerNode의 값을 낮추면 됩니다. 이 방법에는 몇 가지 단점이 있습니다.
고가용성을 가진 단일 사용자 클러스터 배포
다음 다이어그램은 단일 네트워크 구성에서 Google Distributed Cloud의 여러 주요 네트워킹 개념을 보여줍니다.
네트워크 요구사항을 충족하려면 다음 정보를 고려하세요.
- 제어 영역 노드는 부하 분산기를 실행하며, 모두 레이어 2 연결이 있으며, 작업자 노드를 포함한 다른 연결에는 레이어 3 연결만 필요합니다.
- 구성 파일은 워커 노드 풀의 IP 주소를 정의합니다.
구성 파일은 다음과 같은 목적으로 VIP를 정의합니다.
- 서비스
- 인그레스
- Kubernetes API를 통한 제어 영역 액세스
- Google Cloud 연결이 필요합니다.
포트 사용량
이 섹션에서는 Google Distributed Cloud 클러스터의 포트 요구사항을 설명합니다. 다음 표는 클러스터 및 부하 분산기 노드의 Kubernetes 구성요소에서 UDP 및 TCP 포트를 사용하는 방법을 보여줍니다.
제어 영역 노드
버전 1.29
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 관리자 클러스터 노드 프로비저닝 및 업데이트 | 관리 워크스테이션 |
| TCP | 인바운드 | 2379 - 2381 | etcd 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd |
| TCP | 인바운드 | 2382 - 2384 | etcd-events 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd-events |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 6444 | Kubernetes API 서버 | 전체 |
| TCP | 인바운드 | 9100 | auth-proxy | node-exporter |
| TCP | 인바운드 | 9101 | localhost에서만 노드 측정항목 제공
(버전 1.28 이상에 적용됨) |
node-exporter |
| TCP | 인바운드 | 9977 | API 서버에서 감사 이벤트 수신 | audit-proxy |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 10257 | kube-controller-manager
(버전 1.28 이상의 경우 포트 번호 변경) |
자체 |
| TCP | 인바운드 | 10259 | kube-scheduler
(버전 1.28 이상의 경우 포트 번호 변경) |
자체 |
| TCP | 인바운드 | 11002 | GKE Identity Service 핵심 컨테이너가 hostPort를 통해 포트에 바인딩됨
(버전 1.29 이상에 적용됨) |
자체 |
| TCP | 인바운드 | 14443 | ANG 웹훅 서비스 | kube-apiserver 및 ang-controller-manager |
버전 1.28
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 관리자 클러스터 노드 프로비저닝 및 업데이트 | 관리 워크스테이션 |
| TCP | 인바운드 | 2379 - 2381 | etcd 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd |
| TCP | 인바운드 | 2382 - 2384 | etcd-events 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd-events |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 6444 | Kubernetes API 서버 | 전체 |
| TCP | 인바운드 | 8444 | GKE Identity Service 핵심 컨테이너가 hostPort를 통해 포트에 바인딩됨
(버전 1.28에만 적용됨) |
전체 |
| TCP | 인바운드 | 9100 | auth-proxy | node-exporter |
| TCP | 인바운드 | 9101 | localhost에서만 노드 측정항목 제공
(버전 1.28 이상에 적용됨) |
node-exporter |
| TCP | 인바운드 | 9977 | API 서버에서 감사 이벤트 수신 | audit-proxy |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 10257 | kube-controller-manager
(버전 1.28 이상의 경우 포트 번호 변경) |
자체 |
| TCP | 인바운드 | 10259 | kube-scheduler
(버전 1.28 이상의 경우 포트 번호 변경) |
자체 |
| TCP | 인바운드 | 14443 | ANG 웹훅 서비스 | kube-apiserver 및 ang-controller-manager |
버전 1.16
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 관리자 클러스터 노드 프로비저닝 및 업데이트 | 관리 워크스테이션 |
| TCP | 인바운드 | 2379 - 2381 | etcd 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd |
| TCP | 인바운드 | 2382 - 2384 | etcd-events 서버 클라이언트 API, 측정항목, 상태
(버전 1.16 이상에 적용) |
kube-apiserver 및 etcd-events |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 6444 | Kubernetes API 서버 | 전체 |
| TCP | 인바운드 | 9100 | 측정항목 제공 | node-exporter |
| TCP | 인바운드 | 9443 | 제어 영역 구성요소의 제공/프록시 측정항목(이 포트 요구사항은 클러스터 버전 1.16 이하용입니다.) | kube-control-plane-metrics-proxy |
| TCP | 인바운드 | 9977 | API 서버에서 감사 이벤트 수신 | audit-proxy |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10251 | kube-scheduler |
자체 |
| TCP | 인바운드 | 10252 | kube-controller-manager |
자체 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 14443 | ANG 웹훅 서비스 | kube-apiserver 및 ang-controller-manager |
버전 1.15 이하
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 관리자 클러스터 노드 프로비저닝 및 업데이트 | 관리 워크스테이션 |
| TCP | 인바운드 | 2379 - 2381 | etcd 서버 클라이언트 API, 측정항목, 상태 | kube-apiserver 및 etcd |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 6444 | Kubernetes API 서버 | 전체 |
| TCP | 인바운드 | 9100 | 측정항목 제공 | node-exporter |
| TCP | 인바운드 | 9443 | 제어 영역 구성요소의 제공/프록시 측정항목(이 포트 요구사항은 클러스터 버전 1.16 이하용입니다.) | kube-control-plane-metrics-proxy |
| TCP | 인바운드 | 9977 | API 서버에서 감사 이벤트 수신 | audit-proxy |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10251 | kube-scheduler |
자체 |
| TCP | 인바운드 | 10252 | kube-controller-manager |
자체 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 14443 | ANG 웹훅 서비스 | kube-apiserver 및 ang-controller-manager |
워커 노드
버전 1.29
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 9100 | auth-proxy | node-exporter |
| TCP | 인바운드 | 9101 | localhost에서만 노드 측정항목 제공
(버전 1.28 이상에 적용됨) |
node-exporter |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 30000~32767 | 서비스 NodePort개 |
자체 |
버전 1.28
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 9100 | auth-proxy | node-exporter |
| TCP | 인바운드 | 9101 | localhost에서만 노드 측정항목 제공
(버전 1.28 이상에 적용됨) |
node-exporter |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 30000~32767 | 서비스 NodePort개 |
자체 |
버전 1.16
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 9100 | 측정항목 제공 | node-exporter |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 30000~32767 | 서비스 NodePort개 |
자체 |
버전 1.15 이하
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 9100 | 측정항목 제공 | node-exporter |
| TCP | 인바운드 | 10250 | API kubelet개 |
자체 및 제어 영역 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 30000~32767 | 서비스 NodePort개 |
자체 |
부하 분산기 노드
버전 1.29
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 인바운드 | 443 | 클러스터 관리 이 포트는 클러스터 구성 파일에서 |
전체 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP 및 UDP | 인바운드 | 7946 | MetalLB 상태 점검 | 부하 분산기 노드 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
| TCP | 인바운드 | 11000 | HAProxy 측정항목의 수신 포트(변경 불가)
(버전 1.29 이상에 적용됨) |
전체 |
| TCP | 인바운드 | 11001 | GKE Identity Service의 수신 포트(변경 불가)
(버전 1.29 이상에 적용됨) |
전체 |
버전 1.28
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 인바운드 | 443 | 클러스터 관리 이 포트는 클러스터 구성 파일에서 |
전체 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP 및 UDP | 인바운드 | 7946 | MetalLB 상태 점검 | 부하 분산기 노드 |
| TCP | 인바운드 | 8443 | GKE Identity Service의 수신 포트(변경 불가)
(버전 1.28에만 적용됨) |
전체 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
버전 1.16
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 인바운드 | 443 | 클러스터 관리 이 포트는 클러스터 구성 파일에서 |
전체 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 7946 | MetalLB 상태 점검 | 부하 분산기 노드 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
버전 1.15 이하
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 사용자 클러스터 노드 프로비저닝 및 업데이트 | 관리자 클러스터 노드 |
| TCP | 인바운드 | 443 | 클러스터 관리 이 포트는 클러스터 구성 파일에서 |
전체 |
| TCP | 둘 다 | 4240 | CNI 상태 확인 | 전체 |
| UDP | 인바운드 | 6081 | GENEVE 캡슐화 | 자체 |
| TCP | 인바운드 | 7946 | MetalLB 상태 점검 | 부하 분산기 노드 |
| TCP | 인바운드 | 10256 | 노드 상태 점검 | 전체 |
멀티 클러스터 포트 요구사항
멀티 클러스터 구성에서 추가된 클러스터에 다음 포트가 포함되어야 관리자 클러스터와 통신할 수 있습니다.
| 프로토콜 | 방향 | 포트 범위 | 목적 | 사용 주체 |
|---|---|---|---|---|
| TCP | 인바운드 | 22 | 클러스터 노드 프로비저닝 및 업데이트 | 모든 노드 |
| TCP | 인바운드 | 443 | 추가된 클러스터의 Kubernetes API 서버 이 포트는 |
제어 영역 및 부하 분산기 노드 |
방화벽 포트 구성
Red Hat Enterprise Linux(RHEL)에서 Google Distributed Cloud 실행을 위해 firewalld를 사용 중지할 필요는 없습니다. firewalld를 사용하려면 이 페이지의 포트 사용량에 설명된 대로 제어 영역, 작업자, 부하 분산기 노드에서 사용하는 UDP 및 TCP 포트를 열어야 합니다. 다음 예시 구성에서는 firewalld 명령줄 유틸리티인 firewall-cmd를 사용하여 포트를 여는 방법을 보여줍니다. 루트 사용자로 명령어를 실행해야 합니다.
제어 영역 노드 구성 예시
다음 명령어 블록은 제어 영역 노드를 실행하는 서버에서 필요한 포트를 여는 방법의 예시를 보여줍니다.
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
사용할 클러스터 버전의 특정 포트 요구사항은 앞의 포트 사용 섹션을 참조하세요. 샘플 명령어를 적절하게 업데이트합니다.
PODS_CIDR을 clusterNetwork.pods.cidrBlocks 필드에 구성된 포드에 예약된 CIDR 블록으로 바꿉니다. 포드의 기본 CIDR 블록은 192.168.0.0/16입니다.
워커 노드 예시 구성
다음 명령어 블록은 워커 노드를 실행하는 서버에서 필요한 포트를 여는 방법을 보여줍니다.
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
사용할 클러스터 버전의 특정 포트 요구사항은 앞의 포트 사용 섹션을 참조하세요. 샘플 명령어를 적절하게 업데이트합니다.
PODS_CIDR을 clusterNetwork.pods.cidrBlocks 필드에 구성된 포드에 예약된 CIDR 블록으로 바꿉니다. 포드의 기본 CIDR 블록은 192.168.0.0/16입니다.
부하 분산기 노드 예시 구성
다음 명령어 블록은 부하 분산기 노드를 실행하는 서버에서 필요한 포트를 여는 방법의 예시를 보여줍니다.
firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload
사용할 클러스터 버전의 특정 포트 요구사항은 앞의 포트 사용 섹션을 참조하세요. 샘플 명령어를 적절하게 업데이트합니다.
PODS_CIDR을 clusterNetwork.pods.cidrBlocks 필드에 구성된 포드에 예약된 CIDR 블록으로 바꿉니다. 포드의 기본 CIDR 블록은 192.168.0.0/16입니다.
RHEL 9.2 및 9.4의 추가 구성
Red Hat Enterprise Linux(RHEL) 버전 9.2 및 9.4는 버전 1.29.400 이상에서 GA로 지원됩니다. RHEL 버전 9.2 및 9.4에서는 서비스 및 포트가 올바르게 기능하기 위해 노드에서 추가 firewalld 구성을 수행해야 합니다.
노드의 활성 인터페이스를 나열하여 기본 노드 인터페이스를 찾습니다.
firewall-cmd --list-interfacesLinux 머신 인터페이스의 이름 지정 규칙에 따라 기본 인터페이스 이름은
eth0,eno1,ens1,enp2s0중 하나로 표시될 수 있습니다.노드의 영역을 나열하여 기본 인터페이스에서 사용하는 영역을 찾습니다.
firewall-cmd --list-all-zones예를 들어 기본 인터페이스가
eno1인 경우 다음 응답 섹션은 기본 인터페이스가public영역에 있음을 나타냅니다.... public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: ...다음 firewalld 명령어를 실행하여 RHEL 9.2 또는 9.4의 커스텀 영역 및 정책 세부정보를 설정합니다.
firewall-cmd --permanent --new-zone=cilium firewall-cmd --permanent --zone=cilium --add-interface=cilium_host firewall-cmd --permanent --zone=cilium --set-target ACCEPT firewall-cmd --permanent --zone=cilium --add-masquerade firewall-cmd --permanent --zone=cilium --add-forward firewall-cmd --permanent --new-policy cilium-host-port-forwarding firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT firewall-cmd --reload이전 단계에서 찾은 항목에 따라
IN_ZONE을 다음 값 중 하나로 바꿉니다.public: 선택된 수신 연결만 허용되는 공공 구역에서 사용할 사전 정의된 영역입니다.trusted: 모든 네트워크 연결이 허용되는 제어된 환경에서 사전 정의된 영역입니다.- 정의한 커스텀 영역의 이름입니다.
공급업체 문서에 따라 스토리지 솔루션을 구성합니다.
예를 들어 Portworx를 사용하여 스테이트풀(Stateful) 워크로드를 관리하는 경우 Portworx 네트워크 요구사항에 열린 상태로 유지해야 하는 포트가 나열됩니다.
공급업체 문서에 나열된 각 포트에 대해 다음 명령어를 실행합니다.
firewall-cmd --permanent --zone=public --add-port=PORT_INFOPORT_INFO를 포트 번호 또는 프로토콜이 뒤에 추가된 포트 번호 범위로 바꿉니다. 예를 들면10250-10252/tcp입니다.
포트 구성 확인
포트 구성을 확인하려면 제어 영역, 작업자, 부하 분산기 노드에서 다음 단계를 따르세요.
다음 Network Mapper 명령어를 실행하여 어떤 포트가 열려 있는지 확인합니다.
nmap localhost다음 명령어를 실행하여 firewalld 구성 설정을 가져옵니다.
firewall-cmd --info-zone=public firewall-cmd --info-zone=k8s-pods firewall-cmd --list-all-policies필요한 경우 이전 섹션의 명령어를 다시 실행하여 노드를 올바르게 구성합니다. 루트 사용자로 명령어를 실행해야 할 수 있습니다.
firewalld의 알려진 문제
Red Hat Enterprise Linux(RHEL)에서 사용 설정된 firewalld로 Google Distributed Cloud를 실행할 때 firewalld를 변경하면 호스트 네트워크에서 Cilium iptables 체인이 삭제될 수 있습니다. iptables 체인은 anetd 포드 시작 시 추가됩니다. Cilium iptables 체인이 손실되면 노드의 포드에서 노드 외부의 네트워크 연결이 끊어집니다.
iptables 체인을 삭제하는 firewalld의 변경사항에는 다음이 포함되지만 이에 국한되지 않습니다.
systemctl을 사용하여firewalld다시 시작명령줄 클라이언트(
firewall-cmd --reload)로firewalld새로고침
iptables 체인을 삭제하지 않고 firewalld 변경사항을 적용하려면 노드에서 anetd를 다시 시작합니다.
다음 명령어로
anetd포드를 찾아 삭제하고anetd를 다시 시작합니다.kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZANETD_XYZ를
anetd포드의 이름으로 바꿉니다.