1. Kubernetes Service & Network
Kubernetes Service
-
CLUSTER IP : 클러스터 내부 통신을 위한 서비스. 하나의 가상 ip를 이용하여 연결된 파드에 대해 로드밸런싱해준다
- 로드 밸런싱 기법은 kubeproxy가 userspace mode라면 라운드로빈, iptables 모드라면 랜덤 인 unweighted 라운드로빈, ipvs면 사용자가 설정한 방식으로 해준다
-
NODE PORT : Clusterip의 확장판으로 워커 노드의 포트를 사용하여 외부와 통신 할 수 있게 해주는 서비스. 워커 노드 포트에 트래픽이 들어오면 서비스를 거쳐서 파드에 접속된다
- Nodeport의 단점은 노드의 ip와 포트를 이용하기에 노드에 고장이 나면 접근을 할 수 없는 문제가 일어난다는 점이다
-
LOAD BALANCER : NODE PORT의 확장판으로 로드밸런서를 통해 파드가 외부와 통신할 수 있게 해준다. 외부 로드밸런서에 트래픽이 들어오면 서비스를 통해 파드로 트래픽이 전달된다
-
EXTERNAL NAME : 외부에서 접근하기 위한 용도가 아닌, 외부의 특정 FQDN에 대한 CNAME 매핑을 제공하기 위한 서비스이다. CORE DNS 서비스가 특정 FQDN에 대한 CNAME을 제공하여 내부의 파드가 CNAME을 통해 외부의 특정 FQDN에 접근하기 위한 서비스
- FQDN은 FULL QUALITIED DOMAIN NAME으로 호스트와 도메인을 함께 명시한 주소이다. WWW.GOOGLE.COM이 있으면 WWW가 호스트이고 GOOGLE.COM이 도메인이다
- CNAME 레코드는 도메인과 IP 주소를 매핑하는 A레코드와 다르게, 도메인 주소를 또 다른 도메인 주소와 매핑시키는 DNS 레코드 타입이다
- EXTERNAL NAME 서비스의 NAME이 CNAME이며, 안에 명시한 externalName이 외부 FQDN 이다. 특정 파드와 매칭하는 것이 아닌, 단순히 외부 주소에 대한 CNAME을 제공하는 것
Kubernetes Network
- 노드의 eth0와 파드 및 서비스의 인터페이스 사이에 cbr0 bridge가 존재한다. cbr0는 default 게이트웨이 역할을 한다
- 쿠버네티스는 각 노드의 bridge의 네트워크 대역이 겹치지 않게 주소 대역을 할당한다. 그 다음 게이트웨이 라우팅 테이블을 설정해서, 어떤 패킷이 어떤 브릿지로 가야하는지 설정한다. ( 이런 가상 브릿지와 라우팅 규칙의 조합 = 오버레이 네트워크 )
- 언더레이 네트워크 : 실제 네트워크 장비, 보안 장비, 서버등을 이용하여 구축한 물리적인 네트워크 인프라.
- 오버레이 네트워크: 물리적인 인프라를 기반으로 네트워크 가상화 기술을 통해 end to end 통신을 구현하는 기술. 오버레이 네트워크가 아래 언더레이 네트워크에 영향을 주지 않으며, 분할된 네트워크에 자원을 할당하여 네트우크 자원 효율성을 높일 수 잇다. 또한, 네트워크 구성시 암호화 알고리즘을 적용하여 높은 보안성을 지닐 수 있다 ( vlan , vxlan )
- IP 네트워크는 보통 자신의 HOST에서 목적지에 대한 주소를 못찾으면, 상위 게이트웨이로 전달한다. 쿠버네티스도 POD 의 VETH → CBR0 → ETH0 순으로 올라가는데, KUBE PROXY를 이용해 다른 노드의 파드와 통신할 수 있게 해준다
- KUBEPROXY를 통해 다른 노드의 서비스 IP를 요청하면, 해당 서비스에 연결된 파드의 IP를 목적지로 설정해준다
Kubernetes Network Policy
- 쿠버네티스에서는 network policy 기능을 통해 파드의 방화벽을 설정할 수 있다. network policy 안에는 들어오는 트래픽에 대한 설정인 ingress 와 나가는 트래픽에 대한 설정인 egress가 있다. 파드 선택은 파드 셀렉터를 이용하여 라벨을 통해 선택한다
2. NETFILTER & IPTABLES
KubeProxy에 대해 알아보기 전에, KubeProxy가 사용하는 리눅스 네트워크 기능인 Netfilter 와 Iptables에 대해 알아보자
NETFILTER & IPTABLES 개념
Userspace의 iptables를 통해 netfilter에 rule을 추가하면, Kernelspace의 netfilter는 해당 rule을 바탕으로 패킷을 모니터링하고 처리한다
-
NETFILTER : KERNEL SPACE에 위치하며, 패킷을 모니터링하고 조작 및 처리하는 RULE BASED 패킷 처리 엔진이다. 규칙에 매핑되는 패킷을 발견하면, 정의된 동작을 수행한다. KERNEL SPACE에 존재하는 PROXY라고 볼 수 있다
-
IPTABLES : netfilter에 rule을 추가할 수 잇는 userspace 실행 프로그램으로 특정 조건에 부합하는 패킷을 드랍하거나, 패킷의 출발지 혹은 목적지 주소를 변경하기 위해 사용
IPTABLES의 TABLE
-
Iptables는 'Netfilter의 Hook을 표현하는 Chain'과 '룰을 관리하기 위한 Table'을 이용하여 Netfilter에 등록된 룰을 관리한다
- 룰들은 기능에 따라 구분되어 Table에 놓여진다
- Table은 특수한 목적을 지니고 있으며, Table 안에서 룰들은 chain으로 묶여서 관리된다. 미리 설정한 rule에 match 되지 않은 패킷은 설정에 따라 accept 혹은 drop 된다
-
Table에는 패킷을 목적지에 보내거나, 요청을 거부하는데 사용하는 filter Table, Nat를 위한 Nat Table, Ip 헤더를 변경하는 Mangle Table, 특정 packet이 Connection Tracking에서 제외되도록 설저하는 raw Table, SELinux에서 packet을 어떻게 처리할지 결정하기 위한 security Table이 있다
- Connection Tracking : 이전에 도착한 packet을 이용해 이후에 도착한 packer의 Connection을 추적하는 방법.
- Iptable은 Connection Tracking 을 이용하여 내부 네트워크 상 서비스 연결 사태에 따라 해당 연결을 감시하고, 제한할 수 있게 해준다. 상태에 기반한 연결 추적 기능이기에 어느 네트워크 프로토콜에서나 사용 가능하며, 상태를 저장하지 않는 UDP에서도 사용 가능하다
Chain 종류
-
prerouting : 패킷의 목적지 주소를 변경 ( dnat ) - nf ip pre routing hook에 의해 트리거
-
postrouting : 패킷의 출발지 주소를 변경 ( snat or masquerade ) - nf ip post routing hook에 의해 트리거
-
output : 호스트에서 밖으로 흐르는 패킷의 목적지 주소 변경 - nf ip local out hook에 의해 트리거
-
input : 밖에서 호스트로 흐르는 패킷의 출발지 주소 변경 - nf ip local in hook 에 의해 트리거
-
forward : 패킷이 다른 호스트로 포워딩 될 경우, 해당 호스트로 라우팅 되도혹 함 - nf ip forward hook에 의해 트리거
Netfilter & Iptables 사용 이유
-
서비스는 쿠버네티스의 리소스로 실제 장치가 존재하지는 않는다. 우리는 존재하지도 않는 장치를 이용해 통신을 할 수는 없는데, 이를 해결한게 쿠버네티스의 USERSPACE의 iptables 기능과 kernelspace의 netfilter 기능이다
-
쿠버네티스에서 파드간 통신에 호스트 인터페이스나 파드 인터페이스를 사용할 수 있지만, 노드나 파드가 쉽게 교체될 수 있는 쿠버네티스 환경에서는 불안정적이다. 따라서 NETFILTER와 IPTABLES 기능이 필요하다
- 파드1에서 노드2의 파드2에 대해 트래픽을 보낼때, 파드2의 주소가 라우팅 테이블에 설정되어 바로 보낼 수 있지만, 파드의 VIP가 언제나 바뀔 수 있기에 문제가 생길 수 있다. 따라서 KUBEPROXY가 새로운 파드나 Cluster ip가 생기면, 동작중인 노드의 iptables에 rule을 추가한다
3. KubeProxy
출처 : https://velog.io/@squarebird/Kubernetes-Networking-2.-Service#kube-proxy
KubeProxy란
-
Kube Proxy는 각 Node마다 DaemonSet Controller가 관리하는 Pod로 존재하며, Kubernetes에서 네트워크 동작을 관리하는 컴포넌트이다
-
Kube Proxy는 Linux의 Netfilter와 Iptables를 이용해 서비스가 가지고 있는 Virtual Ip로 트래픽을 전달할 수 있게 해주며, 클러스터 내부 Ip 로 연결하려는 요청을 포워딩과 로드밸런싱을 통해 적절한 파드로 전달해주는 프록시 및 로드밸런서 역할을 하는 컴포넌트이다
- 트래픽이 Service Port로 들어오면, KubeProxy는 Pod로 트래픽을 전달한다
- 파드간 통신이나, 서비스를 이용한 통신에서 실질적인 조작을 해주는 것은 KubeProxy이다
- Node Port에서 Service를 통해 Port를 노출할 때, 해당 Port를 Listen하는 역할을 담당
KubeProxy 안정성
-
kube proxy가 userspace mode라면 단일 실패점 문제가 발생할 수 잇지만, iptabels나 ipvs 모드에서는 트래픽 전달에 직접 관여하지 않고 netfilter를 통해 동작하기에 노드가 살아있는 한 안정적이다
-
kubeproxy는 api server로부터 정보를 수신 받아 iptabels를 업데이트하여 netfilter 규칙을 최신화한다. 이때 health check는 kubelet이 하며, check한 정보를 통한 적절한 삭제 및 추가 요청을 apiserver를 통해 proxy에게 전달한다. 이를 통해 트래픽을 안정적으로 전달해줄 수 있다
4. KubeProxy Mode
USERSPACE MODE
- 쿠버네티스 초기에 기본으로 사용되었던 모드로, 대부분의 네트워크 작업을 kube proxy가 직접 수행한다
Network 준비 단계
-
kubeproxy는 apiserver와 통신하며 클러스터의 파드와 서비스 오브젝트의 생성과 삭제를 모니터링한다
-
서비스가 생성되면 서비스별로 노드의 Port를 열어야 한다. 따라서 kube proxy는 서비스의 가상 ip에 대해 노드의 랜덤한 Port와 목적지 Pod를 연결시킨다. 이후, 서비스의 cluster ip와 Port에 매칭되는 트래픽을 모두 kube proxy로 포워딩되게 iptable을 설정한다
네트워킹 과정
-
클라이언트가 cluster ip를 향해 request
-
node의 iptable에 설정으로 생성된 netfilter chain에 적용
-
chain에는 cluster ip와 port간의 매칭 목록이 있다. kube proxy로 트래픽을 전달하기 위해 목적지를 Hostip & 해당 포트로 변경
-
해당 목적지 주소로 접근하면, 요청이 kube proxy로 전달
-
kube proxy가 포트 번호를 확인하고, 매치되는 실제 pod로 패킷 전달
로드밸런싱
-
라운드 로빈 방식을 사용
-
만약, SessionAffinity 설정이 되어있다면, 설정한 파드에 우선적으로 전달되게 함 ( 특정 파드에 지속적으로 연결이 되게 하는 설정 )
단점
- kubeproxy는 프로세스로 동작하므로 user space에 있다. 네트워킹 동작을 위해 userspace에서 kernel에 접근해야 하기에, kernel 자체 서비스보다 속도가 느리다. userspace mode에서 네트워킹 작업을 주로 userspace에 있는 kubeproxy가 하기에 네트워킹 속도가 저하된다
IPTABLES 모드
- 쿠버네티스 1.19.2 버전부터 기본값이 되는 모드로, KUBE PROXY가 트래픽을 받지않고, IPTABLES만 관리하며, 트래픽 전달은 netfilter가 담당한다
Network 준비 단계
-
kube proxy는 apiserver와 통신하며 서비스 오브젝트 / 파드 생성 및 삭제를 모니터링
-
서비스가 생성되면, kubeproxy는 iptable의 설정에 서비스와 연결된 파드 정보를 기록한 netfilter chain 생성
네트워킹 과정
-
CLIENT가 CLUSTER IP로 패킷 보냄
-
노드의 IPTABLE 설정에 따라 NETFILTER로 들어옴
-
NETFILTER CHAIN RULE에 따라 정해진 POD 로 전송
로드밸런싱
- 랜덤 방식을 사용
장점
- 모든 네트워크 작업을 netfilter / iptables 를 통해 수행하므로 userspace mode보다 빠른 성능을 가지며, 커널 기능인 netfiletr를 통해 동작하기에 노드가 살아있는 한 계속 동작하여 userspace보다 안정성이 높다
단점
-
USERSPACE MODE는 pod에 대한 트래픽 전송을 kubeproxy가 하기에 파드가 응답하지 않으면, 다른 파드에 재시도하지만, iptable 모드에서는 재시도하지않으므로, readness probe와 같은 설정이 필요
-
로드밸런싱 알고리즘이 랜덤이다
Ipvs 모드
-
Ipvs ( IP Virtual Server ) 모드에서는 L4 로드밸런서인 IPVS 기술을 이용한다. 해쉬 테이블인 IPVS 테이블을 사용하기에 IPTABLES모드보다 빠르고 좋은 성능을 제공하며, 다양한 로드밸런싱 알고리즘을 지원한다
- IPSET : IPTABLE의 확장 기능으로 IP들의 집합을 별도로 만들어 관리할 수 있으며, 많은 IP 집합을 설정해도 성능이 많이 떨어지지 않는 장점이 있다
- IPVS : NETFILTER 기반으로 구현된 4계층 로드밸런싱 도구로 다양한 로드밸런싱 방식을 지원하며, 해쉬테이블인 IPVS 테이블을 사용하므로 처리 속도가 빠르다
- 해쉬 테이블 : 데이터를 KEY VALUE 형태로 저장하는 자료구조로 버킷을 사용하여 데이터를 저장하기에 빠른 검색 속도를 제공한다
-
해당 모드를 사용하기 위해서 커널에 IPVS 모듈을 설치해야 한다
Network 준비 단계
-
KUBE PROXY가 APISERVER와 통신하며 클러스터에 파드나 서비스가 생성 및 삭제되는지 모니터링
-
서비스가 생성되면 KUBE PROXY는 IPVS HASH TABLE에 서비스와 서비스와 매칭되는 파드 정보 기록
-
KUBE PROXY는 서비스와 관련된 트래픽을 IPVS에 전달하기 위해 IPSEC을 설정한다. 서비스 관련 패킷을 IPVS에 보내도록 CHAIN을 생성
네트워킹 과정
-
패킷이 노드의 IPTABLE의 설정에 따라 NETFILTER에 들어오면, NETFILTER CHAIN에 따라 IPVS에 전달된다
-
IPVS는 해쉬 테이블을 확인하고, Pod 로 패킷을 전달한다
로드밸런싱
기본값은 라운드 로빈이며, 사용자가 로드밸런싱 알고리즘을 설정할 수 있다
장점
- IPVC는 서버 헬스 체크와 연결 재시도를 지원한다
- IPTABLE 모드 보다 트래픽 리다이렉트 지연율이 낮으며, 성능이 높다
- 다양한 로드밸런싱 알고리즘을 지원한다
로드밸런싱 알고리즘
-
라운드 로빈 : 순차적으로 선택
-
WEIGHTED 라운드 로빈 : 가중치를 더해서 분산 비율을 변경한다
-
LEAST CONNECTION : 접속수가 가장 적은 서버 선택
-
WEIGHTED LEAST CONNECTION : 가중치를 주어 가중치가 높으면서 접속수가 낮은 서버를 우선 선택
-
SHORTEST EXPECTED DELAY : 응답속도가 가장 빠른 서버 선택
-
DESTINATION, SOURCE HASHING : 목적지 / 출발지 IP 주소를 기반으로 해시 함수를 통한 해시값을 계산하여 서버 선택
