[kubernetes] GKE Network

박원균·2021년 11월 18일

Kubernetes

목록 보기

17/24

GKE Network

kubernetes의 고급 소프트웨어 정의 네트워킹 = SDN을 사용 설정하면 동일한 리전 클러스터의 여러 영역에서 pod,서비스,노드의 패킷을 라우팅 및 전달할 수 있습니다.

k8s IP주소 관련 용어

knm은 IP 주소에 크게 의존하며 서비스, pod, 컨테이너, 노드는 IP 주소와 포트를 사용하여 통신합니다

ClusterIP: 서비스에 할당된 IP 주소
서비스 수명 기간동안 안정적으로 유지됩니다.
Pod IP : 특정 Pod에 할당된 IP 주소
일시적입니다.
Node IP : 특정 노드에 할당된 IP 주소

클러스터 내부 네트워킹

IP 할당

각 노드에는 클러스터 VPC 네트워크에서 할당되는 IP 주소가 있습니다. 이 IP를 가지고 노드의 kube proxy, kubelet과 같은 제어 구성요소에서 연결을 제공합니다.
각 노드는 GKE가 해당 노드에서 실행 중인 Pod를 할당하는 IP 주속 풀을 가지고 있습니다.

❕ 클러스터를 만들때 선택적으로 IP 범위를 지정할 수 있습니다. 가변형 pod CIDR 범위 기능을 사용하면 특정 노드 풀의 노드에 대항 pod IP 범위의 크기를 줄일 수 있습니다.
각 pod 에는 해당 노드의 pod CIDR 범위에서 핟랑된 단일 IP 주소가 있습니다.
❕ 이 주소는 pod 내에서 실행되는 모든 컨테이너가 공유하며 클러스터에서 실행 중인 다른 pod에 해당 컨테이너를 연결합니다.
각 서비스에는 클러스터의 VPC 네트워크에서할당된 ClusterIP라는 IP 주소가 있습니다. 원한다면 클러스터를 만들 때 VPC 네트워크를 맞출설정할 수 있습니다.

Pod

k8s는 노드에서 실행할 pod를 예약할 때 노드의 Linux 커널에 있는 pod의 네트워크 네임스페이스를만듭니다.

이 네트워크 네임스페이슨느 가상 네트워크 인터페이스를 사용하여 노드의 물맂거 네트워크 인터페이스를 pod와 연결하므로 퍀시에 pod를 오고 갈 수 있습니다.

노드의 루트 네트워크 네임스페이스에 있는 연결된 가상 네트워크 인터페이스가 Linux 브리지에 연결되어 동일 노드에서 pod 간 통신을 허용합니다. 또한 pod는 동일한 가상 인터페이스를 사용해서 노드외부로 패킷을 전송할 수 있습니다.

pod에서 실행되는 컨테이너 는 pod의 네트워크 네임스페이스를 사용합니다. 컨테이너의 관점에서 pod는 하나의 네트워크 인터페이스를 포함하는 물리적 머신으로 표시됩니다.

pod의 모든 컨테이너에는 동일한 네트워크 인터페이스가 표시됩니다. 각 컨테이너의 localhost는 pod를 통해 노드의 물리적 네트워크 인터페이스에 연결됩니다.

각 pod에서는 클러스터의 모든 노드에서 실행되는 다른 모든 pod에 대한 액세스가 제한되지 않지만 개발자가 pod간 액세스를 제한할 수 있습니다.

pod의 IP 주소는 구현에 따라 달라지므로 의존적이어서는 안됨.

서비스

k8s는 라벨을 사용하여 여러 관련된 pod를 서비스라고 부르는 논리 단위로 그룹화 합니다.

서비스는 안정적인 IP 주소 및 포트를 포함하며 개발자가 서비스를만들 때 라벨 선택기에서 정의하는 모든 라벨과 라벨이 일치하는 pod 집합 간에 부하 분산을 제공.

클라이언트 pod는 서비스 선택기와 정확하게 일치하지 않으므로 서비스의 일부가 아닙니다 하지만 클라이언트 pod는 동일한 크러스터에서 실행되기 때문에 서비스 중 하나와 통신 할 수 있습니다.

k8s는 사용 가능한 서비스 IP 주소의 클러스터 풀에서 새로 생성된 각 서비스에 안정적이고 신뢰할 수 있는 IP 주소를 할당합니다. DNS 항목을 추가하여 ClusterIP에 호스트 이름을 할당합니다.

IP및 이름은 고유하며 서비스 수명 주기 동안 변경되지 않습니다.

kube-Proxy

k8s는 kube-proxy 구성요소를 사용하여 pod와 서비스 간의 연결을 관리합니다.

인라인 프록시가 아니지만 ingress 기반 부하분산 컨트롤러인 kube-proxy는 k8s API 서버를 감시하고 노드의 iptables 하위 시스템에 대상 NAT 규칙을 추가 및 삭제하여 ClusterIP를 정상 상태의 pod에 계속 매핑합니다.

?? pod에서 실행되는 컨테이너가 서비스의 ClusterIP에 트래픽을 전송할 때 노드는 pod를 무작위로 선택하고 이 pod로 트래픽을 라우팅합니다.

