노드 내 가시성 설정

Autopilot Standard

---

이 가이드에서는 Google Kubernetes Engine(GKE) 클러스터에서 노드 내 가시성을 설정하는 방법을 보여줍니다.

노드 내 가시성은 포드가 동일한 노드에 있더라도 한 포드에서 다른 포드로 전송되는 트래픽이 클러스터의 Virtual Private Cloud(VPC) 네트워크에서 처리되도록 클러스터의 각 노드에서 네트워킹을 구성합니다.

노드 내 가시성은 기본적으로 Standard 클러스터에서 사용 중지되고, Autopilot 클러스터에서 사용 설정됩니다.

아키텍처

노드 내 가시성은 방화벽 규칙, 경로, 흐름 로그, 패킷 미러링 구성이 패킷에 적용되도록 포드 간에 전송되는 패킷이 항상 VPC 네트워크에서 처리되도록 합니다.

포드가 패킷을 동일한 노드의 다른 포드로 전송하면 패킷은 노드를 떠나서 Google Cloud 네트워크에서 처리됩니다. 그런 다음 패킷은 같은 노드의 대상 포드로 즉시 전송됩니다.

노드 내 가시성은 netd DaemonSet를 배포합니다.

이점

노드 내 가시성은 다음과 같은 이점을 제공합니다.

• 같은 노드에 있는 pod 간의 트래픽을 포함하여 pod 간의 모든 트래픽의 흐름 로그를 확인합니다.
• 같은 노드에 있는 포드 간 트래픽을 포함하여 포드 간의 모든 트래픽에 적용되는 방화벽 규칙을 만듭니다.
• 패킷 미러링을 사용하여 동일 노드의 포드 간 트래픽을 포함하여 트래픽을 클론하고 이를 검사하도록 전달합니다.

요구사항 및 제한사항

노드 내 가시성의 요구사항 및 제한사항은 다음과 같습니다.

• 클러스터가 GKE 버전 1.15 이상에 있어야 합니다.
• 노드 내 가시성은 Windows Server 노드 풀에서 지원되지 않습니다.
• 노드 내 가시성을 사용 설정하고 nonMasqueradeCIDRs 매개변수로 구성된 ip-masq-agent를 사용하는 경우 노드 내 연결 문제가 발생하지 않도록 nonMasqueradeCIDRs에 포드 CIDR 범위를 포함해야 합니다.

방화벽 규칙

노드 내 가시성을 사용 설정하면 동일 노드에서 포드 간에 전송되는 패킷을 포함하여 포드 간에 전송되는 모든 패킷이 VPC 네트워크에서 처리됩니다. 즉, VPC 방화벽 규칙 및 계층적인 방화벽 정책이 포드 위치에 관계없이 포드 간 통신에 일관되게 적용됩니다.

클러스터와의 통신을 위해 커스텀 방화벽 규칙을 구성한 경우 클러스터의 네트워킹 요구를 신중하게 평가해서 이그레스 및 인그레스 허용 규칙 집합을 결정합니다. 적법한 트래픽이 차단되지 않도록 연결 테스트를 사용할 수 있습니다. 예를 들어 네트워크 정책이 작동하려면 포드 간 통신이 필요합니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

• Google Kubernetes Engine API를 사용 설정합니다.
Google Kubernetes Engine API 사용 설정
• 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.
  참고: 기존 gcloud CLI 설치의 경우 compute/region 및 compute/zone 속성을 설정해야 합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다.

새 클러스터에서 노드 내 가시성 사용 설정

gcloud CLI 또는 Google Cloud 콘솔을 사용하여 노드 내 가시성이 사용 설정된 클러스터를 만들 수 있습니다.

gcloud

노드 내 가시성이 사용 설정된 단일 노드 클러스터를 만들려면 --enable-intra-node-visibility 플래그를 사용합니다.

gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --enable-intra-node-visibility

다음을 바꿉니다.

