[Kubernetes Best Practice] 9. 네트워킹, 네트워크 보안, 서비스 메시

이 글은 Kubernetes Best Practice를 읽고개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다.모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다.

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

쿠버네티스 네트워크 규칙

쿠버네티스 내부 네트워크는 상당히 복잡한 주제입니다. 이 책에서는 네트워크의 동작 방식에 대한 정확한 설명은 포함되어 있지 않지만 쿠버네티스를 사용하면서 필요한 컴포넌트 간의 통신 방법에 대해서 다루고 있습니다.

만약 쿠버네티스 네트워크에 대해 내용이 궁금하신 분은 커피 고래님의 글에서 보다 자세한 내용을 확인하실 수 있습니다.

---

동일한 Pod에 속해있는 컨테이너 간 통신

동일한 Pod에 속해있는 컨테이너는 localhost를 통해 상호 통신이 가능합니다. 즉, 동일한 네트워크를 사용하고 있고 이로 인해 각 컨테이너는 다른 포트를 열어두어야 합니다. 이러한 동작이 가능한 이유는 Pod의 내부에서 동작하고 있는 pause 컨테이너 떄문입니다. pause 컨테이너는 네트워크 네임스페이스를 동일한 Pod에 존재하는 컨테이너들에게 공유하고 이로 인해 컨테이너들은 동일한 네트워크를 사용할 수 있게 됩니다.

pause 컨테이너에 대한 자세한 설명은 alice_k106님의 글에서 확인하실 수 있습니다. 이해하기 쉽게 설명되어 있으니 읽어보시는 것을 추천합니다.

---

Pod 간의 통신

쿠버네티스 클러스터 내의 Pod은 NAT없이 통신할 수 있어야 합니다. 즉, 동일한 클러스터에 속해있는 Pod은 각자 가지고 있는 IP 그대로 (Node IP가 아닌 Pod IP) 다른 Pod과 통신할 수 있습니다.

---

Service와 Pod 간의 통신

Kubernetes는 Pod의 IP는 임시적이기 때문에 Service를 통해 고정된 IP 및 포트를 통해 일관된 접근 방법을 제공합니다. Service는 selector를 통해 매칭되는 Endpoint에게 트래픽을 전달합니다.

서비스를 구현하는 내부 기술은 user-space mode에서 1.2 이후부터 iptable을 사용하는 방식으로 변경되었습니다. 두 방법의 차이점에 대해 간단히 말하자면 user-space mode는 kube-proxy가 직접 프록시 역할을 수행하는 것과 다르게 iptable mode는 kube-proxy는 netfilter에게 proxy의 역할을 위임하게 됩니다.

---

네트워크 플러그인

Kubernetes는 플러그인이 가능한 아키텍쳐를 위해 네트워크 표준을 제시하였습니다. 여기서는 2개의 네트워크 플러그인에 대해서 다루고 있습니다.

Kubenet

Kubenet은 Kubernetes가 제공하는 네트워크 플러그인입니다. kubenet은 cbr0라는 리눅스 브릿지를 만들고 각 쌍의 호스트 끝이 cbr0에 연결된 Pod에 대한 veth 쌍을 만듭니다. 쌍의 Pod 끝에는 CIDR 범위 내의 IP를 할당받게 됩니다.
(문서 참고)

이 부분에 대해서는 평소 클라우드 프로바이더를 통해서만 쿠버네티스 클러스터를 사용했었고 온프레미스 환경에서 사용해본적이 없어 알지 못한 부분이었습니다. 온프레미스 환경에서 쿠버네티스 클러스터를 구축해야하는 경우, Pod의 CIDR 범위나 라우팅 규칙과 같은 견고한 네트워크 관리가 필요하다고 합니다.

---

CNI 플러그인

CNI는 CNI와의 인터페이스, API 동작, CRI와의 인터페이스와 같은 기능을 요구하는 명세입니다. CNI 플러그인을 개발 및 선택할 때 고려해야 할 점은 다음과 같습니다.

• 구축한 인프라의 네트워킹 목표를 달성하기 위해 필요한 기능이 있는지 살펴봐야 합니다. ex) 고가용성, 멀티 클라우드 연결 etc.

• 네트워크 보안/관리 등에 사용되는 도구와 CNI 플러그인이 호환되는지 확인해야 합니다.

---

쿠버네티스 서비스

