3. 네트워크를 통해 서비스에 파드 연결하기

• 통신 트래픽은 클러스터 외부에서 파드로 전달되는 것과

• 파드에서 클러스터 외부로 전달되는 것 모두를 포함

쿠버네티스 내부의 네트워크 트래픽 라우팅

• 서비스가 생성되면 서비스의 IP 주소가 클러스터 내 DNS 서버에 등록됨. 이 IP 주소는 정적 주소로 서비스가 삭제될 때까지 변경되지 않음

• 디플로이먼트가 그랬듯이, 서비스 역시 레이블 셀렉터를 이용한 방식으로 파드와 느슨한 연결을 가짐.

• 서비스는 복수의 파드가 공유할 수 있는 가상 주소. sleep-1 파드는 서비스를 갖지 않기 때문에 도메인 네임으로 접근할 수 없다.

• 이런 유형의 서비스는 파드와 파드가 가진 네트워크 주소를 추상화한 것임
• 서비스는 자신만의 IP 주소를 가지고, 이 주소 역시 서비스가 삭제될 때까지 바뀌지 않음. 컨슈머 컴포넌트가 이 주소로 요청을 보내면 쿠버네티스가 서비스와 연결된 파드의 실제 IP 주소로 요청을 전달해줌

파드와 파드 간 통신

• 클러스터 IP 는 클러스터 전체에서 통용되는 IP 주소를 생성하는데, 이 IP 주소는 파드가 어느 노드에 있더라도 접근이 가능하다

• 하지만 이 IP 주소는 클러스터 내에서만 유효하기에 파드와 파드 간 통신에서만 쓰인다. 내부에서는 접근이 가능하되 외부의 접근은 차단해야 하는 분산 시스템의 컴포넌트에 적합함

• 서비스의 label selector와 pod의 label이 매칭되면 쿠버네티스는 자동으로 endpoint 오브젝트를 별도로 생성합니다

외부 트래픽을 파드로 전달하기

Service, LoadBalancer

• 로드밸런서 서비스는 클러스터로 트래픽을 전달해 주는 외부 로드밸런서와 함께 동작하며, 레이블 셀렉터와 일치하는 파드로 트래픽을 전달함
• 로드밸런서를 동적으로 생성하는 기능을 제공하는 환경에서만(AWS, GCP 등) 사용할 수 있음

• 로드밸런서 서비스의 커버 범위는 클러스터 전체. 따라서 어느 노드에 있는 파드라도 트래픽을 전달받을 수 있음
• 대상 파드가 요청받은 노드에 있지 않더라도 쿠버네티스가 올바른 노드까지 이 트래픽을 전달함

• 위 서비스는 8080번 포트를 주시하다가 해당 포트로 들어오는 트래픽을 app:numbers-web 라벨을 가진 파드의 80번 포트로 전달함

• 만약에 그러한 조건을 만족하는 파드가 여러 노드에 걸쳐 있더라도 어디로 배분할지는 쿠버네티스가 알아서 할당해줌

• 로드밸런서는 외부 IP 주소를 주시하다가 해당 주소로 들어오는 트래픽을 클러스터에 전달함

• 이 주소는 클러스터에서 제공되는 주소로, 위 예시에서는 도커 데스크톱을 이용하였어서, localhost가 제공됨

• 로드밸런서 서비스에는 클러스터 IP 가 함께 부여되고, 클러스터 안에 있는 다른 파드는 서비스 이름(numbers-web)으로 서비스에 접근 가능함
• 예: http://numbers-web:8080 으로 numbers-web 파드의 80 포트로 접근이 가능함

분산 환경에 따라 구현 방식(도커 데스크톱, K3s, AKS, EKS )에 발생하는 차이

• 도커 데스크톱의 쿠버네티스는 로컬 환경으로, 이 클러스터는 단일 컴퓨터에서 동작하며, 로컬 컴퓨터의 네트워크 스택과 통합되어 로드밸런서 서비스가 로컬 호스트 주소를 사용할 수 있다. 모든 로드밸런서 서비스가 localhost로 외부에 공개되고, 따라서 여러 개의 로드밸런서 서비스를 사용하려면 이들의 포트를 각각 다르게 설정해야 함

• K3s 환경의 쿠버네티스에서는 별도의 라우팅 테이블을 설정하는 방식으로 로드밸런서 서비스를 구현함
• 각각의 로드밸런서 서비스는 호스트 컴퓨터(여기서는 가상 머신)의 IP 주소로 외부에 공개된다. 따라서 localhost 또는 IP 주소(로컬 네트워크에서 접근도 가능)로 로드밸런서 서비스에 접근할 수 있다.
• 역시 도커 데스크톱과 마찬가지로 여러 개의 로드밸런서 서비스를 사용하려면 이들의 포트를 각각 다르게 설정해야 한다.

• AKS나 EKS 같은 클라우드 환경의 쿠버네티스는 고가용성을 확보한 다중 노드 클러스터임. 이들 클러스터에서 로드밸런서 서비스를 배포하면 클라우드에 실제 로드밸런서가 만들어진다.
• 이 로드밸런서가 외부에서 들어오는 트래픽을 노드로 전달하고, 그다음 쿠버네티스가 이를 다시 파드로 전달한다.
• 따라서 로드밸런서 서비스의 IP 주소도 각기 다르다. 또한 이들 IP 주소는 공인 IP 주소이며 인터넷에서 접근할 수 있다.

Service, NodePort

• 노드포트 서비스는 외부 로드밸런서가 필요 없고, 클러스터를 구성하는 모든 노드가 이 서비스에 지정된 포트를 주시하며 들어온 트래픽을 대상 파드의 대상 포트로 전달함
• 외부 로드밸런서가 없으므로 트래픽이 곧바로 클러스터 노드로 인입됨