• CLUSTER_NAME: 새 클러스터의 이름입니다.
• COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.

콘솔

노드 내 가시성이 사용 설정된 단일 노드 클러스터를 만들려면 다음 단계를 수행합니다.

1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

   Google Kubernetes Engine으로 이동

2. 만들기를 클릭합니다.

3. 클러스터의 이름을 입력합니다.

4. 클러스터 구성 대화상자의 GKE Standard 옆에서 구성을 클릭합니다.

5. 필요에 따라 클러스터를 구성합니다.

6. 탐색창의 클러스터에서 네트워킹을 클릭합니다.

7. 노드 내 공개 상태 사용 설정 체크박스를 선택합니다.

8. 만들기를 클릭합니다.

기존 클러스터에 노드 내 가시성 사용 설정

gcloud CLI 또는 Google Cloud 콘솔을 사용하여 기존 클러스터에 노드 내 가시성을 사용 설정할 수 있습니다.

기존 클러스터에 노드 내 가시성을 사용 설정하면 GKE가 제어 영역 및 워커 노드 모두에서 구성요소를 다시 시작합니다.

gcloud

기존 클러스터에서 노드 내 가시성을 사용 설정하려면 --enable-intra-node-visibility 플래그를 사용합니다.

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

콘솔

기존 클러스터에서 노드 내 가시성을 사용 설정하려면 다음 단계를 수행합니다.

1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

   Google Kubernetes Engine으로 이동

2. 클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.

3. 네트워킹 아래에서 노드 내 가시성 수정을 클릭합니다.

4. 노드 내 공개 상태 사용 설정 체크박스를 선택합니다.

5. 변경사항 저장을 클릭합니다.

경고: 노드 내 가시성을 사용 설정하면 노드를 다시 만들 때 GKE에서 구성된 유지보수 기간을 준수합니다. 즉, 다음 유지보수 기간이 되기 전까지는 노드 내 가시성이 클러스터에서 작동하지 않습니다. 기다리지 않으려면 --cluster-version 플래그를 제어 영역에서 이미 실행 중인 것과 동일한 GKE 버전으로 설정하여 노드 풀을 수동으로 업그레이드합니다. 이러한 해결 방법을 사용하려면 gcloud CLI를 사용해야 합니다. 자세한 내용은 유지보수 기간 주의사항을 참조하세요.

노드 내 가시성 사용 중지

gcloud CLI 또는 Google Cloud 콘솔을 사용하여 클러스터에서 노드 내 가시성을 사용 중지할 수 있습니다.

기존 클러스터에 노드 내 가시성을 사용 중지하면 GKE가 제어 영역 및 워커 노드 모두에서 구성요소를 다시 시작합니다.

gcloud

노드 내 가시성을 사용 중지하려면 --no-enable-intra-node-visibility 플래그를 사용합니다.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

콘솔

노드 내 가시성을 사용 중지하려면 다음 단계를 수행합니다.

1. Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

   Google Kubernetes Engine으로 이동

2. 클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.

3. 네트워킹 아래에서 노드 내 가시성 수정을 클릭합니다.

4. 노드 내 가시성 사용 설정 체크박스를 선택 취소합니다.

5. 변경사항 저장을 클릭합니다.

경고: 노드 내 가시성을 사용 중지하면 노드를 다시 만들 때 GKE에서 구성된 유지보수 기간을 준수합니다. 즉, 다음 유지보수 기간이 되기 전까지는 노드 내 가시성이 사용 중지되지 않습니다. 기다리지 않으려면 --cluster-version 플래그를 제어 영역에서 이미 실행 중인 것과 동일한 GKE 버전으로 설정하여 노드 풀을 수동으로 업그레이드합니다. 이러한 해결 방법을 사용하려면 gcloud CLI를 사용해야 합니다. 자세한 내용은 유지보수 기간 주의사항을 참조하세요.

연습: 노드 내 가시성 확인

