Pod는 자신의 네트워크 namespace를 가지고 같은 Pod내 여러 컨테이너는 localhost로 서로 통신이 가능
이 모델 내에서는 Pod들은 NAT 없이 직접 통신이 가능
k8s Service
Pod는 생성, 삭제, 수정 등으로 IP가 변경이 될 수 있다는 문제가 있어 이를 해결하기 위해 동적인 Pod IP를 대신할 정적인 접근점이 필요해 Service가 생김
Service는 여러 Pod를 백엔드 집합으로 묶어 그 Pod들이 변경이 되어도 접근이 가능한 정적인 IP 주소나 hostname 을 제공
내부적은로 k8s는 서비스 + Pod 간의 매핑정보를 가진 EndpointSlice 객체를 사용해 현재 동작 중인 백엔드를 관리
Service 프록시(kube-proxy)나 네트워크 구현체는 Service를 바탕으로 트래픽을 Pod에 라우팅
Service 타입의 종류
Cluster IP(기본)
클러스터 내부에서만 접근 가능한 가상 IP를 제공하여 내부 서비스 간 통신에 쓰임
NodePort
각 노드의 IP + 고정 포트를 통해 클러스터 외부에서 접근하게 함
테스트 및 디버깅용으로 사용
LoadBalancer
클라우드 환경에서 외부 로드밸런서를 자동으로 프로비저닝하여 외부에서 클러스터 내부 서비스로 접근하게 함
외부 트래픽과의 연결에 사용
ExternalName
Service 명을 외부 DNS 이름으로 매핑하는 방식
단순한 이름 매핑 방식
k8s Ingress/Gateway/외부접근
HTTP/HTTPS 로 여러 경로나 호스트 기반 라우팅, TLS 종료 등이 필요한 경우 Ingresss나 Gateway API 같은 상위의 개념을 함께 사용
Ingress/Gateway + Service 조합을 통하여 여러 Service에 대한 단일 진입점 같은 구성을 만듦
Ingress 를 사용하려면 클러스터에 Ingress 컨트롤러가 별도로 배포되어야 한다.
k8s 네트워크 정책(NetworkPolicy)
Pod 간이나 Pod 와 외부 간 트래픽을 제한하려 할 때 사용
네트워크 플러그인(CNI)가 NetworkPolicy를 지원해야 함
서비스, 로드밸런싱, 네트워킹 - Service
Service는 여러 Pod를 Endpoint으로 묶어 그 Pod들이 변경이 되어도 접근이 가능한 정적인 IP 주소나 hostname 을 제공
Service 작동 방식
Service 객체는 Endpoint + Access Policy 를 정의하는데 이 때 Label Selector 를 통해 어떤 Pod가 이 Service의 백엔드인지 지정
k8s의 Control Plane 은 이 Selector에 맞는 Pod를 감시하고 변화 시 자동으로 Service의 Endpoint 집합을 갱신
사용자가 Service의 고정 IP + 포트로 요청 시, Service 가 실제 Pod 주소로 이 요청을 보내도록 한다.
Service 타입
Cluster IP(기본)
클러스터 내부에서만 접근 가능한 가상 IP를 제공하여 내부 서비스 간 통신에 쓰임
NodePort
각 노드의 IP + 고정 포트를 통해 클러스터 외부에서 접근하게 함
테스트 및 디버깅용으로 사용
LoadBalancer
클라우드 환경에서 외부 로드밸런서를 자동으로 프로비저닝하여 외부에서 클러스터 내부 서비스로 접근하게 함
외부 트래픽과의 연결에 사용
ExternalName
Service 명을 외부 DNS 이름으로 매핑하는 방식
단순한 이름 매핑 방식
클러스터 내부에서 Service를 찾는법
Pod는 DNS 나 환경변수를 통해 Service를 찾음
EndpointSlice
Service가 관리하는 백엔드 엔드포인트(Pod 등)를 추적하고 구성하는 방식
기존의 Endpoints API 를 대체할 예정
여러 Pod가 같은 Service의 백엔드가 될 떄 그 Pod들의 IP/포트 정보를 EndpointSlice가 기록/관리
Service에 Selector가 지정이 되어있다면 Control Plane이 자동으로 적절한 EndpointSlice들을 관리
EndpointSlice 구조
addressType
IP(v4 + v6)
Service가 dual-stack이면 v4,v6 용 EndpointSlice 가 만들어질 수 있다.
ports
이 EndpointSlice가 커버하는 포트 집합
endpoints
실제 백엔드 Endpoint들의 목록
각 Endpoint가 가지는 정보
addresses
conditions
terminating
(+선택) nodeName, zone
토폴로지 정보
토폴로지 기반 라우팅 및 지리적 분산 최적화에 활용
Endpoints 대비 장점
여러 backend Endpoint 들을 작은 그룹(slice)로 나눠 관리하여 기존의 거대한 리스트 대신, 작은 청크들로 관리
백엔드 변경 시 전체 변경이 아닌 일부 slice만 변경이 이뤄지게 하여 업데이트 오버헤드 감소하여 클러스터의 부담이 줄음
IP(v4 + v6) 듀얼스택, 토폴로지 정보, 상태정보 등을 포함하기 때문에 네트워크 구성이 다양해짐
EndpointSlice 괸리와 동작 방식
보통 클러스터 내부 EndpointSlice Controller가 자동으로 생성/관리
Service와 Pod 관계가 바뀌면 Control Plane은
기존 Slice에서 안쓰는 Endpoint 삭제 및 변경된 Endpoint 변경
추가의 경우 Endpoint 공간을 확인하고 여유가 없으면 새 Slice를 추가
한 Service에 속한 Endpoint가 여러 Slice에 분산될 수 있거나 동일한 Endpoint가 여러 Slice에 저장될 수가 있는데 이 떄 EndpointSlice를 소비하는 구현체(예 : kube-proxy)가 모든 Slice를 모아서 중복을 제거 후 실제 Endpoint 리스트로 사용
Service 및 Pod용 DNS
k8s 에선 Pod, Service가 자주 변경됨 => 주소가 자주 변경 =>>직접적인 IP 주소보단 hostname이 관리가 용이 =>>>DNS가 필요로 해짐(이름만 안다면 IP 몰라도 됨)
k8s 클러스터 내부에는 DNS 서비스 (Pod + Service) 가 있고 각 Pod는 DNS 사용하도록 자동 설정 됨
Service, Pod는 DNS 이름이 할당이 되기 때문에 이름으로 참조할 수가 있고 Pod IP가 바뀌어도 영향이 없음
Service의 DNS 레코드(A 또는 AAAA)
서비스명.네임스페이스명.svc.클러스터도메인명.예시이름
해당 Service 내 Pod들의 IP 집합으로 해석
Pod의 DNS 레코드 (A 또는 AAAA)
Pod의 IP.네임스페이스명.pod.클러스터도메인명
Pod가 어떤 Service의 백엔드라면
Pod의 IP.서비스명.네임스페이스명.svc.클러스터도메인명
DNS 기반 Service 디스커버리의 장점
IP를 직접 참조하지 않고 Service 이름으로 접근이 가능
Service, Pod가 변경되어도 DNS 이름은 일정
주의
DNS 서버가 있어야 함
서비스, 로드밸런싱, 네트워킹 - Ingress, Gatway API
Ingress
외부에서 내부로 들어오는 HTTP/HTTPS 트래픽을 클러스터 내 한개 이상의 Service로 라우팅하기 위한 API 오브젝트 => 여러 서비스를 노출 시, 각각에 로드밸런서를 만드는게 아닌, 하나의 진입점만 생성하여 요청을 받아 내부 서비스에게 요청하도록 함
name-base virtual hosting, path-base routing, SSL/TLS 종료 같은 기능을 설정가능하게 함
클러스터 내에 Ingress Controller가 설치되어야 함
HTTP/HTTPS 방식 전용
Ingress 작동 방법
먼저 클러스터 내 Ingress Controller가 설치되어 있어야 함
Ingress Controller 는 Ingress 리소스를 보고 트래픽 라우팅 설정을 함
Ingress 리소스에 정의된 정보
어떤 hostname 또는 IP로 받을지
경로 및 매칭 방식
요청이 매칭되었을 때 어떤 내부 Service와 포트로 트래픽을 보낼지
+(선택) TLS/SSL 설정 : 인증서(Secret) 지정하여 HTTPS 를 지원하고 통신을 암호화 한다.
만약 설정된 규칙 외의 요청이 들어왔을 때 만약 defaultBackend가 지정되어 있을 시, 그 Service로 보내지고 지정이 되지 않았다면 Ingress Controller의 구현에 따라 처리
Ingress 가 사용되는 주요 상황
MSA 시스템에서 각기 다른 경로나 도메인으로 외부에 노출이 되어야 할 떄 Endpoin + Ingress 규칙으로 관리
HTTPS 지원 필요 시, TLS 종료를 Ingress 레벨에서 처리하고 내부 Service는 평문 HTTP로 유지
네트워크 구조를 단순화 할 때
클러스터에 여러 Service 가 있고 외부 노출 방식이 자주 바뀔 때
Ingress Contoller
기능
클러스터 외부에서 들어오는 HTTP/HTTPS 요청을 받음
Ingress 리소스에 정의된 규칙대로 요청을 내부 Service로 Proxy/Routing 함
TTL 종료나 가상 호스팅, 로드밸런싱 지원
Ingress Controller 구현체 예시
AWS, GCE, NGINX Ingress Controller
Traefik, HAProxy, Contour, Apache APISIX, Cilium Ingress Controller 등
Ingress Controller 구현체마다 사용방법이 조금씩 달라저 주의 해야함
Gateway API
외부나 내부에서 들어오는 네트워크 트래픽을 클러스터 내부의 Service로 유연하게 라우팅하기 위한 k8s의 차세대 네트워킹 API 집합
Ingress API의 문제점을 보완하고 더 나은 방식을 제공하는 방향으로 설계
이것 또한 Controller 를 클러스터에 설치해야 함
설계 철학
역할 지향(role-oriented)
인프라 제공자, 클러스터 운영자, 애플리케이션 개발자 등 역할 별로 책임과 권한 분리
표준화(Portable)
CRD 기반으로 구현되며 여러 구현체(Controller)에서 공통 스펙을 지원하도록 설계
표현력(Expressive)
HTTP 호스트/경로 매칭, 헤더 기반 매칭, 트래픽 가중치 분배, 미러링, TCP/\UDP 등 프로토콜 지원
Ingress 보다 나은 기능을 제공
확장 가능(Extensible)
기본 API 외에 커스텀 리소스, 확장 설정이 가능하도록 설계
Gateway API 의 주요 자원 구조
GatewayClass
게이트웨이의 클래스/구현 방식을 정의
어떤 Controller 가 이 Gateway를 관리할지 지정
Gateway
실제 트래픽 처리 인프라의 인스턴스로 트래픽을 받을지 정의
Route 리소스
Gateway를 통해 들어온 트래픽을 내부의 Service 및 EndpointSlice로 어떻게 매핑할지 규칙을 정의
Gateway API 의 장점
HTTP 뿐만 아니라 TCP/UDP, gRPC등 다양한 프로토콜을 지원
헤더 기반 매칭, 트래픽 가중치 분배, 요청 라우팅 필터링, 미러링 등 기능을 표준 API로 지원
Ingress 에서 복잡하게 설정하던걸 쉽게 제공
역할 분리 덕분에 인프라 관리자/클러스터 운영자/애플리케이션 개발자가 서로 다른 리소스를 관리하여 책임 분담이 명확화
다양한 구현체(==Ingress Controller)에서 공통 스펙을 지원 -> 공통 템플릿을 만들어서 이것으로 구현하게 유도
서비스, 로드밸런싱, 네트워킹 - NetworkPolicy
k8s 클러스터 내에서 Pod 간이나 Pod와 외부 네트워크 간의 트래픽을 제어하는 네트워크 격리, 허용 규칙(firewall-like policy)를 정의하는 리소스
기본적으로 모든 Pod 간 통신이 허용이지만 network Policy 정의 시, Ingress 및 Egress 라는 특정 방향에 대한 통신만 허용하도록 격리가 가능
NetworkPolicy 기능을 사용하려면 네트워크 플러그인(CNI)이 NetworkPolicy를 지원해야 함
동작 방식
podSelector
어느 Pod에 이 정책을 적용할지 지정하는 Selector
만약 비어있는 Selector 설정 지 모든 파드를 지정
policyTypes
Ingress, Egress 를 지정할 수 있음
명시하지 않을 시, Ingress 자동 지정
ingress
외부에서 Pod로 들어오는 트래픽을 제어
egress
Pod에서 외부 및 다른 Pod로 나가는 트래픽을 제어
각 규칙은 출처/대상(from/to) + 포트/프로토콜 제한(ports, protocol) 으로 구성
ingress
egress
NetworkPolicy의 장점
Pod 와 Pod, Pod와 외부 간 통신을 엄격히 제어하여 불필요한 접근을 차단
클러스터 내에서 트래픽을 격리하고 권한을 분리할 수 있음
필요한 통신만 가능하도록 설정하여 나머지는 차단시킴
세부적으로 설정이 가능해 세밀한 접근 허용/차단할 수 있음
주의
Layer 3게층, 4계층 수준의 제어만 제공하기 때문에 애플리케이션 레벨(Layer 7) 제어는 하지 않음
네트워크 플러그인(CNI)이 NetworkPolicy를 지원해야 함
hostNetwork : true 로 설정된 경우 NetworkPolicy가 동작하지 않을 수 있음