앞서 말씀드린 것처럼 Pod은 임시적인 특성을 가지기 때문에 Pod에 일관된 방법으로 접근하기 위해 Kubernetes는 Service라는 방법을 제공합니다. 이 때 서비스에 할당된 IP와 Port를 실제 Pod(Endpoint)에 매핑하는 역할을 kube-proxy가 수행하게 됩니다.

서비스는 4가지의 기본 타입을 가지고 있습니다.

ClusterIP

서비스 타입을 명시하지 않을 때 가지게 되는 기본 값입니다. ClusterIP는 서비스의 지정된 CIDR 범위 내에서 IP가 할당되는 방식입니다. 서비스를 선언하게 되면 클러스터 내에서 *my-svc.my-namespace.svc.cluster-domain.example *의 DNS 이름이 생성되고 이를 통해 다른 서비스 및 오브젝트와 통신할 수 있습니다.

서비스는 Selector를 통해 Endpoint를 매핑하는데 만약 Selector가 지정되지 않았다면 특정 Endpoint와 Port를 추가하는 Endpoint API를 사용해 명시적으로 정의할 수 있습니다. 해당 방법은 테스트 시점에는 클러스터에 없는 DB를 사용하고 배포 이후 클러스터에 배포되는 DB로 서비스를 변경하는 시나리오 등에 유용하게 사용할 수 있습니다.

---

Nodeport

Nodeport 타입은 클러스터의 각 노드의 고수준 포트(30000 ~ 32767)를 각 노드의 서비스 IP와 포트에 할당하는 방법입니다. 클러스터 외부에서 서비스에 직접 접근하기 위해서는 NodeIP:NodePort를 통해 접근할 수 있습니다.

---

ExternalName

클러스터 수준에서의 DNS 이름을 외부 DNS 서비스에 전달할 때 사용됩니다. 실제로 현업에서는 사용하는 경우가 제한적이라고 하며 클라우드 프로바이더에서 제공하는 고유 DNS를 가지는 솔루션을 사용할 때 사용할 수 있습니다.

---

LoadBalancer

쿠버네티스 클러스터 공급자가 제공하는 로드 밸런싱 메커니즘을 배포할 수 있는 유일한 방법이 바로 LoadBalancer 타입입니다. 클라우드 프로바이더를 통해 쿠버네티스 클러스터를 사용하는 경우 각 클라우드에 존재하는 로드밸런싱 기능을 활성화하기 위한 어노테이션이 존재하고, 이를 통해 로드 밸런싱 설정을 할 수 있습니다.

---

Ingress

위의 4가지 타입처럼 쿠버네티스의 서비스 타입은 아니지만 트래픽 관리를 위해 Ingress에 대해 알아둘 필요가 있습니다. 기본적으로 Kubernetes Service는 L4 수준의 로드 밸런싱을 제공합니다. 하지만 어플리케이션을 운영하며 이보다 세밀한 즉, L7 수준의 로드 밸런싱이 필요한 경우가 분명 존재합니다.

Ingress는 L7 수준의 로드 밸런서로 호스트 및 라우팅 규칙을 기반으로 특정 서비스에게 트래픽을 전달합니다. 예를 들면 /login 경로로 들어오는 트래픽은 로그인 기능을 수행하는 Pod과 매핑되어 있는 Service로, /buy 경로로 들어오는 트래픽은 구매 기능을 수행하는 Pod과 매핑된 Service로 트래픽을 전달할 수 있습니다. 또한 TLS와 같은 보안 관련 설정들도 Ingress에서 진행할 수 있습니다.

Ingress는 트래픽 규칙을 정의한 오브젝트이기 때문에 실제 트래픽에 해당 규칙을 적용하기 위해서는 Ingress Controller가 필요합니다. Ingress Controller로는 NGINX나 HAProxy와 같이 다양한 솔루션을 선택할 수 있습니다.

---

네트워크를 쉽게 관리하기 위해 책에서 제시하는 서비스 및 인그레스 관련 모범 사례는 다음과 같습니다.

• 클러스터 외부에서 접근하는 서비스 수를 제한하는 것이 좋습니다. 대부분의 서비스는 클러스터 내부에서만 접근 가능하도록 ClusterIP 타입을 사용하고 외부 접근이 필요한 서비스만 노출하는 것이 이상적입니다.

