Istio 구성요소 및 기능

• Istio 동작 원리를 이해한다.

구성요소

Control Plane

Pilot

• envoy에 대한 설정 관리
• 서비스 디스커버리 기능 제공(서비스들의 엔드포인트들의 주소를 얻을 수 있는 기능)
• 서비스에서 서비스로 호출하는 경로를 컨트롤
• retry, Circuit breaker, Timeout등의 기능 제공

Mixer

• 액세스 컨트롤, 정책 통제 그리고 모니터링 지표 수집
• 서비스의 총 처리량 이상으로 요청을 못받게 하거나 특정 헤더값이 일치해야 요청을 받을 수 있게 하는 등의 다양한 정책을 정의 및 컨트롤 가능
• 서비스의 응답시간, 평균 처리량 등 지표 수집 및 저장

Citadel

• 보안에 관련된 기능을 담당하는 모듈
• 사용자 인증(Authentication)과 인가(Authorization)를 담당
• pod간 통신을 TLS 암호화를 위한 인증서 관리 역할 수행

Data plane

envoy proxy

• 서비스 옆에 붙여서 사이드 카 형식으로 배포
• evoy는 서비스들의 IP 주소를 컨트롤 플레인의 Pilot 컴포넌트를 통해 확인(service discovery)

기능

트래픽 제어(Traffic control)

• 트래픽 분할: canary test(새로 배포된 버전에 10% 기존 버전에 90% 식의 Test)
• 컨텐츠 기반 트래픽 분할: 패킷 내용(HTTP header의 User-agent 필드에 따라, Client 모델)에 따라 라우팅 가능

서비스 안정성(Resilience)

• health check: 대상 서비스가 여러개의 pod로 구성되어있으면 이를 로드밸런싱하고, 서비스에 대해서 주기적으로 상태 체크를 하고 장애가 나면 자동으로 서비스에서 제거한다.
• 서비스 디스커버리: 서비스의 위치를 pilot을 통해서 ip를 알아냄
• Retry, Timeout, Circuit breaker: 서비스간의 호출 안정성을 위해서 재시도 횟수를 통제할 수 있다. 일정시간 이상 응답이 오지 않으면 에러처리를 할 수 있고 Circuit breaker패턴을 지원

보안

• 통신보안: envoy를 통해서 통신하는 모든 트래픽을 자동으로 TLS를 이용해서 암호화한다. 서비스간 통신이 디폴트로 암호화 된다.(citadel)
• 서비스 인증과 인가: 서비스에 대한 인증을 제공, 서비스와 클라이언트를 직접 인증할 수 있다.
• 서비스간 인증: 서비스간 인증은 양방향 인증(Mutual TLS)을 이용하여 서비스가 서로를 식별하고 인증
• 서비스와 사용자간 인증: 엔드유저 즉 사용자 Client를 JWT 토큰을 이용해서 서비스에 접근할 수 있는 Client를 인증할 수 있다.
• 인가를 통한 권한 통제: 서비스 접근 권한 통제 가능, 사용자나 서비스는 각각 사용자 계정이나 쿠버네티스 서비스 어카운트로 계정이 정의되고 각각 Role을 부여해서 역할 기반 서비스 접근 제어를 할 수 잇다.

모니터링

• 서비스간 호출 시 트래픽은 envoy 프록시를 통하게 되고, 응답 시간과 서비스의 처리량이 Mixer로 전달
• 전달된 Mixer의 logging backend에 저장됨
• Mixer의 logging backend: 플러긴형태로 가능(Bluemix, stackdriver, aws, prometheus, heapster, datadog ... )

1. kubernetes 구성 module 요약

1.1 All Node

1.1.1 kubelet

• 모든 노드에서 Daemon으로 동작
• kube-apiserver로부터 명령을 받아 OCI Runtime Spec을 준수하는 Container Runtime을 통해 Pod를 제어
• (대표적인 Container Runtime으로 containerd가 있다.)
• CNI plugin을 통해서 생성한 Pod의 Network를 설정하는 역할도 수행
• MasterNode의 kubelet은 kube-apiserver, kube-controller-manager, kube-scheduler pod를 관리하는 역할도 수행

1.1.2. kube-proxy

• kubernetes의 Service를 cluster 내부나 외부에 노출시킬 수 있도록 proxy server역할 수행
• iptables 또는 ipvs를 제어하는 역할1.1.3. network daemon
• kube-apiserver로부터 정보를 얻어와 pod사이에 통신이 가능하도록 Node의 network를 설정
• host network namespace에서 동작하고 network 설정을 변경할 수 있는 권한을 갖고 있기 때문에 node의 network 설정을 자유롭게 변경할 수 있다.
• CNI plugin에 따라 network daemon이 결정
  • flannel의 flanneld, calico의 calio-felix, cilium의 cilium-agent가 network daemon임

1.2. Master Node

Master Node는 Kubernetes Cluster를 관리하는 Node

1.2.1. etcd

• etcd는 분산 key-value storage로 kubernetes cluster관련 data를 저장
• master node가 다수일 경우 etcd cluster를 구성
• etcd cluster에서는 Raft 알고리즘을 통해서 유지됨
• data가 변경될 경우 해당 data를 감시하고 있는 client에게 data변경 event를 전달하는 watcher 기능을 제공
• watcher 기능을 이용하여 kubernetes cluster는 etcd cluster를 event bus처럼 이용하기도 함

1.2.2. kube-apiserver

• kubernetes를 제어하는 rest api server
• etcd와 통신하는 유일한 구성요소
• cluster 관련 data를 저장하거나 etcd의 data 변경 event를 수신하기 위해서는 kube-api서버를 이용해야함
• kubernetes 대부분의 구성요소가 kube-apiserver와 통신함

1.2.3. kube-controller-manager

• Object: Pod, Deployments, Statefulset, Configmap 등이 kubernetes에서 정의한 Object
• kube-controller-manager는 이러한 controller들을 관리한다.
• kube-apiserver를 통해서 제어하려는 Object의 상태정보를 얻어거나 Object를 제어한다.

1.3. Worker Node

사용자가 배포한 Application이 동작하는 NodeQ

1.3.1. coredns:

• pod안에서 다른 pod의 ip를 찾을 수 있는 DNS 역할을 수행
• service ip도 언제든 바뀔 수 있기 때문에 -> pod안에서 service ip를 찾을 수 있게 함

1.3.2. CNI(Container Network interface) Plugin

• pod의 Network를 설정할 때 이용함

2. Terms

• OCI Runtime Spec
• Container Runtime

3. Furder works