https://if.kakao.com/session/119
if(kakao)2021
함께 나아가는 더 나은 세상
if.kakao.com
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
- Nsync Config Repo: 노드별 설정파일 관리.
- host.yaml : 관리해야 할 노드 host 입력. (정규식 가능)
- config.yaml : label / taint 값 추가. global 적용이 필요할 경우 all 하위에, 특정 노드에 적용해야 할 경우 해당 hostName 키값으로 정의. 우선순위는 특정 노드 specific 옵션 > global 옵션
- cluster.yaml : k8s cluster 정보 입력. host.yaml과 cluster.yaml이 어느 클러스터에 적용되어야 하는지 확인하는 용도
- 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를 실행함.
- 노드의 가용자원 체크
- 가용자원이 확인되면, 리소스 변경사항이 있는지 체크.
- 적정값이 이미 설정되어 있는 상태. 적정값에 미달하거나 초과할 경우, 실행유저가 관리자인지 체크
- 관리자일 경우 프로젝트 min / max 재설정
- helm chart 동기화 수행
- 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
- kube config 설정하기
- github인증 / 권한제어
- 실제 k8s api proxy 접근
- audit logging
사용자가 github 토큰을 입력하면, 멀티 클러스터의 정보를 담은 kube config 파일을 받을 수 있다.
인증 과정
- hela로 요청하는 api의 bearer token으로 github token 넣어서 요청
- git org에 등록된 멤버 정보 조회
- hela Role-based Access Control 로 접근권한 확인 가능.
- 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로 실시간 확인 가능.
앞으로도 할 게 많다.