이 연습에서는 노드 내 가시성을 사용 설정하고 클러스터에서 작동하는지 확인하기 위해 필요한 단계를 보여줍니다.

이 연습에서는 다음 단계를 수행합니다.

1. us-central1 리전의 기본 서브넷에 흐름 로그를 사용 설정합니다.
2. us-central1-a 영역에서 노드 내 가시성을 사용 설정하여 단일 노드 클러스터를 만듭니다.
3. 클러스터에 포드 2개를 만듭니다.
4. 한 포드에서 다른 포드로 HTTP 요청을 보냅니다.
5. 포드 간 요청의 흐름 로그 항목을 확인합니다.

흐름 로그 사용 설정

1. 기본 서브넷에 대해 흐름 로그를 사용 설정합니다.

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. 기본 서브넷에 흐름 로그가 사용 설정되었는지 확인합니다.

   gcloud compute networks subnets describe default \
       --region=us-central1
   

   출력에서 다음과 비슷하게 흐름 로그가 사용 설정된 것을 확인할 수 있습니다.

   ...
   enableFlowLogs: true
   ...
   

클러스터 만들기

1. 노드 내 가시성이 사용 설정된 단일 노드 클러스터를 만듭니다.

   gcloud container clusters create flow-log-test \
       --zone=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

2. 클러스터의 사용자 인증 정보를 가져옵니다.

   gcloud container clusters get-credentials flow-log-test \
       --zone=us-central1-a
   

포드 2개 만들기

1. 포드를 만듭니다.

   다음 매니페스트를 pod-1.yaml이라는 파일에 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. 매니페스트를 클러스터에 적용합니다.

   kubectl apply -f pod-1.yaml
   

3. 두 번째 포드를 만듭니다.

   다음 매니페스트를 pod-2.yaml이라는 파일에 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

4. 매니페스트를 클러스터에 적용합니다.

   kubectl apply -f pod-2.yaml
   

5. 포드를 확인합니다.

   kubectl get pod pod-1 pod-2 --output wide
   

   다음과 비슷하게 포드의 IP 주소가 출력에 표시됩니다.

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   pod-1 및 pod-2의 IP 주소를 확인합니다.

요청 전송

1. 셸을 pod-1의 컨테이너로 가져옵니다.

   kubectl exec -it pod-1 -- sh
   

2. 셸에서 요청을 pod-2로 보냅니다.

   wget -qO- POD_2_IP_ADDRESS:8080
   

   POD_2_IP_ADDRESS를 pod-2의 IP 주소로 바꿉니다.

   출력에 pod-2에서 실행 중인 컨테이너의 응답이 표시됩니다.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. exit를 입력하여 셸을 종료하고 기본 명령줄 환경으로 돌아갑니다.

흐름 로그 항목 보기

흐름 로그 항목을 보려면 다음 명령어를 사용합니다.

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

다음을 바꿉니다.

• PROJECT_ID: 프로젝트 ID입니다.
• POD_1_IP_ADDRESS: pod-1의 IP 주소입니다.
• POD_2_IP_ADDRESS: pod-2의 IP 주소입니다.

출력에 pod-1에서 pod-2로의 요청 흐름 로그 항목이 표시됩니다. 이 예시에서 pod-1의 IP 주소는 10.56.0.13이고, pod-2의 IP 주소는 10.56.0.14입니다.

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

삭제

계정에 원치 않는 비용이 부과되지 않도록 다음 단계를 수행하여 생성된 리소스를 삭제합니다.

1. 다음과 같이 클러스터를 삭제합니다.

   gcloud container clusters delete -q flow-log-test
   

2. 기본 서브넷에 대해 흐름 로그를 사용 중지합니다.

   gcloud compute networks subnets update default --no-enable-flow-logs
   

다음 단계

• 클러스터 네트워크 정책 만들기에서 클러스터의 pod와 서비스 간 통신 제어 방법 알아보기
• VPC 기반 클러스터의 이점 알아보기