• 트래픽이 클러스터에 인입된 후에는 로드밸런서 서비스와 비슷하게 동작. 어느 노드가 요청을 받더라도 대상 파드가 있는 노드 3으로 트래픽이 전달됨

• 노드포트 서비스는 서비스에서 설정된 포트가 모든 노드에서 개방되어 있어야 하기 때문에 로드밸런서 서비스만큼 유연하지 x

• 또한 다중 노드 클러스터에서 로드밸런싱 효과를 얻을 수 없음

쿠버네티스 클러스터 외부로 트래픽 전달하기 (ExternalName)

• 익스터널네임 서비스는 어떤 도메인 네임에 대한 별명이라고 생각하면 됨

• 애플리케이션 파드에서 로컬 네임을 사용하고, 쿠버네티스 DNS 서버에 이 로컬 네임을 조회하면 외부 도메인으로 해소해 주는 방식

• 익스터널 네임 서비스는 도메인 네임의 별명을 만듬
• 파드가 로컬 클러스터 네임 db-service를 사용하면, 쿠버네티스 DNS 서버에서 이 도메인 네임을 외부 도메인 app.mydatabase.io 로 resolve 해줌
• 파드는 사실적으로는 클러스터 외부의 컴포넌트와 통신을 하지만, 이를 알지 못함. 파드에서 사용하는 도메인 네임이 로컬 도메인 네임이기 때문에

사용 예시

• 익스터널네임 서비스는 애플리케이션 설정에 포함하기 어려운 환경 간 차이를 반영할 때 유용함
• 데이터베이스 서버 대신 하드코딩된 문자열을 사용한다거나, 개발 환경에서는 로컬 도메인 네임을 파드에서 동작하는 테스트용 데이터베이스 서버에 연결하고 운영환경에서는 실제 도메인에 연결된 운영 데이터베이스 서버에 연결하도록 할 수 있음

• 쿠버네티스는 DNS의 표준 기능 중 하나인 캐노니컬 네임(Canonical NAME, CNAME)을 사용하여 익스터널네임 서비스를 구현함

• 웹 애플리케이션 파드가 도메인 네임 numbers-api를 조회하면 쿠버네티스 DNS 서버가 이 CNAME(raw.githubusercontent.com)을 반환함

헤드리스 서비스

쿠버네티스 서비스의 해소 과정

• 파드 속 컨테이너가 요청한 도메인 네임 조회는 쿠버네티스 DNS 서버가 응답한다
• 조회 대상이 서비스 리소스라면, DNS 서버는 클러스터 내 IP 주소 또는 외부 도메인 네임을 반환한다

• 파드에서 나온 모든 통신은 쿠버네티스의 또 다른 구성요소인 네트워크 프록시가 라우팅을 담당함
• 이 프록시는 각각의 노드에서 동작하며 모든 서비스의 엔드포인트에 대한 최신 정보를 유지하고, 운영체제가 제공하는 네트워크 패킷 필터(리눅스의 경우 IVPS 또는 iptables)를 사용하여 트래픽을 라우팅함
• 클러스터 IP는 네트워크 상에 실재하지 않는 가상 IP 주소고, 파드는 각 노드마다 동작하는 네트워크 프록시 를 경유하여 네트워크에 접근한다. 그리고 이 프록시는 패킷 필터링을 적용하여 가상 IP 주소를 실제 엔드포인트로 연결함

Controller

• 서비스에도 컨트롤러가 있어 파드가 변경될 때마다 엔드포인트의 목록을 최신으로 업데이트한다.
• Controller 정의 : 클러스터의 상태를 관찰한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프
• 쿠버네티스 클러스터는 항상 2가지의 상태(desired state, current state)를 가지며 쿠버네티스에서 기본으로 제공되는 컨트롤러는 ControlPlane 에서 동작한다.
• 컨트롤러는 크게 쿠버네티스에서 자체적으로 제공되는 컨트롤러와 커스텀 컨트롤러로 구분됨
• 내장 컨트롤러는 control plane에서 작동한다고 함
• Controller에도 여러 종류가 있음 [ Kubernetes docs ] control plane components
• ReplicationController
• ReplicaSet, Deployment
• DaemonSet
• Stateful Sets
• Job, CronJob
• EndpointSlice controller : populates EndpointSlice objects (to provide a link between Services and Pods)
• …

네임스페이스

• 모든 쿠버네티스 리소스는 네임스페이스 안에 존재함

• 네임스페이스는 쉽게 말해 다른 리소스를 하나로 묶기 위한 리소스

• 따라서 쿠버네티스 클러스터를 논리적 파티션으로 나누는 역할을 함

• 클러스터는 여러 개의 네임스페이스로 나뉠 수 있다. default 네임스페이스가 항상 존재하고, 여기에 다른 네임스페이스를 추가하여 여러 리소스를 하나로 묶을 수 있음

• 네임스페이스 안에서는 도메인 네임을 이용하여 서비스에 접근함. numbers-web 파드가 numbers-api 라는 이름으로 api 서비스에 접근할 수 있었던 것도 이때문임

• 네임스페이스를 포함하는 완전한 도메인 네임으로도 서비스에 접근할 수 있음. 예를 들어 다른 네임스페이스에 속하는 파드는 numbers-api.default.svc.cluster.local 이라는 도메인 네임으로 API 서비스에 접근할 수 있음
• 도메인 네임 : <service_name>.<namespace>.<subdomain>.<domain name>
• db-service.dev.svc.cluster.local

• kube-system 네임스페이스에 쿠버네티스의 핵심 기능인 DNS 서버가 쿠버네티스 애플리케이션 형태로 동작 중