모든 파드는 고유한 IP 주소를 갖는다.
이는 즉 파드간 연결을 명시적으로 만들 필요가 없으며
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다.
이로 인해 포트 할당, 네이밍, 서비스 디스커버리,
로드 밸런싱,
애플리케이션 구성, 마이그레이션 관점에서 파드를
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.
쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)
노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든
파드와 통신할 수 있다
참고: 파드를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는
다음의 요구사항도 존재한다.
한 노드의 호스트 네트워크에 있는 파드는
NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
이 모델은 전반적으로 덜 복잡할 뿐만 아니라,
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다.
작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다.
이는 동일한 기본 모델이다.
쿠버네티스 IP 주소는 파드 범주에 존재하며,
파드 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다.
이는 곧 파드 내의 컨테이너들이 각자의 포트에 localhost로 접근할 수 있음을 의미한다.
또한 파드 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데,
이는 VM 내 프로세스 간에도 마찬가지이다.
이러한 모델은 "파드 별 IP" 모델로 불린다.
이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.
노드 자체의 포트를 파드로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림),
이는 매우 비주류적인(niche) 동작이다.
포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다.
파드 자체는 호스트 포트 존재 유무를 인지할 수 없다.
쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다.
쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고,
그것들 간에 로드-밸런스를 수행할 수 있다.
동기
쿠버네티스 파드는 클러스터 상태와
일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
만약 앱을 실행하기 위해 디플로이먼트를 사용한다면,
동적으로 파드를 생성하고 제거할 수 있다.
각 파드는 고유한 IP 주소를 갖지만, 디플로이먼트에서는
한 시점에 실행되는 파드 집합이
잠시 후 실행되는 해당 파드 집합과 다를 수 있다.
이는 다음과 같은 문제를 야기한다. ("백엔드"라 불리는) 일부 파드 집합이
클러스터의 ("프론트엔드"라 불리는) 다른 파드에 기능을 제공하는 경우,
프론트엔드가 워크로드의 백엔드를 사용하기 위해,
프론트엔드가 어떻게 연결할 IP 주소를 찾아서 추적할 수 있는가?
서비스 로 들어가보자.
서비스 리소스
쿠버네티스에서 서비스는 파드의 논리적 집합과 그것들에 접근할 수 있는
정책을 정의하는 추상적 개념이다. (때로는 이 패턴을
마이크로-서비스라고 한다.) 서비스가 대상으로 하는 파드 집합은 일반적으로
셀렉터가 결정한다.
서비스 엔드포인트를 정의하는 다른 방법에 대한 자세한 내용은
셀렉터가 없는 서비스를 참고한다.
예를 들어, 3개의 레플리카로 실행되는 스테이트리스 이미지-처리 백엔드를
생각해보자. 이러한 레플리카는 대체 가능하다. 즉, 프론트엔드는 그것들이 사용하는 백엔드를
신경쓰지 않는다. 백엔드 세트를 구성하는 실제 파드는 변경될 수 있지만,
프론트엔드 클라이언트는 이를 인식할 필요가 없으며, 백엔드 세트 자체를 추적해야 할 필요도
없다.
서비스 추상화는 이러한 디커플링을 가능하게 한다.
클라우드-네이티브 서비스 디스커버리
애플리케이션에서 서비스 디스커버리를 위해 쿠버네티스 API를 사용할 수 있는 경우,
서비스 내 파드 세트가 변경될 때마다 업데이트되는 엔드포인트를 API 서버에
질의할 수 있다.
네이티브 애플리케이션이 아닌 (non-native applications) 경우, 쿠버네티스는 애플리케이션과 백엔드 파드 사이에 네트워크 포트 또는 로드
밸런서를 배치할 수 있는 방법을 제공한다.
서비스 정의
쿠버네티스의 서비스는 파드와 비슷한 REST 오브젝트이다. 모든 REST 오브젝트와
마찬가지로, 서비스 정의를 API 서버에 POST하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
RFC 1035 레이블 이름이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
app=MyApp 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
이 명세는 "my-service"라는 새로운 서비스 오브젝트를 생성하고,
app=MyApp 레이블을 가진 파드의 TCP 9376 포트를 대상으로 한다.
쿠버네티스는 이 서비스에 서비스 프록시가 사용하는 IP 주소 ("cluster IP"라고도 함)
를 할당한다.
(이하 가상 IP와 서비스 프록시 참고)
서비스 셀렉터의 컨트롤러는 셀렉터와 일치하는 파드를 지속적으로 검색하고,
"my-service"라는 엔드포인트 오브젝트에 대한
모든 업데이트를 POST한다.
참고: 서비스는 모든 수신 port를 targetPort에 매핑할 수 있다. 기본적으로 그리고
편의상, targetPort는 port
필드와 같은 값으로 설정된다.
파드의 포트 정의에는 이름이 있고, 서비스의 targetPort 속성에서 이 이름을
참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에
혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
엔드포인트 IP는 루프백(loopback) (IPv4의 경우 127.0.0.0/8, IPv6의 경우 ::1/128), 또는
링크-로컬 (IPv4의 경우 169.254.0.0/16와 224.0.0.0/24, IPv6의 경우 fe80::/64)이 되어서는 안된다.
엔드포인트 IP 주소는 다른 쿠버네티스 서비스의 클러스터 IP일 수 없는데,
kube-proxy는 가상 IP를
목적지(destination)로 지원하지 않기 때문이다.
셀렉터가 없는 서비스에 접근하면 셀렉터가 있는 것처럼 동일하게 작동한다.
위의 예에서, 트래픽은 YAML에 정의된 단일 엔드 포인트로
라우팅된다. 192.0.2.42:9376 (TCP)
참고: 쿠버네티스 API 서버는 파드에 매핑되지 않은 엔드포인트를 프록시하는 것을 허용하지 않는다.
셀렉터가 없는 서비스에 대해서 kubectl proxy <service-name>과 같은 행위는
이런 제약으로 인해 실패할 것이다. 이는 사용자가 쿠버네티스 API 서버를
프록시로 사용하여 허가받지 않은 엔드포인트에 접근하는 것을 막아준다.
ExternalName 서비스는 셀렉터가 없고
DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은
이 문서 뒷부분의 ExternalName 섹션을 참조한다.
초과 용량 엔드포인트
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
클러스터는 해당 엔드포인트에 endpoints.kubernetes.io/over-capacity: truncated 어노테이션을 추가한다.
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
엔드포인트슬라이스
FEATURE STATE:Kubernetes v1.21 [stable]
엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는
API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를
사용하면 여러 리소스에 네트워크 엔드포인트를 분산시킬 수 있다. 기본적으로,
엔드포인트슬라이스는 100개의 엔드포인트에 도달하면 "가득찬 것"로 간주되며,
추가 엔드포인트를 저장하기 위해서는 추가 엔드포인트슬라이스가
생성된다.
엔드포인트슬라이스는 엔드포인트슬라이스에서
자세하게 설명된 추가적인 속성 및 기능을 제공한다.
애플리케이션 프로토콜
FEATURE STATE:Kubernetes v1.20 [stable]
appProtocol 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스
오브젝트에 의해 미러링된다.
이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은
IANA 표준 서비스 이름 또는
mycompany.com/my-custom-protocol과 같은 도메인 접두사 이름 중 하나여야 한다.
가상 IP와 서비스 프록시
쿠버네티스 클러스터의 모든 노드는 kube-proxy를 실행한다. kube-proxy는
ExternalName 이외의 유형의 서비스에 대한
가상 IP 형식을 구현한다.
라운드-로빈 DNS를 사용하지 않는 이유
항상 발생하는 질문은 왜 쿠버네티스가 인바운드 트래픽을 백엔드로 전달하기 위해 프록시에
의존하는가 하는 점이다. 다른 접근법이
있는가? 예를 들어, 여러 A 값 (또는 IPv6의 경우 AAAA)을 가진
DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
취할 수 있는가?
서비스에 프록시를 사용하는 데는 몇 가지 이유가 있다.
레코드 TTL을 고려하지 않고, 만료된 이름 검색 결과를
캐싱하는 DNS 구현에 대한 오래된 역사가 있다.
일부 앱은 DNS 검색을 한 번만 수행하고 결과를 무기한으로 캐시한다.
앱과 라이브러리가 적절히 재-확인을 했다고 하더라도, DNS 레코드의 TTL이
낮거나 0이면 DNS에 부하가 높아 관리하기가
어려워 질 수 있다.
본 페이지의 뒷 부분에서 다양한 kube-proxy 구현의 동작에 대해 읽을 수 있다.
우선 알아두어야 할 것은, kube-proxy를 구동할 때, 커널 수준의 규칙이
수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고,
이는 때로는 리부트 전까지 정리되지 않을 수도 있다.
그래서, kube-proxy는 컴퓨터에서 저수준의, 특권을 가진(privileged) 네트워킹
프록시 서비스가 구동됨으로써 발생하는 결과를 이해하고 있는 관리자에 의해서만 구동되어야 한다.
비록 kube-proxy 실행 파일이 cleanup 기능을 지원하기는 하지만, 이 기능은 공식적인 기능이
아니기 때문에 구현된 그대로만 사용할 수 있다.
구성
kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. 마찬가지로, netsh을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
유저 스페이스(User space) 프록시 모드
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스 및 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스는 로컬 노드에서
포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든
연결은 (엔드포인트를 통해 보고된 대로) 서비스의 백엔드 파드 중 하나로 프록시된다.
kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의
SessionAffinity 설정을 고려한다.
마지막으로, 유저-스페이스 프록시는 서비스의
clusterIP (가상)와 port 에 대한 트래픽을 캡처하는 iptables 규칙을 설치한다. 이 규칙은
트래픽을 백엔드 파드를 프록시하는 프록시 포트로 리다이렉션한다.
이 모드에서는, kube-proxy는 쿠버네티스 컨트롤 플레인의 서비스, 엔드포인트 오브젝트의
추가와 제거를 감시한다. 각 서비스에 대해, 서비스의
clusterIP 및 port에 대한 트래픽을 캡처하고 해당 트래픽을 서비스의
백엔드 세트 중 하나로 리다이렉트(redirect)하는
iptables 규칙을 설치한다. 각 엔드포인트 오브젝트에 대해,
백엔드 파드를 선택하는 iptables 규칙을 설치한다.
기본적으로, iptables 모드의 kube-proxy는 임의의 백엔드를 선택한다.
트래픽을 처리하기 위해 iptables를 사용하면 시스템 오버헤드가 줄어드는데, 유저스페이스와
커널 스페이스 사이를 전환할 필요없이 리눅스 넷필터(netfilter)가 트래픽을 처리하기
때문이다. 이 접근 방식은 더 신뢰할 수 있기도 하다.
kube-proxy가 iptables 모드에서 실행 중이고 선택된 첫 번째 파드가
응답하지 않으면, 연결이 실패한다. 이는 userspace 모드와
다르다. 해당 시나리오에서는, kube-proxy는 첫 번째
파드에 대한 연결이 실패했음을 감지하고 다른 백엔드 파드로 자동으로 재시도한다.
파드 준비성 프로브(readiness probe)를 사용하여
백엔드 파드가 제대로 작동하는지 확인할 수 있으므로, iptables 모드의 kube-proxy는
정상으로 테스트된 백엔드만 볼 수 있다. 이렇게 하면 트래픽이 kube-proxy를 통해
실패한 것으로 알려진 파드로 전송되는 것을 막을 수 있다.
IPVS 프록시 모드
FEATURE STATE:Kubernetes v1.11 [stable]
ipvs 모드에서는, kube-proxy는 쿠버네티스 서비스와 엔드포인트를 감시하고,
netlink 인터페이스를 호출하여 그에 따라 IPVS 규칙을 생성하고
IPVS 규칙을 쿠버네티스 서비스와 엔드포인트와 주기적으로 동기화한다.
이 제어 루프는 IPVS 상태가 원하는 상태와 일치하도록
보장한다.
서비스에 접근하면, IPVS는 트래픽을 백엔드 파드 중 하나로 보낸다.
IPVS 프록시 모드는 iptables 모드와 유사한 넷필터 후크 기능을
기반으로 하지만, 해시 테이블을 기본 데이터 구조로 사용하고
커널 스페이스에서 동작한다.
이는 IPVS 모드의 kube-proxy는 iptables 모드의 kube-proxy보다
지연 시간이 짧은 트래픽을 리다이렉션하고, 프록시 규칙을 동기화할 때 성능이
훨씬 향상됨을 의미한다. 다른 프록시 모드와 비교했을 때, IPVS 모드는
높은 네트워크 트래픽 처리량도 지원한다.
IPVS는 트래픽을 백엔드 파드로 밸런싱하기 위한 추가 옵션을 제공한다.
다음과 같다.
rr: 라운드-로빈
lc: 최소 연결 (가장 적은 수의 열려있는 연결)
dh: 목적지 해싱
sh: 소스 해싱
sed: 최단 예상 지연 (shortest expected delay)
nq: 큐 미사용 (never queue)
참고:
IPVS 모드에서 kube-proxy를 실행하려면, kube-proxy를 시작하기 전에 노드에서 IPVS를
사용 가능하도록 해야 한다.
kube-proxy가 IPVS 프록시 모드에서 시작될 때, IPVS 커널 모듈을
사용할 수 있는지 확인한다. IPVS 커널 모듈이 감지되지 않으면, kube-proxy는
iptables 프록시 모드에서 다시 실행된다.
이 프록시 모델에서 클라이언트가 쿠버네티스 또는 서비스 또는 파드에
대해 알지 못하는 경우 서비스의 IP:포트로 향하는 트래픽은
적절한 백엔드로 프록시된다.
특정 클라이언트의 연결이 매번 동일한 파드로
전달되도록 하려면, service.spec.sessionAffinity를 "ClientIP"로 설정하여
클라이언트의 IP 주소를 기반으로 세션 어피니티(Affinity)를 선택할 수 있다.
(기본값은 "None")
service.spec.sessionAffinityConfig.clientIP.timeoutSeconds를 적절히 설정하여
최대 세션 고정 시간을 설정할 수도 있다.
(기본값은 10800으로, 3시간)
멀티-포트 서비스
일부 서비스의 경우, 둘 이상의 포트를 노출해야 한다.
쿠버네티스는 서비스 오브젝트에서 멀티 포트 정의를 구성할 수 있도록 지원한다.
서비스에 멀티 포트를 사용하는 경우, 모든 포트 이름을
명확하게 지정해야 한다.
예를 들면
쿠버네티스의 일반적인 이름과 마찬가지로, 포트 이름은
소문자 영숫자와 - 만 포함해야 한다. 포트 이름은
영숫자로 시작하고 끝나야 한다.
예를 들어, 123-abc 와 web 은 유효하지만, 123_abc 와 -web 은 유효하지 않다.
자신의 IP 주소 선택
서비스 생성 요청시 고유한 클러스터 IP 주소를 지정할 수
있다. 이를 위해, .spec.clusterIP 필드를 설정한다. 예를 들어,
재사용하려는 기존 DNS 항목이 있거나, 특정 IP 주소로 구성되어
재구성이 어려운 레거시 시스템인 경우이다.
선택한 IP 주소는 API 서버에 대해 구성된 service-cluster-ip-range
CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
트래픽 정책
외부 트래픽 정책
spec.externalTrafficPolicy 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
이 필드는 Cluster 또는 Local로 설정할 수 있다. 필드를 Cluster로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
Local로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 Local로 설정되어 있는데 노드-로컬
엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
참고:
FEATURE STATE:Kubernetes v1.22 [alpha]
kube-proxy에 대해 ProxyTerminatingEndpoints기능 게이트를
활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지,
그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
만약 로컬 엔드포인트가 존재하는데 모두가 종료 중이면, kube-proxy는 Local로 설정된 모든 외부 트래픽 정책을 무시한다.
대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안,
kube-proxy는 마치 외부 트래픽 정책이 Cluster로 설정되어 있는 것처럼
그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 NodePort 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가
헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만
파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
내부 트래픽 정책
FEATURE STATE:Kubernetes v1.22 [beta]
spec.internalTrafficPolicy 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
이 필드는 Cluster 또는 Local로 설정할 수 있다. 필드를 Cluster로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
Local로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 Local로 설정되어 있는데 노드-로컬
엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
서비스 디스커버리하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
변수와 DNS
환경 변수
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다.
{SVCNAME}_SERVICE_HOST 및 {SVCNAME}_SERVICE_PORT 환경 변수가 추가되는데, 이 때 서비스 이름은 대문자로, 하이픈(-)은 언더스코어(_)로 변환하여 사용한다. 또한 도커 엔진의 "레거시 컨테이너 연결" 기능과 호환되는 변수(makeLinkVariables 참조)도 지원한다.
예를 들어, TCP 포트 6379를 개방하고
클러스터 IP 주소 10.0.0.11이 할당된 서비스 redis-master는,
다음 환경 변수를 생성한다.
서비스에 접근이 필요한 파드가 있고, 환경 변수를
사용해 포트 및 클러스터 IP를 클라이언트 파드에 부여하는
경우, 클라이언트 파드가 생성되기 전에 서비스를 만들어야 한다.
그렇지 않으면, 해당 클라이언트 파드는 환경 변수를 생성할 수 없다.
DNS 만 사용하여 서비스의 클러스터 IP를 검색하는 경우, 이 순서
이슈에 대해 신경 쓸 필요가 없다.
DNS
애드-온을 사용하여 쿠버네티스
클러스터의 DNS 서비스를 설정할 수(대개는 필수적임) 있다.
CoreDNS와 같은, 클러스터-인식 DNS 서버는 새로운 서비스를 위해 쿠버네티스 API를 감시하고
각각에 대한 DNS 레코드 세트를 생성한다. 클러스터 전체에서 DNS가 활성화된 경우
모든 파드는 DNS 이름으로 서비스를 자동으로
확인할 수 있어야 한다.
예를 들면, 쿠버네티스 네임스페이스 my-ns에 my-service라는
서비스가 있는 경우, 컨트롤 플레인과 DNS 서비스가 함께 작동하여
my-service.my-ns에 대한 DNS 레코드를 만든다. my-ns 네임 스페이스의 파드들은
my-service(my-service.my-ns 역시 동작함)에 대한 이름 조회를
수행하여 서비스를 찾을 수 있어야 한다.
다른 네임스페이스의 파드들은 이름을 my-service.my-ns으로 사용해야 한다. 이 이름은
서비스에 할당된 클러스터 IP로 변환된다.
쿠버네티스는 또한 알려진 포트에 대한 DNS SRV (서비스) 레코드를 지원한다.
my-service.my-ns 서비스에 프로토콜이 TCP로 설정된 http라는 포트가 있는 경우,
IP 주소와 http에 대한 포트 번호를 검색하기 위해 _http._tcp.my-service.my-ns 에 대한
DNS SRV 쿼리를 수행할 수 있다.
쿠버네티스 DNS 서버는 ExternalName 서비스에 접근할 수 있는 유일한 방법이다.
DNS 파드와 서비스에서
ExternalName 검색에 대한 자세한 정보를 찾을 수 있다.
헤드리스(Headless) 서비스
때때로 로드-밸런싱과 단일 서비스 IP는 필요치 않다. 이 경우,
"헤드리스" 서비스라는 것을 만들 수 있는데, 명시적으로
클러스터 IP (.spec.clusterIP)에 "None"을 지정한다.
쿠버네티스의 구현에 묶이지 않고, 헤드리스 서비스를 사용하여
다른 서비스 디스커버리 메커니즘과 인터페이스할 수 있다.
헤드리스 서비스의 경우, 클러스터 IP가 할당되지 않고, kube-proxy가
이러한 서비스를 처리하지 않으며, 플랫폼에 의해 로드 밸런싱 또는 프록시를
하지 않는다. DNS가 자동으로 구성되는 방법은 서비스에 셀렉터가 정의되어 있는지
여부에 달려있다.
셀렉터가 있는 경우
셀렉터를 정의하는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
API에서 엔드포인트 레코드를 생성하고, DNS 구성을 수정하여
서비스 를 지원하는 파드 를 직접 가리키는 A 레코드(IP 주소)를 반환한다.
셀렉터가 없는 경우
셀렉터를 정의하지 않는 헤드리스 서비스의 경우, 엔드포인트 컨트롤러는
엔드포인트 레코드를 생성하지 않는다. 그러나 DNS 시스템은 다음 중 하나를 찾고
구성한다.
애플리케이션 중 일부(예: 프론트엔드)는 서비스를 클러스터 밖에
위치한 외부 IP 주소에 노출하고 싶은 경우가 있을 것이다.
쿠버네티스 ServiceTypes는 원하는 서비스 종류를 지정할 수 있도록 해준다.
기본 값은 ClusterIP이다.
Type 값과 그 동작은 다음과 같다.
ClusterIP: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면
클러스터 내에서만 서비스에 도달할 수 있다. 이것은
ServiceTypes의 기본 값이다.
NodePort: 고정 포트 (NodePort)로 각 노드의 IP에 서비스를
노출시킨다. NodePort 서비스가 라우팅되는 ClusterIP 서비스가
자동으로 생성된다. <NodeIP>:<NodePort>를 요청하여,
클러스터 외부에서
NodePort 서비스에 접속할 수 있다.
LoadBalancer: 클라우드 공급자의 로드 밸런서를 사용하여
서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는
NodePort와 ClusterIP 서비스가 자동으로 생성된다.
ExternalName: 값과 함께 CNAME 레코드를 리턴하여, 서비스를
externalName 필드의 콘텐츠 (예:foo.bar.example.com)에
매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.
참고:ExternalName 유형을 사용하려면 kube-dns 버전 1.7 또는
CoreDNS 버전 1.7 이상이 필요하다.
인그레스를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를
노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다.
NodePort 유형
type 필드를 NodePort로 설정하면, 쿠버네티스 컨트롤 플레인은
--service-node-port-range 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767).
각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다.
서비스는 할당된 포트를 .spec.ports[*].nodePort 필드에 나타낸다.
포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한
--nodeport-addresses 플래그 또는
kube-proxy 구성 파일의
동등한 nodePortAddresses 필드를
특정 IP 블록으로 설정할 수 있다.
이 플래그는 쉼표로 구분된 IP 블록 목록(예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, --nodeport-addresses=127.0.0.0/8 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. --nodeport-addresses의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
특정 포트 번호를 원한다면, nodePort 필드에 값을 지정할 수
있다. 컨트롤 플레인은 해당 포트를 할당하거나 API 트랜잭션이
실패했다고 보고한다.
이는 사용자 스스로 포트 충돌의 가능성을 고려해야 한다는 의미이다.
또한 NodePort 사용을 위해 구성된 범위 내에 있는, 유효한 포트 번호를
사용해야 한다.
NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설정하거나,
쿠버네티스가 완벽하게 지원하지 않는 환경을 구성하거나,
하나 이상의 노드 IP를 직접 노출시킬 수 있다.
이 서비스는 <NodeIP>:spec.ports[*].nodePort와
.spec.clusterIP:spec.ports[*].port로 표기된다.
kube-proxy에 대한 --nodeport-addresses 플래그 또는 kube-proxy 구성 파일의
동등한 필드가 설정된 경우, <NodeIP> 는 노드 IP를 필터링한다.
예를 들면
apiVersion:v1kind:Servicemetadata:name:my-servicespec:type:NodePortselector:app:MyAppports:# 기본적으로 그리고 편의상 `targetPort` 는 `port` 필드와 동일한 값으로 설정된다.- port:80targetPort:80# 선택적 필드# 기본적으로 그리고 편의상 쿠버네티스 컨트롤 플레인은 포트 범위에서 할당한다(기본값: 30000-32767)nodePort:30007
로드밸런서 유형
외부 로드 밸런서를 지원하는 클라우드 공급자 상에서, type
필드를 LoadBalancer로 설정하면 서비스에 대한 로드 밸런서를 프로비저닝한다.
로드 밸런서의 실제 생성은 비동기적으로 수행되고,
프로비저닝된 밸런서에 대한 정보는 서비스의
.status.loadBalancer 필드에 발행된다.
예를 들면
외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.
일부 클라우드 공급자는 loadBalancerIP를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
사용자 지정 loadBalancerIP로 생성된다. loadBalancerIP 필드가 지정되지 않으면,
임시 IP 주소로 loadBalancer가 설정된다. loadBalancerIP를 지정했지만
클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 loadbalancerIP 필드는
무시된다.
참고:
Azure 에서 사용자 지정 공개(public) 유형 loadBalancerIP를 사용하려면, 먼저
정적 유형 공개 IP 주소 리소스를 생성해야 한다. 이 공개 IP 주소 리소스는
클러스터에서 자동으로 생성된 다른 리소스와 동일한 리소스 그룹에 있어야 한다.
예를 들면, MC_myResourceGroup_myAKSCluster_eastus이다.
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 MixedProtocolLBService가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
참고: 로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
로드밸런서 NodePort 할당 비활성화
FEATURE STATE:Kubernetes v1.22 [beta]
type=LoadBalancer 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며,
이는 spec.allocateLoadBalancerNodePorts 필드를 false로 설정하면 된다.
노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 spec.allocateLoadBalancerNodePorts는 true이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
노드 포트가 할당된 기존 서비스에서 spec.allocateLoadBalancerNodePorts가 false로 설정된 경우
해당 노드 포트는 자동으로 할당 해제되지 않는다.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 nodePorts 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 클러스터에 ServiceLBNodePortControl기능 게이트가 활성화되어 있어야 한다.
쿠버네티스 v1.23에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로,
spec.allocateLoadBalancerNodePorts 필드를 사용할 수 있다.
다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
로드 밸런서 구현 클래스 지정
FEATURE STATE:Kubernetes v1.22 [beta]
spec.loadBalancerClass 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
이 필드를 사용하기 위해서는 클러스터에 ServiceLoadBalancerClass기능 게이트가 활성화되어 있어야 한다.
쿠버네티스 v1.23에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
기본적으로, spec.loadBalancerClass 는 nil 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 --cloud-provider 컴포넌트 플래그를 이용하여 설정되어 있으면
LoadBalancer 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
spec.loadBalancerClass 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
로드 밸런서 구현)은 이 필드가 설정된 서비스를 무시한다.
spec.loadBalancerClass 는 LoadBalancer 유형의 서비스에서만 설정할 수 있다.
한 번 설정하면 변경할 수 없다.
spec.loadBalancerClass 의 값은 "internal-vip" 또는
"example.com/internal-vip" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
내부 로드 밸런서
혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
라우팅해야 하는 경우가 있다.
수평 분할 DNS 환경에서는 외부와 내부 트래픽을 엔드포인트로 라우팅 할 수 있는 두 개의 서비스가 필요하다.
내부 로드 밸런서를 설정하려면, 사용 중인 클라우드 서비스 공급자에 따라
다음의 어노테이션 중 하나를 서비스에 추가한다.
버전 1.3.0 부터, 이 어노테이션의 사용은 ELB에 의해 프록시되는 모든 포트에 적용되며
다르게 구성할 수 없다.
AWS의 ELB 접근 로그
AWS ELB 서비스의 접근 로그를 관리하기 위한 몇 가지 어노테이션이 있다.
service.beta.kubernetes.io/aws-load-balancer-access-log-enabled 어노테이션은
접근 로그의 활성화 여부를 제어한다.
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval 어노테이션은
접근 로그를 게시하는 간격을 분 단위로 제어한다. 5분 또는 60분의
간격으로 지정할 수 있다.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name 어노테이션은
로드 밸런서 접근 로그가 저장되는 Amazon S3 버킷의 이름을
제어한다.
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix 어노테이션은
Amazon S3 버킷을 생성한 논리적 계층을 지정한다.
metadata:name:my-serviceannotations:service.beta.kubernetes.io/aws-load-balancer-access-log-enabled:"true"# 로드 밸런서의 접근 로그 활성화 여부를 명시.service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval:"60"# 접근 로그를 게시하는 간격을 분 단위로 제어. 5분 또는 60분의 간격을 지정.service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name:"my-bucket"# 로드 밸런서 접근 로그가 저장되는 Amazon S3 버킷의 이름 명시.service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix:"my-bucket-prefix/prod"# Amazon S3 버킷을 생성한 논리적 계층을 지정. 예: `my-bucket-prefix/prod`
AWS의 연결 드레이닝(Draining)
Classic ELB의 연결 드레이닝은
service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled 어노테이션을
"true"값으로 설정하여 관리할 수 있다. service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout 어노테이션을
사용하여 인스턴스를 해제하기 전에,
기존 연결을 열어 두는 목적으로 최대 시간을 초 단위로 설정할 수도 있다.
이하는 클래식 엘라스틱 로드 밸런서(Classic Elastic Load Balancers)를 관리하기 위한 다른 어노테이션이다.
metadata:name:my-serviceannotations:service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout:"60"# 로드 밸런서가 연결을 닫기 전에, 유휴 상태(연결을 통해 전송 된 데이터가 없음)의 연결을 허용하는 초단위 시간service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled:"true"# 로드 밸런서에 교차-영역(cross-zone) 로드 밸런싱을 사용할 지 여부를 지정service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags:"environment=prod,owner=devops"# 쉼표로 구분된 key-value 목록은 ELB에# 추가 태그로 기록됨service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold:""# 백엔드가 정상인 것으로 간주되는데 필요한 연속적인# 헬스 체크 성공 횟수이다. 기본값은 2이며, 2와 10 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold:"3"# 백엔드가 비정상인 것으로 간주되는데 필요한# 헬스 체크 실패 횟수이다. 기본값은 6이며, 2와 10 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval:"20"# 개별 인스턴스의 상태 점검 사이의# 대략적인 간격 (초 단위). 기본값은 10이며, 5와 300 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout:"5"# 헬스 체크 실패를 의미하는 무 응답의 총 시간 (초 단위)# 이 값은 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.service.beta.kubernetes.io/aws-load-balancer-security-groups:"sg-53fae93f"# 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록.# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,# '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다.# 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다.# 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다.# 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다.# 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다.service.beta.kubernetes.io/aws-load-balancer-extra-security-groups:"sg-53fae93f,sg-42efd82e"# 생성된 ELB에 추가할 추가 보안 그룹 목록# 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여# 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.service.beta.kubernetes.io/aws-load-balancer-target-node-labels:"ingress-gw,gw-name=public-api"# 로드 밸런서의 대상 노드를 선택하는 데# 사용되는 키-값 쌍의 쉼표로 구분된 목록
AWS의 네트워크 로드 밸런서 지원
FEATURE STATE:Kubernetes v1.15 [beta]
AWS에서 네트워크 로드 밸런서를 사용하려면, nlb 값이 설정된 service.beta.kubernetes.io/aws-load-balancer-type 어노테이션을 사용한다.
참고: NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 AWS 문서
를 참고한다.
클래식 엘라스틱 로드 밸런서와 달리, 네트워크 로드 밸런서 (NLB)는
클라이언트의 IP 주소를 노드로 전달한다. 서비스의 .spec.externalTrafficPolicy가
Cluster로 설정되어 있으면, 클라이언트의 IP 주소가 종단 파드로
전파되지 않는다.
.spec.externalTrafficPolicy를 Local로 설정하면, 클라이언트 IP 주소가
종단 파드로 전파되지만, 트래픽이 고르지 않게
분배될 수 있다. 특정 로드밸런서 서비스를 위한 파드가 없는 노드는 자동 할당된
.spec.healthCheckNodePort에 의해서 NLB 대상 그룹의
헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다.
클라이언트 트래픽이 NLB 뒤의 인스턴스에 도달하기 위해, 노드 보안
그룹은 다음 IP 규칙으로 수정된다.
규칙
프로토콜
포트
IP 범위
IP 범위 설명
헬스 체크
TCP
NodePort(s) (.spec.healthCheckNodePort for .spec.externalTrafficPolicy = Local)
Subnet CIDR
kubernetes.io/rule/nlb/health=<loadBalancerName>
클라이언트 트래픽
TCP
NodePort(s)
.spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0)
kubernetes.io/rule/nlb/client=<loadBalancerName>
MTU 탐색
ICMP
3,4
.spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0)
kubernetes.io/rule/nlb/mtu=<loadBalancerName>
네트워크 로드 밸런서에 접근할 수 있는 클라이언트 IP를 제한하려면,
loadBalancerSourceRanges를 지정한다.
spec:loadBalancerSourceRanges:- "143.231.0.0/16"
참고:.spec.loadBalancerSourceRanges가 설정되어 있지 않으면, 쿠버네티스는
0.0.0.0/0에서 노드 보안 그룹으로의 트래픽을 허용한다. 노드에 퍼블릭 IP 주소가
있는 경우, 비(non)-NLB 트래픽도 해당 수정된 보안 그룹의
모든 인스턴스에 도달할 수 있다.
아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다.
metadata:name:my-serviceannotations:# 지정된 노드로 로드 밸런서 바인드service.kubernetes.io/qcloud-loadbalancer-backends-label:key in (value1, value2)# 기존 로드 밸런서의 IDservice.kubernetes.io/tke-existed-lbid：lb-6swtxxxx# 로드 밸런서 (LB)에 대한 사용자 지정 매개 변수는 아직 LB 유형 수정을 지원하지 않음service.kubernetes.io/service.extensiveParameters:""# LB 리스너의 사용자 정의 매개 변수service.kubernetes.io/service.listenerParameters:""# 로드 밸런서 유형 지정# 유효 값 : 클래식 (클래식 클라우드 로드 밸런서) 또는 애플리케이션 (애플리케이션 클라우드 로드 밸런서)service.kubernetes.io/loadbalance-type:xxxxx# 퍼블릭 네트워크 대역폭 청구 방법 지정# 유효 값: TRAFFIC_POSTPAID_BY_HOUR (트래픽 별) 및 BANDWIDTH_POSTPAID_BY_HOUR (대역폭 별)service.kubernetes.io/qcloud-loadbalancer-internet-charge-type:xxxxxx# 대역폭 값 지정 (값 범위 : [1,2000] Mbps).service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out:"10"# 이 어느테이션이 설정되면, 로드 밸런서는 파드가# 실행중인 노드만 등록하고, 그렇지 않으면 모든 노드가 등록됨service.kubernetes.io/local-svc-only-bind-node-with-pod:true
ExternalName 유형
ExternalName 유형의 서비스는 my-service 또는 cassandra와 같은 일반적인 셀렉터에 대한 서비스가 아닌,
DNS 이름에 대한 서비스에 매핑한다. spec.externalName 파라미터를 사용하여 이러한 서비스를 지정한다.
예를 들면, 이 서비스 정의는 prod 네임 스페이스의
my-service 서비스를 my.database.example.com에 매핑한다.
참고: ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은
정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면,
헤드리스(headless) 서비스 사용을 고려한다.
my-service.prod.svc.cluster.local 호스트를 검색하면, 클러스터 DNS 서비스는
my.database.example.com 값의 CNAME 레코드를 반환한다. my-service에 접근하는 것은
다른 서비스와 같은 방식으로 작동하지만, 리다이렉션은 프록시 또는
포워딩을 통하지 않고 DNS 수준에서 발생한다는 중요한
차이점이 있다. 나중에 데이터베이스를 클러스터로 이동하기로 결정한 경우, 해당
파드를 시작하고 적절한 셀렉터 또는 엔드포인트를 추가하고,
서비스의 유형(type)을 변경할 수 있다.
경고:
HTTP 및 HTTPS를 포함한, 몇몇 일반적인 프로토콜에 ExternalName을 사용하는 것은 문제가 있을 수 있다. ExternalName을 사용하는 경우, 클러스터 내부의 클라이언트가 사용하는 호스트 이름(hostname)이 ExternalName이 참조하는 이름과 다르다.
호스트 이름을 사용하는 프로토콜의 경우, 이러한 차이로 인해 오류가 발생하거나 예기치 않은 응답이 발생할 수 있다. HTTP 요청에는 오리진(origin) 서버가 인식하지 못하는 Host : 헤더가 있다. TLS 서버는 클라이언트가 연결된 호스트 이름과 일치하는 인증서를 제공할 수 없다.
하나 이상의 클러스터 노드로 라우팅되는 외부 IP가 있는 경우, 쿠버네티스 서비스는 이러한
externalIPs에 노출될 수 있다. 서비스 포트에서 외부 IP (목적지 IP)를 사용하여 클러스터로 들어오는 트래픽은
서비스 엔드포인트 중 하나로 라우팅된다. externalIPs는 쿠버네티스에 의해 관리되지 않으며
클러스터 관리자에게 책임이 있다.
서비스 명세에서, externalIPs는 모든 ServiceTypes와 함께 지정할 수 있다.
아래 예에서, 클라이언트는 "80.11.12.10:80"(외부 IP:포트)로 "my-service"에 접근할 수 있다.
VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일에서는 동작하지만, 수천 개의
서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
포털에 대한 독창적인 설계 제안에 이에 대한 자세한 내용이
있다.
유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가
가려진다.
이것은 일종의 네트워크 필터링 (방화벽)을 불가능하게 만든다. iptables
프록시 모드는 클러스터 내
소스 IP를 가리지 않지만, 여전히 로드 밸런서 또는 노드-포트를 통해 오는
클라이언트에 영향을 미친다.
Type 필드는 중첩된 기능으로 설계되었다. - 각 레벨은 이전 레벨에
추가된다. 이는 모든 클라우드 공급자에 반드시 필요한 것은 아니지만, (예: Google Compute Engine는
LoadBalancer를 작동시키기 위해 NodePort를 할당할 필요는 없지만, AWS는 필요하다)
현재 API에는 필요하다.
가상 IP 구현
서비스를 사용하려는 많은 사람들에게 이전 정보가
충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
많은 일이 있다.
충돌 방지
쿠버네티스의 주요 철학 중 하나는 잘못한 것이
없는 경우 실패할 수 있는 상황에 노출되어서는
안된다는 것이다. 서비스 리소스 설계 시, 다른 사람의 포트 선택과
충돌할 경우에 대비해 자신의 포트 번호를 선택하지
않아도 된다. 그것은 격리 실패이다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
할당하여 이를 수행한다.
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
각 서비스를 만들기 전에 etcd에서
글로벌 할당 맵을 원자적으로(atomically) 업데이트한다. 서비스가 IP 주소 할당을 가져오려면
레지스트리에 맵 오브젝트가 있어야 하는데, 그렇지 않으면
IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
컨트롤 플레인에서, 백그라운드 컨트롤러는 해당 맵을
생성해야 한다. (인-메모리 잠금을 사용하는 이전 버전의 쿠버네티스에서 마이그레이션
지원 필요함) 쿠버네티스는 또한 컨트롤러를 사용하여 유효하지 않은
할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
IP 주소를 정리한다.
서비스 IP 주소
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,
서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는
iptables (리눅스의 패킷 처리 로직)를 필요에 따라
명백하게 리다이렉션되는 가상 IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에
연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다.
환경 변수와 서비스 용 DNS는 실제로 서비스의
가상 IP 주소 (및 포트)로 채워진다.
kube-proxy는 조금씩 다르게 작동하는 세 가지 프록시 모드—유저스페이스, iptables and IPVS—를
지원한다.
유저스페이스 (Userspace)
예를 들어, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 마스터는 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새 서비스를 발견하면, 새로운 임의의 포트를 열고, 가상 IP 주소에서
이 새로운 포트로 iptables 리다이렉션을 설정한 후,
연결을 수락하기 시작한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면, iptables
규칙이 시작되고, 패킷을 프록시의 자체 포트로 리다이렉션한다.
"서비스 프록시"는 백엔드를 선택하고, 클라이언트에서 백엔드로의 트래픽을 프록시하기 시작한다.
이는 서비스 소유자가 충돌 위험 없이 원하는 어떤 포트든 선택할 수 있음을
의미한다. 클라이언트는 실제로 접근하는 파드를 몰라도, IP와 포트에
연결할 수 있다.
iptables
다시 한번, 위에서 설명한 이미지 처리 애플리케이션을 고려한다.
백엔드 서비스가 생성되면, 쿠버네티스 컨트롤 플레인은 가상
IP 주소(예 : 10.0.0.1)를 할당한다. 서비스 포트를 1234라고 가정하면, 서비스는
클러스터의 모든 kube-proxy 인스턴스에서 관찰된다.
프록시가 새로운 서비스를 발견하면, 가상 IP 주소에서 서비스-별 규칙으로
리다이렉션되는 일련의 iptables 규칙을 설치한다. 서비스-별
규칙은 트래픽을 (목적지 NAT를 사용하여) 백엔드로 리다이렉션하는 엔드포인트-별 규칙에
연결한다.
클라이언트가 서비스의 가상 IP 주소에 연결하면 iptables 규칙이 시작한다.
(세션 어피니티(Affinity)에 따라 또는 무작위로) 백엔드가 선택되고 패킷이
백엔드로 리다이렉션된다. 유저스페이스 프록시와 달리, 패킷은 유저스페이스로
복사되지 않으며, 가상 IP 주소가 작동하기 위해 kube-proxy가
실행 중일 필요는 없으며, 노드는 변경되지 않은 클라이언트 IP 주소에서 오는
트래픽을 본다.
트래픽이 노드-포트 또는 로드 밸런서를 통해 들어오는 경우에도,
이와 동일한 기본 흐름이 실행되지만, 클라이언트 IP는 변경된다.
IPVS
iptables 작업은 대규모 클러스터 (예: 10,000 서비스)에서 크게 느려진다.
IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이블을 기반으로 한다. 따라서 IPVS 기반 kube-proxy로부터 많은 개수의 서비스에서 일관성 있는 성능을 가질 수 있다. 한편, IPVS 기반 kube-proxy는 보다 정교한 로드 밸런싱 알고리즘 (least conns, locality, weighted, persistence)을 가진다.
API 오브젝트
서비스는 쿠버네티스 REST API의 최상위 리소스이다. API 오브젝트에 대한
자세한 내용은 다음을 참고한다. 서비스 API 오브젝트
지원되는 프로토콜
TCP
모든 종류의 서비스에 TCP를 사용할 수 있으며, 이는 기본 네트워크 프로토콜이다.
UDP
대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은
이 기능을 제공하는 클라우드 공급자에 따라 다르다.
SCTP
FEATURE STATE:Kubernetes v1.20 [stable]
SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다.
type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는
클라우드 공급자에 따라 다르다. (대부분 그렇지 않음)
경고
멀티홈드(multihomed) SCTP 연결을 위한 지원
경고:
멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
윈도우
경고: SCTP는 윈도우 기반 노드를 지원하지 않는다.
유저스페이스 kube-proxy
경고: kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
HTTP
클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의
서비스를 사용하여 서비스의 엔드포인트로 전달하는 외부 HTTP / HTTPS 리버스 프록시를
설정할 수 있다.
참고: 이 기능, 특히 알파 topologyKeys API는 쿠버네티스 v1.21부터
더 이상 사용되지 않는다.
쿠버네티스 v1.21에 도입된 토폴로지 인지 힌트는
유사한 기능을 제공한다.
서비스 토폴로지 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
클라이언트와 동일한 노드이거나 동일한 가용성 영역에 있는 엔드포인트로
우선적으로 라우팅되도록 지정할 수 있다.
소개
기본적으로 ClusterIP 또는 NodePort 서비스로 전송된 트래픽은 서비스의
모든 백엔드 주소로 라우팅될 수 있다. 쿠버네티스 1.7을 사용하면 트래픽을 수신한
동일한 노드에서 실행 중인 파드로 "외부(external)" 트래픽을 라우팅할 수
있다. ClusterIP 서비스의 경우, 라우팅에 대한 동일한 노드 기본 설정이
불가능했다. 또한 동일한 영역 내의 엔드 포인트에 대한 라우팅을 선호하도록
클러스터를 구성할 수도 없다.
서비스에 topologyKeys 를 설정하면, 출발 및 대상 노드에 대한
노드 레이블을 기반으로 트래픽을 라우팅하는 정책을 정의할 수 있다.
소스와 목적지 사이의 레이블 일치를 통해 클러스터 운영자는
서로 "근접(closer)"하거나 "먼(father)" 노드 그룹을 지정할 수 있다.
자신의 요구 사항에 맞는 메트릭을 나타내는 레이블을 정의할 수 있다.
예를 들어, 퍼블릭 클라우드에서는 지역 간의 트래픽에는 관련 비용이 발생(지역 내
트래픽은 일반적으로 그렇지 않다)하기 때문에, 네트워크 트래픽을 동일한 지역 내에 유지하는 것을
선호할 수 있다. 다른 일반적인 필요성으로는 데몬셋(DaemonSet)이 관리하는
로컬 파드로 트래픽을 라우팅하거나, 대기 시간을 최소화하기 위해
동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을
유지하는 것이 있다.
서비스 토폴로지 사용하기
만약 클러스터에서 ServiceTopology기능 게이트가 활성화된 경우, 서비스 사양에서
topologyKeys 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
발신 노드 값과 일치하는 노드로 보내진다. 만약 노드에 서비스와 일치하는
백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
레이블이 남지 않을 때까지 고려한다.
만약 일치하는 것을 못찾는 경우에는, 서비스에 대한 백엔드가 없었던 것처럼
트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
대한 백엔드가 없기에 연결에 실패해야 한다. 특수한 값인 "*" 은 "모든 토폴로지"를
의미하는데 사용될 수 있다. 이 캐치 올(catch-all) 값을 사용하는 경우
목록의 마지막 값으로만 타당하다.
만약 topologyKeys 가 지정되지 않거나 비어있는 경우 토폴로지 제약 조건이 적용되지 않는다.
호스트 이름, 영역 이름 그리고 지역 이름으로 레이블이 지정된 노드가 있는
클러스터가 있다고 생각해 보자. 그러고 나면, 서비스의 topologyKeys 값을 설정해서 다음과 같이 트래픽을
전달할 수 있다.
동일한 노드의 엔드포인트에만 해당하고, 엔드포인트가 노드에 없으면 실패한다:
["kubernetes.io/hostname"].
동일한 노드의 엔드포인트를 선호하지만, 동일한 영역의 엔드포인트로 대체
한 후 동일한 지역으로 대체되고, 그렇지 않으면 실패한다: ["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"].
예를 들어 데이터 위치가 중요한 경우에 유용할 수 있다.
동일한 영역이 선호되지만, 이 영역 내에 사용할 수 있는 항목이 없는 경우에는
사용가능한 엔드포인트로 대체된다:
["topology.kubernetes.io/zone", "*"].
제약들
서비스 토폴로지는 externalTrafficPolicy=Local 와 호환되지 않으므로
서비스는 이 두 가지 기능을 함께 사용할 수 없다. 동일한 서비스가 아닌
같은 클러스터의 다른 서비스라면 이 기능을 함께 사용할
수 있다.
유효한 토폴로지 키는 현재 kubernetes.io/hostname,
topology.kubernetes.io/zone 그리고 topology.kubernetes.io/region 로
제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.
만약 캐치 올(catch-all) 값인 "*" 를 사용한다면 토폴로지 키들의 마지막 값이어야
한다.
예시들
다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다.
노드 로컬 엔드포인트만
노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다.
쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에
일관된 DNS 네임을 통해서 서비스에 접속할 수 있다.
소개
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며,
개별 컨테이너들이 DNS 네임을 해석할 때
DNS 서비스의 IP를 사용하도록 kubelets를 구성한다.
클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다.
기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와
클러스터의 기본 도메인을 포함한다.
서비스의 네임스페이스
DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다른 결과를 반환할 수
있다. 네임스페이스를 지정하지 않은 DNS 쿼리는 파드의 네임스페이스에
국한된다. DNS 쿼리에 네임스페이스를 명시하여 다른 네임스페이스에 있는 서비스에 접속한다.
예를 들어, test 네임스페이스에 있는 파드를 생각해보자. data 서비스는
prod 네임스페이스에 있다.
이 경우, data 에 대한 쿼리는 파드의 test 네임스페이스를 사용하기 때문에 결과를 반환하지 않을 것이다.
data.prod 로 쿼리하면 의도한 결과를 반환할 것이다. 왜냐하면
네임스페이스가 명시되어 있기 때문이다.
DNS 쿼리는 파드의 /etc/resolv.conf 를 사용하여 확장될 수 있을 것이다. Kubelet은
각 파드에 대해서 파일을 설정한다. 예를 들어, data 만을 위한 쿼리는
data.test.svc.cluster.local 로 확장된다. search 옵션의 값은
쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우,
resolv.conf 설명 페이지.를 참고한다.
요약하면, test 네임스페이스에 있는 파드는 data.prod 또는
data.prod.svc.cluster.local 중 하나를 통해 성공적으로 해석될 수 있다.
DNS 레코드
어떤 오브젝트가 DNS 레코드를 가지는가?
서비스
파드
다음 섹션은 지원되는 DNS 레코드의 종류 및 레이아웃에 대한 상세
내용이다. 혹시 동작시킬 필요가 있는 다른 레이아웃, 네임, 또는 쿼리는
구현 세부 사항으로 간주되며 경고 없이 변경될 수 있다.
최신 명세 확인을 위해서는,
쿠버네티스 DNS-기반 서비스 디스커버리를 본다.
서비스
A/AAAA 레코드
"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라
my-svc.my-namespace.svc.cluster-domain.example
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터
IP로 해석된다.
"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라
my-svc.my-namespace.svc.cluster-domain.example
형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다.
노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다.
클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을
통해 선택할 수 있다.
SRV 레코드
SRV 레코드는 노멀 서비스 또는
헤드리스 서비스에
속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다.
_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example.
정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다.
my-svc.my-namespace.svc.cluster-domain.example.
헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의
포트 번호와 도메인 이름을 포함한다.
auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example.
파드 스펙(Pod spec)에는 선택적 필드인 hostname이 있다.
이 필드는 파드의 호스트네임을 지정할 수 있다.
hostname 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다.
예를 들어 hostname 필드가 "my-host"로 설정된 파드는 호스트네임이 "my-host"로 설정된다.
또한, 파드 스펙에는 선택적 필드인 subdomain이 있다. 이 필드는 서브도메인을 지정할 수 있다.
예를 들어 "my-namespace" 네임스페이스에서, hostname 필드가 "foo"로 설정되고,
subdomain 필드가 "bar"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다.
"foo.bar.my-namespace.svc.cluster-domain.example".
파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면,
클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다.
예를 들어 호스트네임이 "busybox-1"이고,
서브도메인이 "default-subdomain"이고,
같은 네임스페이스 내 헤드리스 서비스의 이름이 "default-subdomain"이면,
파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다.
"busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example".
DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
"busybox1"와 "busybox2" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.
엔드포인트 오브젝트는 hostname 필드를
임의의 엔드포인트 IP 주소로 지정할 수 있다.
참고: A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에
파드의 A 또는 AAAA 레코드를 생성하기 위해서는 hostname 필드를 작성해야 한다.
hostname 필드는 없고 subdomain 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의
A 또는 AAAA 레코드만 생성할 수 있다. (default-subdomain.my-namespace.svc.cluster-domain.example)
또한 서비스에서 publishNotReadyAddresses=True 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
파드의 setHostnameAsFQDN 필드
FEATURE STATE:Kubernetes v1.22 [stable]
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 hostname 명령어는 busybox-1 을 반환하고 hostname --fqdn 명령은 FQDN을 반환한다.
파드 명세에서 setHostnameAsFQDN: true 를 설정하면, kubelet은 파드의 FQDN을 해당 파드 네임스페이스의 호스트네임에 기록한다. 이 경우, hostname 과 hostname --fqdn 은 모두 파드의 FQDN을 반환한다.
참고:
리눅스에서, 커널의 호스트네임 필드(struct utsname 의 nodename 필드)는 64자로 제한된다.
파드에서 이 기능을 사용하도록 설정하고 FQDN이 64자보다 길면, 시작되지 않는다. 파드는 파드 호스트네임과 클러스터 도메인에서 FQDN을 구성하지 못한다거나, FQDN long-FDQN 이 너무 길다(최대 64자, 70자 요청인 경우)와 같은 오류 이벤트를 생성하는 Pending 상태(kubectl 에서 표시하는 ContainerCreating)로 유지된다. 이 시나리오에서 사용자 경험을 개선하는 한 가지 방법은 사용자가 최상위 레벨을 오브젝트(예를 들어, 디플로이먼트)를 생성할 때 FQDN 크기를 제어하기 위해 어드미션 웹훅 컨트롤러를 생성하는 것이다.
파드의 DNS 정책
DNS 정책은 파드별로 설정할 수 있다.
현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다.
이 정책들은 파드 스펙의 dnsPolicy 필드에서 지정할 수 있다.
"Default": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다.
자세한 내용은
관련 논의에서
확인할 수 있다.
"ClusterFirst": "www.kubernetes.io"와 같이 클러스터 도메인 suffix 구성과
일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다.
클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다.
그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은
관련 논의에서
확인할 수 있다.
"ClusterFirstWithHostNet": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인
"ClusterFirstWithHostNet"을 명시적으로 설정해야 한다.
"None": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다.
모든 DNS 설정은 파드 스펙 내에 dnsConfig필드를 사용하여 제공해야 한다.
아래 절인 파드의 DNS 설정에서
자세한 내용을 확인할 수 있다.
참고: "Default"는 기본 DNS 정책이 아니다. dnsPolicy가 명시적으로 지정되어 있지 않다면
"ClusterFirst"가 기본값으로 사용된다.
아래 예시는 hostNetwork필드가 true로 설정되어 있어서
DNS 정책이 "ClusterFirstWithHostNet"으로 설정된 파드를 보여준다.
dnsConfig 필드는 선택적이고, dnsPolicy 세팅과 함께 동작한다.
이때, 파드의 dnsPolicy의 값이 "None"으로 설정되어 있어야
dnsConfig 필드를 지정할 수 있다.
사용자는 dnsConfig 필드에서 다음과 같은 속성들을 지정할 수 있다.
nameservers: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다.
파드의 dnsPolicy가 "None" 으로 설정된 경우에는
적어도 하나의 IP 주소가 포함되어야 하며,
그렇지 않으면 이 속성은 생략할 수 있다.
nameservers에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며
중복되는 주소는 제거된다.
searches: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다.
이 속성은 생략이 가능하며,
값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
병합 시 중복되는 도메인은 제거되며,
쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
options: name 속성(필수)과 value 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다.
이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
병합 시 중복되는 항목은 제거된다.
쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트(localhost)에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다.
파드를 클러스터에 노출하기
이 작업은 이전 예시에서 수행해 보았지만, 네트워킹 관점을 중점에 두고 다시 한번 수행해 보자.
nginx 파드를 생성하고, 해당 파드에 컨테이너 포트 사양이 있는 것을 참고한다.
이제 클러스터의 모든 노드로 ssh 접속하거나 curl과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 않으며 , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
kubectl expose 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
이 사양은 run: my-nginx 레이블이 부착된 모든 파드에 TCP 포트 80을
대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다
(targetPort 는 컨테이너가 트래픽을 수신하는 포트, port 는
추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는
모든 포트일 수 있다).
서비스의
API 오브젝트를 보고 서비스 정의에서 지원되는 필드 목록을 확인한다.
서비스를 확인한다.
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
앞에서 언급한 바와 같이, 서비스는 파드 그룹에 의해 지원된다. 이 파드들은
endpoints 를 통해 노출된다. 서비스 셀렉터는 지속적으로 평가되고
결과는 my-nginx 이름의 엔드포인트 오브젝트에 POST된다.
파드가 죽으면 자동적으로 엔드포인트에서 제거되며 서비스 셀렉터와
일치하는 새 파드는 자동적으로 엔드포인트에 추가된다.
엔드포인트를 확인하고 IP가 첫 번째 단계에서 생성된 파드와 동일하다는
점을 참고한다.
NAME ENDPOINTS AGE
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
이제 클러스터의 모든 노드에서 <CLUSTER-IP>:<PORT> 로 nginx 서비스를
curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
서비스 프록시에 대해 더 읽어본다.
서비스에 접근하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
CoreDNS 클러스터 애드온이 필요하다.
참고: 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) 파드 사양에서
enableServiceLinks 플래그를 false 로 설정하면 이 모드를 비활성화할 수 있다.
환경 변수들
파드가 노드에서 실행될 때 kubelet은 각기 활성화된 서비스에 대해 일련의 환경
변수 집합을 추가한다. 이것은 순서 문제를 야기한다. 이유를 확인하려면
실행 중인 nginx 파드 환경을 점검해야 한다(실제 사용자의 파드 이름은 다를 것이다).
kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
서비스에 대한 언급이 없다는 것에 참고해야 한다. 이것은 서비스 이전에 레플리카를
생성했기 때문이다. 이 작업을 수행할 때 또 다른 단점은 스케줄러가 두 파드를
모두 동일한 머신에 배치할 수도 있다는 것이며, 이로 인해 전체 서비스가 중단될 수
있다. 두개의 파드를 죽이고 디플로이먼트가 파드를 재생성하기를 기다리는 것으로
이를 정상화 할 수 있다. 이번에는 서비스가 레플리카들 전 에
존재한다. 이렇게 하면 올바른 환경 변수뿐만 아니라 파드의 스케줄러-수준의
서비스 분배(모든 노드에 동일한 용량이 제공되는 경우)가
된다.
쿠버네티스는 DNS 클러스터 애드온 서비스를 제공하며 dns 이름을 다른 서비스에 자동으로 할당한다. 다음 명령어로 이것이 클러스터에서 실행 중인지 확인할 수 있다.
kubectl get services kube-dns --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP
에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 kube-dns)을 사용하므로, 표준 방법(예: gethostbyname())을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 CoreDNS README 또는 CoreDNS 설치를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
kubectl run curl --image=radial/busyboxplus:curl -i --tty
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
Hit enter for command prompt
kubectl get pods -o yaml | grep -i podip
podIP: 10.244.3.5
node $ curl -k https://10.244.3.5
...
<h1>Welcome to nginx!</h1>
마지막 단계에서 curl에 -k 파라미터를 제공한 방법에 참고한다. 이는 인증서 생성시 nginx를 실행하는 파드에 대해 아무것도 모르기 때문에
curl에 CName 불일치를 무시하도록 지시해야하기 때문이다. 서비스를 생성해서 인증서에 사용된 CName을 서비스 조회시 파드에서 사용된 실제 DNS 이름과 연결했다.
파드에서 이것을 테스트 해보자(단순히 동일한 시크릿이 재사용되고 있으며, 파드는 서비스에 접근하기위해 nginx.crt만 필요하다).
애플리케이션의 일부인 경우 원한다면 외부 IP 주소에 서비스를
노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 NodePort 를 사용했기에
노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
준비가 되어 있다.
이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. my-nginx 서비스의 Type 을 NodePort 에서 LoadBalancer 로 변경한다.
kubectl edit svc my-nginx
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
curl https://<EXTERNAL-IP> -k
...
<title>Welcome to nginx!</title>
EXTERNAL-IP 의 IP 주소는 공용 인터넷에서 이용할 수 있는 주소이다. CLUSTER-IP 는
클러스터/프라이빗 클라우드 네트워크 내에서만 사용할 수 있다.
AWS에서는 LoadBalancer 유형은 IP가 아닌 (긴)호스트네임을 사용하는 ELB를
생성한다는 점을 참고한다. 이것은 일반적인 kubectl get svc 의 출력에
맞추기에는 매우 길기 때문에 실제로 이를 보려면 kubectl describe service my-nginx 를
수행해야 한다. 다음과 같은 것을 보게 된다.
kubectl describe service my-nginx
...
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
클러스터와 함께 자동으로 실행되지 않는다.
클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
프로젝트로서 쿠버네티스는 AWS, GCE와
nginx 인그레스 컨트롤러를 지원하고 유지한다.
추가 컨트롤러
참고:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
하나의 클러스터 내에 여러 개의 인그레스 컨트롤러를 배포할 수 있다.
인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우
어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 ingress.class
어노테이션을 각각의 인그레스에 달아야 한다.
만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다.
이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만,
다양한 인그레스 컨트롤러는 약간 다르게 작동한다.
클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.
인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다.
용어
이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다.
노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
클러스터 네트워크(Cluster network): 쿠버네티스 네트워킹 모델에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
서비스: 레이블 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 서비스. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
인그레스란?
인그레스는 클러스터 외부에서 클러스터 내부
서비스로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
다음은 인그레스가 모든 트래픽을 하나의 서비스로 보내는 간단한 예시이다.
graph LR;
client([클라이언트])-. 인그레스-매니지드 로드 밸런서 .->ingress[인그레스];
ingress-->|라우팅 규칙|service[서비스];
subgraph 클러스터
ingress;
service-->pod1[파드];
service-->pod2[파드];
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class ingress,service,pod1,pod2 k8s;
class client plain;
class cluster cluster;
인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 apiVersion, kind, 그리고 metadata 필드가 필요하다.
인그레스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 애플리케이션 배포하기, 컨테이너 구성하기, 리소스 관리하기를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 재작성-타겟 어노테이션이다.
서로 다른 인그레스 컨트롤러는 서로 다른 어노테이션을 지원한다.
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
인그레스 사양
에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은,
들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을
지시하는 규칙만 지원한다.
ingressClassName을 생략하려면, 기본 인그레스 클래스가
정의되어 있어야 한다.
몇몇 인그레스 컨트롤러는 기본 IngressClass가 정의되어 있지 않아도 동작한다.
예를 들어, Ingress-NGINX 컨트롤러는 --watch-ingress-without-class플래그를 이용하여 구성될 수 있다.
하지만 아래에 나와 있는 것과 같이 기본 IngressClass를 명시하는 것을
권장한다.
인그레스 규칙
각 HTTP 규칙에는 다음의 정보가 포함된다.
선택적 호스트. 이 예시에서는, 호스트가 지정되지 않기에 지정된 IP 주소를 통해 모든 인바운드
HTTP 트래픽에 규칙이 적용 된다. 만약 호스트가 제공되면(예,
foo.bar.com), 규칙이 해당 호스트에 적용된다.
경로 목록 (예, /testpath)에는 각각 service.name 과
service.port.name 또는 service.port.number 가 정의되어 있는 관련
백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로
보내기 전에 호스트와 경로가 모두 수신 요청의 내용과
일치해야 한다.
백엔드는 서비스 문서 또는 사용자 정의 리소스 백엔드에 설명된 바와 같이
서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한
HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다.
defaultBackend 는 종종 사양의 경로와 일치하지 않는 서비스에 대한 모든 요청을 처리하도록 인그레스
컨트롤러에 구성되는 경우가 많다.
DefaultBackend
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. defaultBackend 는 일반적으로
인그레스 컨트롤러의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
리소스 백엔드
Resource 백엔드는 인그레스 오브젝트와 동일한 네임스페이스 내에 있는
다른 쿠버네티스 리소스에 대한 ObjectRef이다. Resource 는 서비스와
상호 배타적인 설정이며, 둘 다 지정하면 유효성 검사에 실패한다. Resource
백엔드의 일반적인 용도는 정적 자산이 있는 오브젝트 스토리지 백엔드로 데이터를
수신하는 것이다.
인그레스의 각 경로에는 해당 경로 유형이 있어야 한다. 명시적
pathType 을 포함하지 않는 경로는 유효성 검사에 실패한다. 지원되는
경로 유형은 세 가지이다.
ImplementationSpecific: 이 경로 유형의 일치 여부는 IngressClass에 따라
달라진다. 이를 구현할 때 별도 pathType 으로 처리하거나, Prefix 또는 Exact
경로 유형과 같이 동일하게 처리할 수 있다.
Exact: URL 경로의 대소문자를 엄격하게 일치시킨다.
Prefix: URL 경로의 접두사를 / 를 기준으로 분리한 값과 일치시킨다.
일치는 대소문자를 구분하고,
요소별로 경로 요소에 대해 수행한다.
모든 p 가 요청 경로의 요소별 접두사가 p 인 경우
요청은 p 경로에 일치한다.
참고: 경로의 마지막 요소가 요청 경로에 있는 마지막
요소의 하위 문자열인 경우에는 일치하지 않는다(예시: /foo/bar 는
/foo/bar/baz 와 일치하지만, /foo/barbaz 와는 일치하지 않는다).
예제
종류
경로
요청 경로
일치 여부
Prefix
/
(모든 경로)
예
Exact
/foo
/foo
예
Exact
/foo
/bar
아니오
Exact
/foo
/foo/
아니오
Exact
/foo/
/foo
아니오
Prefix
/foo
/foo, /foo/
예
Prefix
/foo/
/foo, /foo/
예
Prefix
/aaa/bb
/aaa/bbb
아니오
Prefix
/aaa/bbb
/aaa/bbb
예
Prefix
/aaa/bbb/
/aaa/bbb
예, 마지막 슬래시 무시함
Prefix
/aaa/bbb
/aaa/bbb/
예, 마지막 슬래시 일치함
Prefix
/aaa/bbb
/aaa/bbb/ccc
예, 하위 경로 일치함
Prefix
/aaa/bbb
/aaa/bbbxyz
아니오, 문자열 접두사 일치하지 않음
Prefix
/, /aaa
/aaa/ccc
예, /aaa 접두사 일치함
Prefix
/, /aaa, /aaa/bbb
/aaa/bbb
예, /aaa/bbb 접두사 일치함
Prefix
/, /aaa, /aaa/bbb
/ccc
예, / 접두사 일치함
Prefix
/aaa
/ccc
아니오, 기본 백엔드 사용함
Mixed
/foo (Prefix), /foo (Exact)
/foo
예, Exact 선호함
다중 일치
경우에 따라 인그레스의 여러 경로가 요청과 일치할 수 있다.
이 경우 가장 긴 일치하는 경로가 우선하게 된다. 두 개의 경로가
여전히 동일하게 일치하는 경우 접두사(prefix) 경로 유형보다
정확한(exact) 경로 유형을 가진 경로가 사용 된다.
호스트네임 와일드카드
호스트는 정확한 일치(예: "foo.bar.com") 또는 와일드카드(예:
"* .foo.com")일 수 있다. 정확한 일치를 위해서는 HTTP host 헤더가
host 필드와 일치해야 한다. 와일드카드 일치를 위해서는 HTTP host 헤더가
와일드카드 규칙의 접미사와 동일해야 한다.
.spec.parameters 필드만 설정하고 .spec.parameters.scope 필드는 지정하지 않거나,
.spec.parameters.scope 필드를 Cluster로 지정하면,
인그레스클래스는 클러스터 범위의 리소스를 참조한다.
파라미터의 kind(+apiGroup)는
클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며,
파라미터의 name은
해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다.
예시는 다음과 같다.
---apiVersion:networking.k8s.io/v1kind:IngressClassmetadata:name:external-lb-1spec:controller:example.com/ingress-controllerparameters:# 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는# ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다.# 이 정의는 쿠버네티스가 # 클러스터 범위의 파라미터 리소스를 검색하도록 한다.scope:ClusterapiGroup:k8s.example.netkind:ClusterIngressParametername:external-config-1
FEATURE STATE:Kubernetes v1.23 [stable]
.spec.parameters 필드를 설정하고
.spec.parameters.scope 필드를 Namespace로 지정하면,
인그레스클래스는 네임스페이스 범위의 리소스를 참조한다.
사용하고자 하는 파라미터가 속한 네임스페이스를
.spec.parameters 의 namespace 필드에 설정해야 한다.
파라미터의 kind(+apiGroup)는
네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며,
파라미터의 name은
namespace에 명시한 네임스페이스의 특정 리소스를 가리킨다.
네임스페이스 범위의 파라미터를 이용하여,
클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다.
클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다.
다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다
클러스터 운영 팀이 매번 승인을 해야 한다. 또는,
애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는
RBAC 롤, 바인딩 등의 특별 접근 제어를
클러스터 운영자가 정의해야 한다.
인그레스클래스 API 자신은 항상 클러스터 범위이다.
네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가
다음과 같다.
---apiVersion:networking.k8s.io/v1kind:IngressClassmetadata:name:external-lb-2spec:controller:example.com/ingress-controllerparameters:# 이 인그레스클래스에 대한 파라미터는 # "external-configuration" 환경 설정 네임스페이스에 있는# "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.scope:NamespaceapiGroup:k8s.example.comkind:IngressParameternamespace:external-configurationname:external-config
사용중단(Deprecated) 어노테이션
쿠버네티스 1.18에 IngressClass 리소스 및 ingressClassName 필드가 추가되기
전에 인그레스 클래스는 인그레스에서
kubernetes.io/ingress.class 어노테이션으로 지정되었다. 이 어노테이션은
공식적으로 정의된 것은 아니지만, 인그레스 컨트롤러에서 널리 지원되었었다.
인그레스의 최신 ingressClassName 필드는 해당 어노테이션을
대체하지만, 직접적으로 해당하는 것은 아니다. 어노테이션은 일반적으로
인그레스를 구현해야 하는 인그레스 컨트롤러의 이름을 참조하는 데 사용되었지만,
이 필드는 인그레스 컨트롤러의 이름을 포함하는 추가 인그레스 구성이
포함된 인그레스 클래스 리소스에 대한 참조이다.
기본 IngressClass
특정 IngressClass를 클러스터의 기본 값으로 표시할 수 있다. IngressClass
리소스에서 ingressclass.kubernetes.io/is-default-class 를 true 로
설정하면 ingressClassName 필드가 지정되지 않은
새 인그레스에게 기본 IngressClass가 할당된다.
주의: 클러스터의 기본값으로 표시된 IngressClass가 두 개 이상 있는 경우
어드미션 컨트롤러에서 ingressClassName 이 지정되지 않은
새 인그레스 오브젝트를 생성할 수 없다. 클러스터에서 최대 1개의 IngressClass가
기본값으로 표시하도록 해서 이 문제를 해결할 수 있다.
몇몇 인그레스 컨트롤러는 기본 IngressClass가 정의되어 있지 않아도 동작한다.
예를 들어, Ingress-NGINX 컨트롤러는 --watch-ingress-without-class플래그를 이용하여 구성될 수 있다.
하지만 다음과 같이 기본 IngressClass를 명시하는 것을
권장한다.
만약 규칙에 정의된 호스트 없이 인그레스 리소스를 생성하는 경우,
이름 기반 가상 호스트가 없어도 인그레스 컨트롤러의 IP 주소에 대한 웹
트래픽을 일치 시킬 수 있다.
예를 들어, 다음 인그레스는 first.bar.com에 요청된 트래픽을
service1로, second.bar.com는 service2로, 그리고 요청 헤더가 first.bar.com 또는 second.bar.com에 해당되지 않는 모든 트래픽을 service3로 라우팅한다.
TLS 개인 키 및 인증서가 포함된 시크릿(Secret)을
지정해서 인그레스를 보호할 수 있다. 인그레스 리소스는
단일 TLS 포트인 443만 지원하고 인그레스 지점에서 TLS 종료를
가정한다(서비스 및 해당 파드에 대한 트래픽은 일반 텍스트임).
인그레스의 TLS 구성 섹션에서 다른 호스트를 지정하면, SNI TLS 확장을 통해
지정된 호스트이름에 따라 동일한 포트에서 멀티플렉싱
된다(인그레스 컨트롤러가 SNI를 지원하는 경우). TLS secret에는
tls.crt 와 tls.key 라는 이름의 키가 있어야 하고, 여기에는 TLS에 사용할 인증서와
개인 키가 있다. 예를 들어 다음과 같다.
인그레스에서 시크릿을 참조하면 인그레스 컨트롤러가 TLS를 사용하여
클라이언트에서 로드 밸런서로 채널을 보호하도록 지시한다. 생성한
TLS 시크릿이 https-example.foo.com 의 정규화 된 도메인 이름(FQDN)이라고
하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다.
참고: 가능한 모든 하위 도메인에 대해 인증서가 발급되어야 하기 때문에
TLS는 기본 규칙에서 작동하지 않는다. 따라서
tls 섹션의 hosts는 rules섹션의 host와 명시적으로 일치해야
한다.
참고: TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
차이가 있다. 사용자 환경에서의 TLS의 작동 방식을 이해하려면
nginx,
GCE 또는 기타
플랫폼의 특정 인그레스 컨트롤러에 대한 설명서를 참조한다.
로드 밸런싱
인그레스 컨트롤러는 로드 밸런싱 알고리즘, 백엔드 가중치 구성표 등
모든 인그레스에 적용되는 일부 로드 밸런싱
정책 설정으로 부트스트랩된다. 보다 진보된 로드 밸런싱 개념
(예: 지속적인 세션, 동적 가중치)은 아직 인그레스를 통해
노출되지 않는다. 대신 서비스에 사용되는 로드 밸런서를 통해 이러한 기능을
얻을 수 있다.
또한, 헬스 체크를 인그레스를 통해 직접 노출되지 않더라도, 쿠버네티스에는
준비 상태 프로브와
같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이
있다는 점도 주목할 가치가 있다. 컨트롤러 별
설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(예:
nginx, 또는
GCE).
인그레스 업데이트
기존 인그레스를 업데이트해서 새 호스트를 추가하려면, 리소스를 편집해서 호스트를 업데이트 할 수 있다.
kubectl describe ingress test
Name: test
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
Rules:
Host Path Backends
---- ---- --------
foo.bar.com
/foo service1:80 (10.8.0.90:80)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 35s loadbalancer-controller default/test
서비스 내부 트래픽 정책 을 사용하면 내부 트래픽 제한이 트래픽이 시작된
노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다.
여기서 "내부" 트래픽은 현재 클러스터의 파드로부터 시작된 트래픽을 지칭한다.
이를 통해 비용을 절감하고 성능을 개선할 수 있다.
서비스 내부 트래픽 정책 사용
ServiceInternalTrafficPolicy기능 게이트는
베타 기능이며 기본적으로 활성화되어 있다.
이 기능이 활성화되어 있으면,
서비스의
.spec.internalTrafficPolicy를 Local로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다.
이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다.
참고: 지정된 서비스에 대한 엔드포인트가 없는 노드의 파드인 경우에
서비스는 다른 노드에 엔드포인트가 있더라도 엔드포인트가 없는 것처럼 작동한다.
(이 노드의 파드에 대해서)
다음 예제는 서비스의 .spec.internalTrafficPolicy를 Local로
설정하는 것을 보여 준다:
kube-proxy는 spec.internalTrafficPolicy 의 설정에 따라서 라우팅되는
엔드포인트를 필터링한다.
이것을 Local로 설정하면, 노드 내부 엔드포인트만 고려한다.
이 설정이 Cluster이거나 누락되었다면 모든 엔드포인트를 고려한다.
기능 게이트의
ServiceInternalTrafficPolicy를 활성화한다면, spec.internalTrafficPolicy는 기본값 "Cluster"로 설정된다.
제약조건
같은 서비스에서 externalTrafficPolicy 가 Local로 설정된 경우
서비스 내부 트래픽 정책이 사용되지 않는다.
클러스터에서 동일하지 않은 다른 서비스에서 이 두 가지 기능은 동시에 사용할 수 있다.
엔드포인트슬라이스 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
대안을 제안한다.
사용동기
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
간단하고 직접적인 방법을 제공한다. 불행하게도 쿠버네티스 클러스터와
서비스가 더 많은 수의 백엔드 파드로
더 많은 트래픽을 처리하고 전송하는 방향으로 성장함에 따라, 이 API의 한계가 더욱 눈에 띄게
되었다.
특히나, 많은 수의 네트워크 엔드포인트로 확장하는 것에
어려움이 있었다.
이후로 서비스에 대한 모든 네트워크 엔드포인트가 단일 엔드포인트
리소스에 저장되기 때문에 엔드포인트 리소스가 상당히 커질 수 있다. 이것은 쿠버네티스
구성요소 (특히 마스터 컨트롤 플레인)의 성능에 영향을 미쳤고
엔드포인트가 변경될 때 상당한 양의 네트워크 트래픽과 처리를 초래했다.
엔드포인트슬라이스는 이러한 문제를 완화하고 토폴로지 라우팅과
같은 추가 기능을 위한 확장 가능한 플랫폼을 제공한다.
엔드포인트슬라이스 리소스
쿠버네티스에서 엔드포인트슬라이스는 일련의 네트워크 엔드포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 컨트롤 플레인은 자동으로
엔드포인트슬라이스를 생성한다. 이 엔드포인트슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트슬라이스는
프로토콜, 포트 번호 및 서비스 이름의 고유한 조합을 통해 네트워크 엔드포인트를
그룹화한다.
엔드포인트슬라이스 오브젝트의 이름은 유효한
DNS 서브도메인 이름이어야 한다.
예를 들어, 여기에 example 쿠버네티스 서비스를 위한 엔드포인트슬라이스
리소스 샘플이 있다.
기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
갖도록 엔드포인트슬라이스를
생성하고 관리한다. --max-endpoints-per-slicekube-controller-manager
플래그를 사용하여, 최대 1000개까지 구성할 수 있다.
엔드포인트슬라이스는 내부 트래픽을 라우트하는 방법에 대해
kube-proxy에
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
주소 유형
엔드포인트슬라이스는 다음 주소 유형을 지원한다.
IPv4
IPv6
FQDN (전체 주소 도메인 이름)
조건
엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
조건은 준비, 제공 및 종료 세 가지가 있다.
준비
ready는 파드의 Ready 조건에 매핑되는 조건이다. Ready 조건이 True로 설정된 실행 중인 파드는
이 엔드포인트슬라이스 조건도 true로 설정되어야 한다. 호환성의
이유로, 파드가 종료될 때 ready는 절대 true가 되면 안 된다. 컨슈머는 serving 조건을 참조하여
파드 종료 준비 상태(readiness)를 검사해야 한다.
이 규칙의 유일한 예외는 spec.publishNotReadyAddresses가 true로 설정된 서비스이다.
이러한 서비스의 엔드 포인트는 항상 ready조건이 true로 설정된다.
제공(Serving)
FEATURE STATE:Kubernetes v1.20 [alpha]
serving은 종료 상태를 고려하지 않는다는 점을 제외하면 ready 조건과 동일하다.
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
이 조건을 확인해야 한다.
참고:serving은 ready와 거의 동일하지만 ready의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
엔드포인트를 종료하기 위해 ready가 true 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다.
역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
이러한 이유로 ready는 엔드포인트 종료를 위해 alwaysfalse이며,
클라이언트가 ready에 대한 기존 의미와 관계없이 파드 종료 준비 상태를
추적 할 수 있도록 v1.20에 새로운 조건 serving이 추가되었다.
종료(Terminating)
FEATURE STATE:Kubernetes v1.20 [alpha]
종료(Terminating)는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
토폴로지 정보
엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다.
토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및
영역에 대한 정보가 포함된다. 엔드포인트슬라이스의 다음의 엔드 포인트별
필드에서 사용할 수 있다.
*nodeName - 이 엔드 포인트가 있는 노드의 이름이다.
*zone - 이 엔드 포인트가 있는 영역이다.
참고:
v1 API에서는, 전용 필드 nodeName 및 zone 을 위해 엔드 포인트별
topology 가 효과적으로 제거되었다.
EndpointSlice 리소스의 endpoint 필드에 임의의 토폴로지 필드를
설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
v1 API는 개별 nodeName 및 zone 필드 설정을 지원한다. 이러한
필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
v1beta1 API의 topology 필드에 있는 "topology.kubernetes.io/zone"
키 값은 v1 API의 zone 필드로 접근할 수 있다.
관리
대부분의 경우, 컨트롤 플레인(특히, 엔드포인트슬라이스
컨트롤러)는
엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가
엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이
엔드포인트슬라이스에 대한 다양한 다른 유스케이스가 있다.
여러 엔티티가 서로 간섭하지 않고 엔드포인트슬라이스를
관리할 수 있도록 쿠버네티스는 엔드포인트슬라이스를 관리하는
엔티티를 나타내는 endpointslice.kubernetes.io/managed-by레이블을
정의한다.
엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로
endpointslice-controller.k8s.io 를 설정한다. 엔드포인트슬라이스를
관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다.
소유권
대부분의 유스케이스에서, 엔드포인트슬라이스 오브젝트가 엔드포인트를
추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자
참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는
kubernetes.io/service-name 레이블로 표시된다.
엔드포인트슬라이스 미러링
경우에 따라, 애플리케이션이 사용자 지정 엔드포인트 리소스를 생성한다. 이러한
애플리케이션이 엔드포인트와 엔드포인트슬라이스 리소스에 동시에 쓸 필요가 없도록
클러스터의 컨트롤 플레인은 대부분의 엔드포인트 리소스를
해당 엔드포인트슬라이스에 미러링한다.
컨트롤 플레인은 다음을 제외하고 엔드포인트 리소스를 미러링한다.
엔드포인트 리소스에는 endpointslice.kubernetes.io/skip-mirror 레이블이
true 로 설정되어 있다.
엔드포인트 리소스에는 control-plane.alpha.kubernetes.io/leader
어노테이션이 있다.
해당 서비스 리소스가 존재하지 않는다.
해당 서비스 리소스에 nil이 아닌 셀렉터가 있다.
개별 엔드포인트 리소스는 여러 엔드포인트슬라이스로 변환될 수 있다.
엔드포인트 리소스에 여러 하위 집합이 있거나 여러 IP 제품군(IPv4 및 IPv6)이 있는
엔드포인트가 포함된 경우 변환이 일어난다. 하위 집합 당 최대 1000개의 주소가
엔드포인트슬라이스에 미러링된다.
엔드포인트슬라이스의 배포
각 엔드포인트슬라이스에는 리소스 내에 모든 엔드포인트가 적용되는
포트 집합이 있다. 서비스에 알려진 포트를 사용하는 경우 파드는
동일하게 알려진 포트에 대해 다른 대상 포트 번호로 끝날 수 있으며 다른
엔드포인트슬라이스가 필요하다. 이는 하위 집합이 엔드포인트와 그룹화하는
방식의 논리와 유사하다.
컨트롤 플레인은 엔드포인트슬라이스를 최대한 채우려고 노력하지만,
적극적으로 재조정하지는 않는다. 로직은 매우 직관적이다.
기존 엔드포인트슬라이스에 대해 반복적으로, 더 이상 필요하지 않는 엔드포인트를
제거하고 변경에 의해 일치하는 엔드포인트를 업데이트 한다.
첫 번째 단계에서 수정된 엔드포인트슬라이스를 반복해서
필요한 새 엔드포인트로 채운다.
추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은
슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다.
중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다
엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가
10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의
엔드포인트슬라이스가 있는 경우, 이 방법은 기존 엔드포인트슬라이스
2개를 채우는 대신에 새 엔드포인트슬라이스를 생성한다. 다른 말로, 단일
엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다.
각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면,
엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기
때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가
가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는
변경 횟수를 의도적으로 제한하기 위한 것이다.
실제로는, 이러한 이상적이지 않은 분배는 드물 것이다. 엔드포인트슬라이스
컨트롤러에서 처리하는 대부분의 변경 내용은 기존 엔드포인트슬라이스에
적합할 정도로 적고, 그렇지 않은 경우 새 엔드포인트슬라이스가
필요할 수 있다. 디플로이먼트의 롤링 업데이트도 모든 파드와 해당
교체되는 엔드포인트에 대해서 엔드포인트슬라이스를
자연스럽게 재포장한다.
중복 엔드포인트
엔드포인트슬라이스 변경의 특성으로 인해, 엔드포인트는 동시에 둘 이상의
엔드포인트슬라이스에 표시될 수 있다. 이는 다른 엔드포인트슬라이스 오브젝트에
대한 변경 사항이 다른 시간에서의 쿠버네티스 클라이언트 워치(watch)/캐시에
도착할 수 있기 때문에 자연스럽게 발생한다. 엔드포인트슬라이스를 사용하는 구현은
엔드포인트가 둘 이상의 슬라이스에 표시되도록 할 수 있어야 한다. 엔드포인트
중복 제거를 수행하는 방법에 대한 레퍼런스 구현은 kube-proxy 의
EndpointSliceCache 구현에서 찾을 수 있다.
토폴로지 인지 힌트(Topology Aware Hints) 는 클라이언트가 엔드포인트를 어떻게 사용해야 하는지에 대한 제안을 포함시킴으로써
토폴로지 인지 라우팅을 가능하게 한다.
이러한 접근은 엔드포인트슬라이스(EndpointSlice) 및 엔드포인트(Endpoint) 오브젝트의 소비자(consumer)가 이용할 수 있는 메타데이터를 추가하며,
이를 통해 해당 네트워크 엔드포인트로의 트래픽이 근원지에 더 가깝게 라우트될 수 있다.
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
인접성을 고려하여 트래픽을 라우트할 수 있다.
동기(motivation)
쿠버네티스 클러스터가 멀티-존(multi-zone) 환경에 배포되는 일이 점점 많아지고 있다.
토폴로지 인지 힌트 는 트래픽이 발생한 존 내에서 트래픽을 유지하도록 처리하는 메커니즘을 제공한다.
이러한 개념은 보통 "토폴로지 인지 라우팅"이라고 부른다.
서비스의 엔드포인트를 계산할 때,
엔드포인트슬라이스 컨트롤러는 각 엔드포인트의 토폴로지(지역(region) 및 존)를 고려하여,
엔드포인트가 특정 존에 할당되도록 힌트 필드를 채운다.
그러면 kube-proxy와 같은
클러스터 구성 요소는 해당 힌트를 인식하고,
(토폴로지 상 가까운 엔드포인트를 사용하도록) 트래픽 라우팅 구성에 활용한다.
토폴로지 인지 힌트 사용하기
service.kubernetes.io/topology-aware-hints 어노테이션을 auto로 설정하여
서비스에 대한 토폴로지 인지 힌트를 활성화할 수 있다.
이는 엔드포인트슬라이스 컨트롤러가 안전하다고 판단되는 경우 토폴로지 힌트를 설정하도록 지시하는 것이다.
명심할 점은, 이를 수행한다고 해서 힌트가 항상 설정되는 것은 아니라는 것이다.
동작 방법
이 기능을 동작시키는 요소는
엔드포인트슬라이스 컨트롤러와 kube-proxy 두 구성요소로 나눠져 있다.
이 섹션에서는 각 구성요소가 어떻게 이 기능을 동작시키는지에 대한 고차원 개요를 제공한다.
엔드포인트슬라이스 컨트롤러
엔드포인트슬라이스 컨트롤러는 이 기능이 활성화되어 있을 때
엔드포인트슬라이스에 힌트를 설정하는 일을 담당한다.
컨트롤러는 각 존에 일정 비율의 엔드포인트를 할당한다.
이 비율은 해당 존에 있는 노드의
할당 가능한(allocatable) CPU 코어에 의해 결정된다.
예를 들어, 한 존에 2 CPU 코어가 있고 다른 존에 1 CPU 코어만 있는 경우,
컨트롤러는 2 CPU 코어가 있는 존에 엔드포인트를 2배 할당할 것이다.
kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 힌트를 기반으로
자신이 라우팅하는 엔드포인트를 필터링한다.
대부분의 경우, 이는 kube-proxy가 동일 존 내에서 트래픽을 엔드포인트로 라우팅할 수 있음을 뜻한다.
때때로 컨트롤러는 존 사이에 보다 균등한 엔드포인트 분배를 위해 다른 존으로부터 엔드포인트를 할당하기도 한다.
이러한 경우 일부 트래픽은 다른 존으로 라우팅될 것이다.
보호 규칙
쿠버네티스 컨트롤 플레인과 각 노드의 kube-proxy는
토폴로지 인지 힌트를 사용하기 전에 몇 가지 보호 규칙을 적용한다.
이들이 만족되지 않으면, kube-proxy는 존에 상관없이
클러스터의 모든 곳으로부터 엔드포인트를 선택한다.
엔드포인트 수가 충분하지 않음: 존의 숫자보다 엔드포인트의 숫자가 적으면,
컨트롤러는 어떤 힌트도 할당하지 않을 것이다.
균형잡힌 할당이 불가능함: 일부 경우에, 존 간 균형잡힌 엔드포인트 할당이 불가능할 수 있다.
예를 들어, zone-a가 zone-b보다 2배 큰 상황에서,
엔드포인트가 2개 뿐이라면,
zone-a에 할당된 엔드포인트는 zone-b에 할당된 엔드포인트보다 2배의 트래픽을 수신할 것이다.
컨트롤러는 이 "예상 과부하" 값을 각 존에 대해
허용 가능한 임계값보다 작게 낮출 수 없는 경우에는 힌트를 할당하지 않는다.
명심할 점은, 이것이 실시간 피드백 기반이 아니라는 것이다.
개별 엔드포인트가 과부하 상태로 바뀔 가능성도 여전히 있다.
하나 이상의 노드에 대한 정보가 불충분함:topology.kubernetes.io/zone 레이블이 없는 노드가 있거나
할당 가능한 CPU 값을 보고하지 않는 노드가 있으면,
컨트롤 플레인은 토폴로지 인지 엔드포인트를 설정하지 않으며
이로 인해 kube-proxy는 존 별로 엔드포인트를 필터링하지 않는다.
하나 이상의 엔드포인트에 존 힌트가 없음: 이러한 상황이 발생하면,
kube-proxy는 토폴로지 인지 힌트로부터의 또는 토폴로지 인지 힌트로의 전환이 진행 중이라고 가정한다.
이 상태에서 서비스의 엔드포인트를 필터링하는 것은 위험할 수 있으므로
kube-proxy는 모든 엔드포인트를 사용하는 모드로 전환된다.
힌트에 존이 기재되지 않음: kube-proxy가 실행되고 있는 존을 향하는 힌트를 갖는 엔드포인트를
하나도 찾지 못했다면,
모든 존에서 오는 엔드포인트를 사용하는 모드로 전환된다.
이러한 경우는 기존에 있던 클러스터에 새로운 존을 추가하는 경우에 발생할 가능성이 가장 높다.
제약사항
토폴로지 인지 힌트는 서비스의 externalTrafficPolicy 또는
internalTrafficPolicy가 Local로 설정된 경우에는 사용되지 않는다.
동일 클러스터의 서로 다른 서비스들에 대해 두 기능 중 하나를 사용하는 것은 가능하며,
하나의 서비스에 두 기능 모두를 사용하는 것은 불가능하다.
이러한 접근 방법은 존의 일부분에서
많은 트래픽이 발생하는 서비스에는 잘 작동하지 않을 것이다.
대신, 들어오는 트래픽이
각 존 내 노드 용량에 대략 비례한다고 가정한다.
엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
준비되지 않은(unready) 노드는 무시한다.
이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다.
엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
톨러레이션은 고려하지 않는다.
서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우,
이러한 상황은 고려되지 않을 것이다.
오토스케일링 기능과는 잘 동작하지 않을 수 있다.
예를 들어, 하나의 존에서 많은 트래픽이 발생하는 경우,
해당 존에 할당된 엔드포인트만 트래픽을 처리하고 있을 것이다.
이로 인해 Horizontal Pod Autoscaler가
이 이벤트를 감지하지 못하거나,
또는 새롭게 추가되는 파드가 다른 존에 추가될 수 있다.
IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 클러스터의 특정 애플리케이션에 대해 쿠버네티스 네트워크폴리시(NetworkPolicy) 사용을 고려할 수 있다. 네트워크폴리시는 파드가 네트워크 상의 다양한 네트워크 "엔티티"(여기서는 "엔티티"를 사용하여 쿠버네티스에서 특별한 의미로 사용되는 "엔드포인트" 및 "서비스"와 같은 일반적인 용어가 중의적으로 표현되는 것을 방지함)와 통신할 수 있도록 허용하는 방법을 지정할 수 있는 애플리케이션 중심 구조이다. 네트워크폴리시는 한쪽 또는 양쪽 종단이 파드인 연결에만 적용되며, 다른 연결에는 관여하지 않는다.
파드가 통신할 수 있는 엔티티는 다음 3개의 식별자 조합을 통해 식별된다.
허용되는 다른 파드(예외: 파드는 자신에 대한 접근을 차단할 수 없음)
허용되는 네임스페이스
IP 블록(예외: 파드 또는 노드의 IP 주소와 관계없이 파드가 실행 중인 노드와의 트래픽은 항상 허용됨)
pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, 셀렉터를 사용하여 셀렉터와 일치하는 파드와 주고받는 트래픽을 지정한다.
한편, IP 기반의 네트워크폴리시가 생성되면, IP 블록(CIDR 범위)을 기반으로 정책을 정의한다.
전제 조건
네트워크 정책은 네트워크 플러그인으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다.
파드 격리의 두 가지 종류
파드 격리에는 이그레스에 대한 격리와 인그레스에 대한 격리의 두 가지 종류가 있다. 이들은 어떤 연결이 성립될지에 대해 관여한다. 여기서 "격리"는 절대적인 것이 아니라, "일부 제한이 적용됨"을 의미한다. 반대말인 "이그레스/인그레스에 대한 비격리"는 각 방향에 대해 제한이 적용되지 않음을 의미한다. 두 종류의 격리(또는 비격리)는 독립적으로 선언되며, 두 종류 모두 파드 간 연결과 연관된다.
기본적으로, 파드는 이그레스에 대해 비격리되어 있다. 즉, 모든 아웃바운드 연결이 허용된다. 해당 파드에 적용되면서 policyTypes에 "Egress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 이그레스에 대해 격리된다. 이러한 정책은 파드의 이그레스에 적용된다고 말한다. 파드가 이그레스에 대해 격리되면, 파드에서 나가는 연결 중에서 파드의 이그레스에 적용된 NetworkPolicy의 egress 리스트에 허용된 연결만이 허용된다. egress 리스트 각 항목의 효과는 합산되어 적용된다.
기본적으로, 파드는 인그레스에 대해 비격리되어 있다. 즉, 모든 인바운드 연결이 허용된다. 해당 파드에 적용되면서 policyTypes에 "Ingress"가 있는 NetworkPolicy가 존재하는 경우, 파드가 인그레스에 대해 격리된다. 이러한 정책은 파드의 인그레스에 적용된다고 말한다. 파드가 인그레스에 대해 격리되면, 파드로 들어오는 연결 중에서 파드의 인그레스에 적용된 NetworkPolicy의 ingress 리스트에 허용된 연결만이 허용된다. ingress 리스트 각 항목의 효과는 합산되어 적용된다.
네트워크 폴리시가 충돌하는 경우는 없다. 네트워크 폴리시는 합산되어 적용된다. 특정 파드의 특정 방향에 대해 하나 또는 여러 개의 폴리시가 적용되면, 해당 파드의 해당 방향에 대해 허용된 연결은 모든 폴리시가 허용하는 연결의 합집합이다. 따라서, 판별 순서는 폴리시 결과에 영향을 미치지 않는다.
송신 파드에서 수신 파드로의 연결이 허용되기 위해서는, 송신 파드의 이그레스 폴리시와 수신 파드의 인그레스 폴리시가 해당 연결을 허용해야 한다. 만약 어느 한 쪽이라도 해당 연결을 허용하지 않으면, 연결이 되지 않을 것이다.
참고: 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
필수 필드들: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는
apiVersion, kind, 그리고 metadata 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는
컨피그 맵을 사용해서 컨테이너 구성하기,
그리고 오브젝트 관리 를 본다.
spec: 네트워크폴리시 사양에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
podSelector: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 podSelector 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 podSelector 는 네임스페이스의 모든 파드를 선택한다.
policyTypes: 각 네트워크폴리시에는 Ingress, Egress 또는 두 가지 모두를 포함할 수 있는 policyTypes 목록이 포함된다. policyTypes 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 policyTypes 가 지정되어 있지 않으면 기본적으로 Ingress 가 항상 설정되고, 네트워크폴리시에 Egress 가 있으면 이그레스 규칙이 설정된다.
ingress: 각 네트워크폴리시에는 화이트리스트 ingress 규칙 목록이 포함될 수 있다. 각 규칙은 from 과 ports 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 ipBlock 을 통해 지정되고, 두 번째는 namespaceSelector 를 통해 그리고 세 번째는 podSelector 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
egress: 각 네트워크폴리시에는 화이트리스트 egress 규칙이 포함될 수 있다. 각 규칙은 to 와 ports 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 10.0.0.0/24 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
따라서 예시의 네트워크폴리시는 다음과 같이 동작한다.
인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우).
(인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.
"role=frontend" 레이블이 있는 "default" 네임스페이스의 모든 파드
네임스페이스와 "project=myproject" 를 레이블로 가지는 모든 파드
172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외)
(이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다.
from 배열에 두 개의 요소가 포함되어 있으며, 로컬 네임스페이스에 레이블을 role=client 로 가지는 파드 또는 네임스페이스에 레이블을 user=alice 로 가지는 파드의 연결을 허용한다.
의심스러운 경우, kubectl describe 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다.
ipBlock: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에
발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자,
서비스 구현 등의 조합에 따라 동작이 다를 수 있다.
인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을
필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는
"소스 IP"는 LoadBalancer 또는 파드가 속한 노드 등의 IP일 수 있다.
이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 서비스 IP로의 연결은
ipBlock 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다.
기본 정책
기본적으로 네임스페이스 정책이 없으면 해당 네임스페이스의 파드에 대한 모든 인그레스와 이그레스 트래픽이 허용된다. 다음 예시에서는 해당 네임스페이스의 기본 동작을
변경할 수 있다.
기본적으로 모든 인그레스 트래픽 거부
모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 인그레스 격리 정책을 생성할 수 있다.
이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
SCTP 지원
FEATURE STATE:Kubernetes v1.20 [stable]
안정된 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 --feature-gates=SCTPSupport=false,… 를 사용해서 SCTPSupport기능 게이트를 비활성화해야 한다.
해당 기능 게이트가 활성화되어 있는 경우, 네트워크폴리시의 protocol 필드를 SCTP로 지정할 수 있다.
참고: SCTP 프로토콜 네트워크폴리시를 지원하는 CNI 플러그인을 사용하고 있어야 한다.
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우,
네임스페이스 default 에 레이블이 role=db 인 모든 파드가
TCP를 통해 10.0.0.0/24 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
베타 기능으로, 기본적으로 활성화되어 있다.
클러스터 수준에서 endPort 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가
API 서버에 대해 --feature-gates=NetworkPolicyEndPort=false,… 명령을 이용하여
NetworkPolicyEndPort기능 게이트를 비활성화해야 한다.
endPort 필드는 port 필드보다 크거나 같아야 한다.
endPort 는 port 도 정의된 경우에만 정의할 수 있다.
두 포트 모두 숫자여야 한다.
참고: 클러스터가 네트워크폴리시 명세의 endPort 필드를 지원하는
CNI 플러그인을 사용해야 한다.
만약 네트워크 플러그인이
endPort 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면,
그 정책은 port 필드에만 적용될 것이다.
이름으로 네임스페이스 지정
FEATURE STATE:Kubernetes 1.21 [beta]
쿠버네티스 컨트롤 플레인은 NamespaceDefaultLabelName기능 게이트가 활성화된 경우
모든 네임스페이스에 변경할 수 없는(immutable) 레이블 kubernetes.io/metadata.name 을 설정한다.
레이블의 값은 네임스페이스 이름이다.
네트워크폴리시는 일부 오브젝트 필드가 있는 이름으로 네임스페이스를 대상으로 지정할 수 없지만, 표준화된 레이블을 사용하여
특정 네임스페이스를 대상으로 지정할 수 있다.
네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
쿠버네티스 1.23부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다.
내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음).
TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용).
노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음).
이름으로 서비스를 타겟팅한다(그러나, 레이블로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임).
타사 공급사가 이행한 "정책 요청"의 생성 또는 관리.
모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음).
고급 정책 쿼리 및 도달 가능성 도구.
네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결).
명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음).
루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음).
--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6 IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다.
kube-proxy:
--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>
kubelet:
--cloud-provider가 명시되지 않았다면
관리자는 해당 노드에 듀얼 스택 .status.addresses를 수동으로 설정하기 위해
쉼표로 구분된 IP 주소 쌍을 --node-ip 플래그로 전달할 수 있다.
해당 노드의 파드가 HostNetwork 모드로 실행된다면,
파드는 이 IP 주소들을 자신의 .status.podIPs 필드에 보고한다.
노드의 모든 podIPs는 해당 노드의 .status.addresses 필드에 의해 정의된
IP 패밀리 선호사항을 만족한다.
참고:
IPv4 CIDR의 예: 10.244.0.0/16 (자신의 주소 범위를 제공하더라도)
IPv6 CIDR의 예: fdXY:IJKL:MNOP:15::/64 (이 형식으로 표시되지만, 유효한 주소는 아니다 - RFC 4193을 본다.)
서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (--service-cluster-ip-range 플래그를 통해 kube-apiserver에 구성)
서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 .spec.ipFamilyPolicy 필드를
다음 값 중 하나로 설정한다.
SingleStack: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
PreferDualStack:
서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다.
RequireDualStack: IPv4 및 IPv6 주소 범위 모두에서 서비스 .spec.ClusterIPs를 할당한다.
.spec.ipFamilies 배열의 첫 번째 요소의 주소 계열을 기반으로 .spec.ClusterIPs 목록에서 .spec.ClusterIP를 선택한다.
단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 .spec.ipFamilies를 설정하여 주소 군을 선택할 수 있다.
참고:.spec.ipFamilies 필드는 이미 존재하는 서비스에 .spec.ClusterIP를 재할당할 수 없기 때문에 변경할 수 없다. .spec.ipFamilies를 변경하려면 서비스를 삭제하고 다시 생성한다.
.spec.ipFamilies를 다음 배열 값 중 하나로 설정할 수 있다.
["IPv4"]
["IPv6"]
["IPv4","IPv6"] (이중 스택)
["IPv6","IPv4"] (이중 스택)
나열한 첫 번째 군은 레거시.spec.ClusterIP 필드에 사용된다.
이중 스택 서비스 구성 시나리오
이 예제는 다양한 이중 스택 서비스 구성 시나리오의 동작을 보여준다.
새로운 서비스에 대한 이중 스택 옵션
이 서비스 사양은 .spec.ipFamilyPolicy를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 service-cluster-ip-range에서 서비스에 대한 클러스터 IP를 할당하고 .spec.ipFamilyPolicy를 SingleStack으로 설정한다. (셀렉터가 없는 서비스 및 헤드리스 서비스와 같은 방식으로 동작한다.)
이 서비스 사양은 .spec.ipFamilyPolicy에 PreferDualStack을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 .spec을 업데이트하여 IP 주소 할당을 기록한다. 필드 .spec.ClusterIPs는 기본 필드이며 할당된 IP 주소를 모두 포함한다. .spec.ClusterIP는 값이 .spec.ClusterIPs에서 계산된 보조 필드이다.
.spec.ClusterIP 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
단일 스택 클러스터에서 .spec.ClusterIPs 및 .spec.ClusterIP 필드는 모두 하나의 주소만 나열한다.
이중 스택이 활성화된 클러스터에서 .spec.ipFamilyPolicy에 RequireDualStack을 지정하면 PreferDualStack과 동일하게 작동한다.
이 서비스 사양은 .spec.ipFamilies에 IPv6과 IPv4를 명시적으로 정의하고 .spec.ipFamilyPolicy에 PreferDualStack을 정의한다. 쿠버네티스가 .spec.ClusterIPs에 IPv6 및 IPv4 주소를 할당할 때 .spec.ClusterIP는 .spec.ClusterIPs 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.
이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.)
클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (IPv4 또는 IPv6)는 컨트롤 플레인이 .spec.ipFamilyPolicy를 SingleStack으로 지정하고 .spec.ipFamilies를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 .spec.ClusterIPs에 저장한다.
클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 헤드리스 서비스는 .spec.ClusterIP가 None이라도 컨트롤 플레인이 .spec.ipFamilyPolicy을 SingleStack으로 지정하고 .spec.ipFamilies는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 --service-cluster-ip-range 플래그를 통해 구성)의 주소 계열으로 지정한다.
서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 .spec.ipFamilyPolicy를 SingleStack에서 PreferDualStack 또는 RequireDualStack으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
.spec.ipFamilyPolicy를 SingleStack에서 PreferDualStack으로 업데이트하는 서비스 사양을 편집한다.
이전:
spec:ipFamilyPolicy:SingleStack
이후:
spec:ipFamilyPolicy:PreferDualStack
서비스를 이중 스택에서 단일 스택으로 변경하려면 .spec.ipFamilyPolicy를 PreferDualStack에서 또는 RequireDualStack을 SingleStack으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 .spec.ClusterIPs 배열의 첫 번째 요소 만 유지하고 .spec.ClusterIP를 해당 IP 주소로 설정하고 .spec.ipFamilies를 .spec.ClusterIPs의 주소 계열로 설정한다.
셀렉터가 없는 헤드리스 서비스
셀렉터가 없는 서비스 및 .spec.ipFamilyPolicy가 명시적으로 설정되지 않은 경우 .spec.ipFamilyPolicy 필드의 기본값은 RequireDualStack 이다.
로드밸런서 서비스 유형
서비스에 이중 스택 로드밸런서를 프로비저닝하려면
.spec.type 필드를 LoadBalancer로 설정
.spec.ipFamilyPolicy 필드를 PreferDualStack 또는 RequireDualStack으로 설정
참고: 이중 스택 LoadBalancer 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
이그레스(Egress) 트래픽
비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. ip-masq-agent 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
