KubeCon 2019 - Istio Multi-Cluster Service Mesh Patterns Explained

https://youtu.be/-zsThiLvYos

 

 

Multi cluster를 사용하는 이유는 여러 가지.

• Performance
• Cost (Dev for cheaper)
• Failover / Redundancy (Availability)

 

 

비즈니스적인 이유로도 멀티 클러스터를 요청하는 고객이 많았음.

• Secure Workload
• 외부 공격 방지 (attack vector)
• auditing of public internet traffic
• 기존 On-prem과 cloud 간 통신
• pod to pod, cluster to cluster 통신에서 데이터 Security

 

간단한 cluster configuration 예시

• 각 클러스터에는 worker node pool이 존재함. (VM / Bare Metal 무관)
  • edge pool만 public internet access가 가능함. 나머지는 private network로만 통신 가능.
  • back office cluster (private cluster) -> public internet으로 worker / master node에 접근 불가능. 예컨대 IBM kubernetes의 경우 private endpoint proxy로 통신.

---

istio : Programmable Network.

 

 

For Cloud Native, it goes well Beyond just kubernetes. Additional Capability가 필요함.

• Network / Security에서는 Kubernetes native 기능만으로는 한계가 있음.

 

 

예컨대 Service A에서 Service B로 request를 보낸다고 하면

• istio는 Application Pod에 Envoy proxy를 inject. -> at least 2 containers in a single pod
• istio Control plane에서 Envoy configuration을 관리함.
  • Galley -> istio configuration yaml 파일의 변경사항을 확인
  • Pilot -> istio configuration을 envoy configuration으로 변환, 적용해야 하는 envoy에 반영 (translate)

service A에서 service B로 통신하기 위해

• k8s에서는 kubeDNS에서 cluster IP lookup 수행.
• istio를 설치하면, 확인한 cluster IP 주소를 service B에 설치된 envoy proxy pod IP로 replace.
  • Mixer : istio policy 체크하면서 통신이 가능한지 확인. 발생하는 로그를 telemetry에 기록.

 

하지만 보통 istio 사용을 권유할 때 제일 먼저 강조하는 기능은 traffic management 같은 게 아니라 mTLS라고 함.

• pod to pod 통신에 TLS certificate 설정 / 관리 자동화.
  • microservice에서 통신 간 secure 처리하는 데 드는 overhead 줄여주는 의미가 큼

 

---

istio Multi-Cluster : 3 main Patterns

multi cluster 쓰는 사용자가 많아지면서 istio도 multi cluster를 위한 기능을 도입함.

1. Single Network, Single Control plane

 

Flat Network.

• Cluster 1: main cluster. entire istio control plane이 설치되어 있음.
• Cluster 2: istio 컴포넌트 중 필요한 것만 설치.

특징

• Cluster 1은 cluster 2의 kube API를 호출하기 위한 Secret 정보가 필요. (istio pilot이 cluster 2에는 없기 때문)
• cluster 1과 cluster 2는 Shared Network에서 동작해야 함.
  • 각 클러스터의 cluster IP range / pod IP range가 겹치면 안 되기 때문
  • gateway같은 거 없이 Direct routing하는 방식.

예컨대 cluster 1의 foo pod가 cluster 2의 bar pod에 요청을 보낸다고 할 때

• k8s DNS Lookup로 cluster IP 확인.
• Envoy에서 해당 request intercept -> cluster IP에서 실제 bar의 pod IP로 replace.
• envoy proxy가 직접 destination pod IP로 traffic routing.

장점

• Flat Network 환경.
• 물리적으로 가까운 클러스터 환경에서 적용하면 좋음. cluster 간 latency가 낮기 때문.

단점

• 설정하기 꽤 복잡함.
  • 예컨대 위 예시의 경우 cluster 2의 bar pod에서 cluster 1의 pilot으로 telemetry 정보를 보내야 한다.
  • 클러스터 간 direct IP통신이 많기 때문에, ip가 자주 바뀌거나 kubeAPI 호출을 위한 secret이 바뀌는 등의 이슈를 관리하기 위한 Management Plane이 필요.
  • Consistent Config management가 가능한 CI / CD 환경을 보유했을 경우 추천
• Network Isolation이 동작하지 않음. 결국 두 개의 클러스터를 하나처럼 사용하는 방식이므로.

---

2. Single Control Plane, Separate networks

 

• main cluster에는 모든 istio 컴포넌트 설치, remote cluster에는 필요한 것들만 설치.
• Separate IP range, remote cluster에 접근하려면 해당 클러스터의 Ingress gateway를 통과해야 함
  • ingress gateway는 label되어 있고, label이 클러스터를 구분하는 기준.
• pilot은 envoy API에서 제공하는 split Horizon EDS라는 걸 사용
  • Able to configure the routes, based on who's calling it.
• foo pod가 main cluster 서비스를 호출할 경우 local IP address로 라우팅, remote cluster로 호출할 경우 해당 클러스터의 ingress gateway로 라우팅.
  • remote cluster의 ingress gateway로 보내는 트래픽은 Encrypted. ingress gateway가 확인할 수 있는 SNI (server name indication) 정보 포함.
  • ingress gateway는 SNI 확인해서 destination pod로 routing.

장단점

CI / CD requirement가 약간 간소화된다는 것 외에는 single network / single control place과 비슷함.

• single istio control plane에서 발생하는 장단점은 동일
  • 하나의 istio dashboard로 멀티 클러스터 정보를 확인할 수 있는 방식 - kiali, grafana, prometheus.
• 차이점은 Flat network 여부.

---

3. Multiple Control Planes

 

independent cluster with full-blown istio - simpler to set up.

• config sharing 전혀 없음.
• cluster 1의 DNS + additional Endpoints.
  • cluster 2의 bar pod에 요청을 보내고 싶을 경우 bar..global 형태의 DNS로 호출
  • bar..global을 인식할 수 있도록 serviceEntry 생성. 요청은 cluster 2의 ingress gateway로 전달됨.

장점

• 설정이 어렵지 않음
• 상대 클러스터에 노출할 서비스를 serviceEntry object 설정만으로 지정할 수 있음.
• canary deployment / traffic management 등이 가능함.
• istio control plane이 클러스터마다 있으므로 앞선 두 개의 pattern에 비해 scale이 용이함
  • Common Root CA 설정하면 서로 다른 클러스터 간 통신에도 mTLS 적용 가능.

단점

• 여러 개의 control plane을 manage해야 함 - higher operational Cost

---

incoming / outgoing traffic