if kakao 2021 - k8s Cluster 확장, 어디까지 알아보고 오셨어요?

https://if.kakao.com/session/119

if(kakao)2021

 

Multi-IDC 구축하면서 SLA 확보하기 위한 시도들.

 

 

• 카카오페이는 현재 800여 개 이상의 microservice를 k8s에서 운영중.
• 장애가 날 만한 상황은 예방하기 + 안정적으로 운영 가능한 아키텍처 구축이 필요함.

 

 

k8s 운영 시 발생할 수 있는 위험요소들을 정리한 영역

• k8s cpu 관련 이슈 : limit / 쓰로틀링
  • 리눅스 커널 업데이트, pod 개수와 성능 보장 등
• istio 관련 이슈 - 카카오페이는 service mesh로 istio 쓰는가 보다
  • 프로토콜 선택 관련 이슈
  • citadel 인증서 기한 만료
  • envoy의 hot restart fail 이슈
    • hot restart: https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5
    • 트래픽 변경 없이 무중단 배포를 지원하는 envoy 기능을 말하는 것 같다

 

 

카카오페이의 SLA는 99.999%. 가용성을 높이기 위한 여러 방식 중, Single Point of Failure 해소를 위한 방법을 설명한다.

 

 

 

 

멀티 클러스터 구조.

• IDC마다 클러스터가 있고, 클러스터마다 VIP가 있음. 트래픽이 들어오면 각각의 클러스터로 분산되는 구조.

 

고민점

• 멀티 클러스터 -> 관리해야 할 포인트가 증가함
• 여러 클러스터에 배포된 서비스를 확인해야 함.

 

클러스터 관점

---

 

 

현재 NodeSelector / NodeTaint 기능으로 pod 스케줄링하고 있음.

• 노드 추가될 때마다 taint / labeling 필수. 수동으로 작업 시 누락되는 경우 종종 발생

 

 

Cluster Node 관리 : Nsync

1. Nsync Config Repo: 노드별 설정파일 관리.
   • host.yaml : 관리해야 할 노드 host 입력. (정규식 가능)
   • config.yaml : label / taint 값 추가. global 적용이 필요할 경우 all 하위에, 특정 노드에 적용해야 할 경우 해당 hostName 키값으로 정의. 우선순위는 특정 노드 specific 옵션 > global 옵션
   • cluster.yaml : k8s cluster 정보 입력. host.yaml과 cluster.yaml이 어느 클러스터에 적용되어야 하는지 확인하는 용도
2. Nsync가 주기적으로 모든 노드 스캔 -> 신규노드 발견 시 config repo 설정값으로 label / taint 적용함.

 

 

 

싱크 돌다가 적용해야 할 노드가 발견되면 깃허브 pr. 팀원이 승인 시 자동 적용

 

 

---

Service Resource 관리 : Resource Handler

 

• 서비스 리소스의 모니터링 / 관리
• 개발자에게 권한은 주되 human error는 방지하고 싶다

k8s에서도 리소스 쿼터나 limit rage로 일부 기능을 제공하지만, DB connection / 배포속도 조절 / 적정 heap 메모리 설정 등을 직접 관리할 목적으로 개발함.

 

Spinnaker CD에서 실행됨.

• 배포하기 전 resource check / sync 단계에서 resource handler를 실행함.

 

1. 노드의 가용자원 체크
2. 가용자원이 확인되면, 리소스 변경사항이 있는지 체크.
   1. 적정값이 이미 설정되어 있는 상태. 적정값에 미달하거나 초과할 경우, 실행유저가 관리자인지 체크
   2. 관리자일 경우 프로젝트 min / max 재설정
3. helm chart 동기화 수행
4. helm history에 이력이 저장됨

 

---

배포: Spinnaker Pipeline

 

• spinnaker의 병렬처리 기능 써서 여러 클러스터에 같은 이미지를 동시에 배포함.

 

---

서비스 관점

 

 

인증 / 권한제어

• 싱글 클러스터의 경우 오픈소스 Guard 사용해서 인증 / 인가처리 가능.
• 멀티클러스터의 경우, 확장되는 클러스터마다 RBAC 추가적으로 관리하기는 버거움
• AWS EKS의 경우 마스터 서버를 제어할 수 없기 때문에 Guard + Github으로 처리하기 어려움

-> 서비스 개발자 인증 / 권한 제어 기능의 통합이 필요했음

 

k8s 실시간 추적 시스템

클러스터에서 주요 상태변화가 발생했을 경우 알림 서비스 필요. 작업 과정을 실시간으로 알림받고 추적 가능해야 함

 

커뮤니케이션 비용 절감

800여 개의 마이크로서비스 + 8000여 개의 pod

• 멀티 클러스터로 몇 배씩 리소스 증가

 

-> 커뮤니케이션 비용 문제. 따라서 서비스 개발자에게 devops 쪽 작업을 처리할 수 있도록 일부 권한을 지원해서 자유도를 높여야 했음

 

AWS EKS 인증과정 통합

AWS EKS 사용할 경우, VPC 바뀌거나 신규 개발자가 들어올 때마다 위 작업을 반복해야 함

• eks 필수인증과정을 최소화

 

기타 불편한 점

Context Switch의 불편함. On-Prem과 EKS를 오고가면서 동일한 deployment를 수정하는... 작업을 영상으로 보여줌.

• 근데 진짜 이렇게 했었다고? kubectl edit으로...?

 

Hela - k8s API Proxy

 

1. kube config 설정하기
2. github인증 / 권한제어
3. 실제 k8s api proxy 접근
4. audit logging

 

사용자가 github 토큰을 입력하면, 멀티 클러스터의 정보를 담은 kube config 파일을 받을 수 있다.

 

인증 과정

1. hela로 요청하는 api의 bearer token으로 github token 넣어서 요청
2. git org에 등록된 멤버 정보 조회
3. hela Role-based Access Control 로 접근권한 확인 가능.
   1. k8s RBAC 참고해서 github에 활용할 수 있게 커스텀한 거라고 함. CRD인 거 같다

 

 

roles에 보면 http 메소드도 정의되어 있음. 위 예시는 kubectl patch로 리소스를 수정하는 명령어는 사용할 수 없는 권한을 의미함.

 

 

 

테스트케이스 있음.

• 특히 nginx-ingress controller / istio control plane처럼 중요도와 민감도 높은 컴포넌트 쪽에 공들였다고 함

 

• git PR -> 리포트를 html로 받을 수 있다고 함. 새로 추가된 권한 / 사전에 정의된 인증 권한에는 문제없는지 확인 가능.

 

k8s api proxy 로 멀티클러스터에 요청하기.

• 요청을 보내면, proxyRequest 정보와 clusterInfo 정보 파싱.
  • 멀티클러스터의 경우 타입, 이름, tls 등의 정보를 가지고 있음.
  • 이 정보로 Client 생성 -> 특정 k8s에 요청
  • 라우팅은 Domain-based routing 사용한다고 함. yaml로 정의되어 있음.

 

 

 

context switching 작업은 payctl이라는 인터프리터 cmd 개발해서 사용함.

 

 

 

 

• 작업 이력을 남기는 audit log. 중요 정보는 구조화해서 저장하며, 멀티클러스터의 작업이력을 실시간으로 확인할 수 있다.

 

• EFK stack으로 수집됨. kibana로 실시간 확인 가능.

 

 

 

앞으로도 할 게 많다.