• 외부에 노출하는 서비스가 HTTP/HTTPS 기반이라면 Ingress를 사용하는 것이 좋습니다. Ingress를 사용함으로써 어플리케이션은 트래픽과 관련된 기능을 Ingress에게 위임할 수 있고 비즈니스 로직에 집중할 수 있습니다.

• 인그레스 컨트롤러를 사용할 때 HA가 고려되었는지 확인하고 처리량을 확인해야 합니다. 메트릭을 수집해 인그레스 컨트롤러를 적절하게 확장하고 확장을 수행하는 동안 클라이언트가 중단되지 않는 시나리오를 검증해야 합니다.

---

네트워크 보안 정책

쿠버네티스는 NetworkPolicy API를 통해 Ingress/Egress 접근을 제어할 수 있습니다. Network Policy API의 명세에는 podSelector, ingress, egress, policyType 필드가 존재하며 podSelector를 통해 Pod을 선택할 수 있습니다. 만약 Pod을 지정하지 않으면 동일한 네임스페이스에 존재하는 모든 Pod에 적용됩니다.

선택된 Pod은 정의된 Ingress, Egress 규칙에 허용되는 Whitelist를 생성하고 해당 Pod에 대한 요청은 오직 Whitelist만 허용됩니다. 만약 Ingress와 Egress가 명시되지 않았을 경우에는 모든 인바운드 트래픽 / 아웃바운드 트래픽이 차단됩니다.

하나의 예시로 Frontend => Backend => DB Layer로 이루어진 어플리케이션이 존재한다고 가정해보겠습니다. Frontend 서비스는 모든 곳에서 접근이 가능해야하며, Backend는 오직 Frontend 서비스에서만, DB는 오직 Backend 서비스에서만 접근이 허용되어야 합니다. 이를 위한 NetworkPolicy 설정은 다음과 같습니다.

먼저 모든 인바운드에 대한 트래픽을 차단한 이후, 각 목적에 맞는 인바운드를 허용하기 위한 Ingress를 정의해줄 수 있습니다. 여기서 모든 인바운드에 대한 트래픽을 차단하는 이유는 실수로 네트워크 정책을 삭제하더라도 외부로 서비스가 노출되지 않도록 하기 위함입니다.

apiVersion: networking.k82.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k82.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      app: "frontend"
  policyTypes:
  - Ingress
  ingress:
  - {}
---
apiVersion: networking.k82.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: "backend"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: "frontend"

---
apiVersion: networking.k82.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      app: "db"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: "backend"  

---

책에서 제시하는 네트워크 정책을 설정 및 관리할 때 모범 사례는 다음과 같습니다.

• 각 네임스페이스에 모든 인바운드를 차단하는 기본 트래픽을 정의하면 실수로 네트워크 정책을 삭제하더라도 노출을 막을 수 있습니다.

• 어플리케이션 워크로드를 동일한 네임스페이스에 배치하여 네트워크 정책을 단순하게 만드는 것이 관리에 용이합니다.

---

서비스 메시

클러스터 규모가 커질수록 트래픽에 대한 관리의 난이도가 점차 증가합니다. 서비스 메시는 사이드카 프록시를 통해 어플리케이션에서 가지고 있던 네트워크와 관련된 복잡성을 제거할 수 있는 방법입니다. 서비스 메시와 관련된 내용은 서비스 메시 시리즈에서 다루었기 때문에 따로 다루지는 않겠지만, 서비스 메시를 도입할 때 고려해야 할 점들에 대해서 간단하게 다루어보고자 합니다.

작년 면접을 진행하면서 궁금했던 부분은 Tracing를 어떻게 일반화 시켜 적용할 수 있는지 였습니다. 당시 면접관님께서 해주셨던 대답은 이를 위해서 Istio와 같은 서비스메시 도입을 고려하고 있지만, 아직 완전히 성숙된 기술이 아니고 서비스 메시를 도입함으로써 관리해야할 레이어가 증가하기 때문에 아직 고려 중에 있다는 말씀이었습니다.

책에서도 동일하게 서비스 메시는 관리가 복잡하고 환경이 불안정해질 수 있는 프로세스이기 때문에 익숙하지 않다면상업적 지원을 고려해야 한다는 점을 언급하고 있으며 도입 전 사이드 이펙트에 대한 충분한 고려가 필요하다는 점을 잊지 말아야 합니다.