port : 클라이언트가 애플리케이션에 연결하는 지점
'targetPort : 애플리케이션이 pod 내에서 트래픽을 실제로 리스닝하는 포트.

kube-proxy는 노드에서 iptables 규칙을 추가 및 삭제하여 이러한 포트 매핑을 관리합니다.

클러스터 외부 네트워킹

kube-proxy가 각 노드에서 모든 트래픽을 관리하기 때문에 기본적으로 pod는 외부 IP 주소를 노출하지 않습니다.

외부 부하 분산기
클러스터 및 Google Cloud VPC 네트워크 외부에서 들어오는 트래픽을 관리하며 Google Cloud 네트워크와 연결된 전달 규칙을 사용하여 트래픽을 k8s 노드로 라우팅합니다.
내부 부하 분산기
동일한 VPC 네트워크 내에서 들어오는 트래픽을 관리합니다. 외부 부하 분산기처럼 내부 부하 분산기도 Google Cloud 네트워크와 연결된 전달 규칙을 사용하여 트래픽을 k8s 노드로 라우팅합니다.
HTTP(S) 부하 분산기
HTTP(S) 트래픽에 사용되는 특수한 외부 부하 분산기 입니다. 전달 규칙 대신 인그레스 리소스를 사용해서 트래픽을 k8s 노드로 라우팅합니다.

트래픽이 Kubernetes 노드에 연결되면 부하 분산기 유형에 관계없이 동일한 방식으로 처리됩니다. 부하 분산기는 클러스터의 어떤 노드가 해당 서비스에 대해 pod를 실행 중인지 알 수 없습니다. 대신 관련 pod를 실행하지 않는 노드까지 포함해 클러스터의 모든 노드에 트래픽을 분산합니다. 리전 클러스터에서는 클러스터 리전의 모든 영역에 있는 모든 노드에 부하가 분산됩니다. 트래픽이 노드로 라우팅되면 노드는 동일 노드나 다른 노드에서 실행 중인 pod로 트래픽을 라우팅합니다. 노드는 kube-proxy가 노드에서 관리하는 iptables 규칙을 사용하여 무작위로 선택된 pod에 트래픽을 전달합니다.

부하 분산기가 노드로 보내는 트래픽은 다른 노드에 있는 pod로 전달 될 수 있습니다. 그러려면 추가 네트워크 홉이 필요합니다. 추가 홉을 피하려면 트래픽을 처음 수신하는 동일 노드에 있는 pod로 트래픽이 가야 한다로 지정할 수 있습니다.

외부 부하 분산기

클러스터 외부와 VPC 네트워크 외부에서 서비스에 연결해야 하는 경우 서비스를 정의할 때 서비스의 type필드를 Loadbalancer로 설정하여 서비스를 로밸로 구성할 수 있습니다. 그러면 GKE가 서비스 앞에 네트워크 부하 분산기를 프로비저닝합니다.

모든 노드를 인식하고 서비스의 외부 IP 주소를 사용하여 VPC 네트워크 외부에서 서비스에 대한 연결을 허용하도록 VPC 네트워크 방화벽 규칙을 구성합니다.

HTTP(S) 부하 분산기

RESTful 웹 서비스 API와 같은 많은 애플리케이션이 HTTP(S)를 사용하여 통신합니다. VPC 네트워크 외부의 클라이언트가 Kubernetes 인그레스 리소스를 사용해서 이 유형의 애플리케이션에 액세스하도록 허용할 수 있습니다. Ingress 리소스를 사용하면 호스트 이름 및 URL 경로를 클러스터 내의 서비스에 매핑할 수 있습니다. HTTP(S) 부하 분산기를 사용할 때는 ClusterIP뿐 아니라 NodePort도 사용하도록 서비스를 구성해야 합니다. 트래픽이 NodePort에서 노드의 IP로 서비스에 액세스할 때 GKE는 해당 서비스를 위한 정상 상태의 pod로 트래픽을 라우팅합니다. NodePort를 지정하거나 GKE가 사용되지 않는 포트를 무작위로 할당하도록 허용할 수 있습니다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - backend:
          serviceName: frontend
          servicePort: 80
  - host: demo-backend.example.com
    http:
      paths:
      - backend:
          serviceName: users
          servicePort: 8080

???

노드 간 연결 제한

클러스터의 노드를 타켓팅하는 인그레스 또는 이그레스 방화벽 규칙을 만들면 부정적인 영향을 미칠 수 있습니다.

예를 들어 이그레스 거부 규칙을 클러스터의 노드에 적용하면 NodePort, kubectl exec 등의 기능이 중단될 수 있습니다.

pod 및 서비스 연결 제한

pod 간 액세스 제한

네트워크 정책을 사용하여 pod 간 액세스를 제한할 수 있습니다. 네트워크 정책 정의를 사용하면 라벨, IP 범위, 포트 번호를 임의로 조합하고 이를 기준으로 pod의 인그레스 및 이그레스를 제한할 수 있습니다. 기본적으로는 네트워크 정책이 없으므로, 클러스터에 있는 pod 사이의 모든 트래픽이 허용됩니다. 네임스페이스에서 첫 번째 네트워크 정책을 만들면 다른 모든 트래픽이 즉시 거부됩니다.