[if(kakao) 2020] 엔터프라이즈 환경에서의 ITSM을 고려한 Kubernetes 도입 Review

출처 : https://if.kakao.com/2020/session/118

if(kakao)2020

카카오에서의 쿠버네티스 활용 사례와 엔터프라이즈 환경에서 쿠버네티스를 도입할 때, 전사적 ITSM 관점에서 고려해야 하는 사항들에 대해서 공유합니다.

 

리뷰 포인트

1. 카카오에서의 Kubernetes 도입 사례
2. ITSM 을 고려한 Kubernetes 도입

 

 

 

카카오에서의 Kubernetes 도입 사례

• DKOS 플랫폼, 카카오의 Kubernetes as a Service
  
  • 클릭 몇 번으로 인프라와 Kubernetes 클러스터를 생성할 수 있는 플랫폼으로 카카오 크루들은 개인학습, 테스트, 서비스를 위해 나만의 Kubernetes 클러스터를 생성할 수 있다.
  • 카카오에서는 수 만 대의 서버에서 Kubernetes를 통해 수십 만 개의 컨테이너를 관리하고 있다.
• D2hub 플랫폼, 카카오의 Container Image Hub
  • 컨테이너 기반으로 지속적인 서비스를 하기 위해 컨테이너 이미지를 빌드해서 저장하고 배포하기 위한 플랫폼
  • Github에서 코드 변경 이벤트를 감지하여 컨테이너 이미지로 자동 빌드하고 빌드된 컨테이너 이미지를 배포 정책을 통해 다양한 멀티 클러스터에 자동으로 배포
• DKOS와 D2hub를 바탕으로 카카오톡 전체 시스템을 Kubernetes 기반으로 전환 

 

 

 

ITSM 을 고려한 Kubernetes 도입

• ITSM (IT Service Management) : IT 서비스를 계획/제공/운영/제어하는 조직에서 수행하는 활동 전체. 서버, 네트워크, 서비스 개발, 보안, 기획, 재무 등 모든 활동
  
  
• 전사적 관점에서 Kubernetes의 장점을 더 잘 활용하려면
  
  
  • Container 자원 대한 성능정보, 로깅 수집, 통합 관리 해야 함.
    
    
  • 서비스 환경에서는 개발자가 직접 앱에 대한 정의와 필요한 자원만 제출하면, 필요한 자원들을 Kubernetes가 조합하여 연결해주고 항상 선언하는 형상과 같은 형상을 유지할 수 있도록 관리할 수 있음. 서버, 스토리지, 로드밸런서까지 전부 Kubernetes가 생성하고 연결시키고 관리할 수 있음.
    
    
  • 배포된 컨테이너들의 형상을 실시간으로 모니터링 할 수 있음
    
    
  • Kubernetes는 선언한 자원들에 대한 Topology 정보(클러스터에서 어떤 트래픽을 어디로 라우팅하기 위해 필요한 정보)를 가지고 있음. 이 Topology 정보들을 공유하여 전사에서 활용할 수 있게 해야 함. 예를 들어 이 서버는 어떤 로드밸런서에 연결되어 있고 상태는 어떻고 무슨 앱이 어떤 도메인으로 어디 로드밸런서에 연결되어 서비스되고 있는 지를 배포를 통해 형상이 달라져도 실시간으로 전사에 공유할 수 있어야 함
    
    
  • Kubernetes에서 발생한 이벤트를 중앙 데이터 허브로 수집하면 전사에서 다양한 용도로 사용할 수 있음
    • 어플리케이션 설정 상태의 변경이나 인프라 구성정보의 변경사항에 대해 알려줄 수 있음
    • 이벤트를 기반으로 가용성 용량 보안관리를 자동화할 수 있음
    • 이벤트 엔진의 정책 로직 판단을 통해 Kubernetes 클러스터에 다시 피드백을 줌으로 써 이벤트 기반으로 노드 장애를 감지하고 장애 발생한 노드 만큼 새로운 노드를 신규 추가하여 사람의 개입없이 가용성과 용량 관리를 자동화 할 수 있음
  • CI/CD 파이프라인을 거친 작은 앱들이 컨테이너 형태로 패키징 되어 Helm Chart 등의 형태로 Saas로 설치 됨. 이 과정에서 생성되는 데이터들을 CMDB와 유기적으로 연결하면  어떤 클러스터에서 어떤 앱이 설치되어있고 버전은 얼마인지 구성 정보를 쉽게 관리할 수 있고 Kubernetes 클러스터에 설치된 Saas형태의 어플리케이션의 차트나 이미지 버전만 수정하는 것 만으로 서비스 중단없이 새로운 버전의 소프트웨어로 업그레이드 할 수 있다. 이런 데이터들을 CMDB를 통해 전사에 공유되면 라이센스 관리, 보안 관리, 버전 관리등 다양한 부서들의 기존 ITSM 활동들과 융합되어 시너지를 낼 수 있음 
    
    
  • Storage나 Loadbalancer와 같은 외부 물리 자원들은 Kubernetes가 Custom Resource를 정의하고 Custom Controller를 구현하여 외부 자원을 인식하고 관리할 수 있도록 통합해야 함
    
    
• Kubernetes를 활용한 ITMS
  • ITIL(IT Infrastructure Library) : ITSM을 효과적으로 달성하기 위한 실천 모델(모범 사례, Best Practice)을 담은 프레임워크로 서비스 설계, 서비스 전환, 서비스 운영 단계로 이루어져 있다.
    
    • 서비스 설계에 앞서 SLA(Service Level Agreement, 서비스 수준)를 세운다. 인프라 관점의 SLA보다 서비스 관점에서 SLA를 하는 것을 추천한다. 예를 들어 가용성은 99.99%(1년 중 53분 이하의 서비스 중단), 성능은 평균 응답시간 30ms, 용량은 상시 피크시의 4배 보유와 같이 서비스 수준을 정하는 것이다. (참고, 비용과 가용성은 트레이드 오프 관계이다.)
      
      
    • 서비스 설계
      • 가용성 관리
        • Kubernetes는 Master Node의 개수가 많을 수록 가용성이 높다. 보통 5대의 Master node로 Kubernetes를 구성하면 실 서비스용 가용성을 확보할 수 있다.
          
          
        • Kubernetes의 저장소인 etcd를 Master Node에 같이 설치하지 않고, 외부 분리하여 추가적인 가용성을 확보할 수 있다.
          
          
        • Master Node의 가용성 관리
          • $ kubectl get cs
            • cs(componentstatuses) 명령에 대한 응답으로 kube-api 동작 상태 확인 가능
            • 응답 상세 내용으로 kube-scheduler, kube-controller-manager, etcd의 상태 확인 가능
        • Worker Node의 가용성 관리
          • $ kubectl get nodes
          • node-problem-detector
          • Custom Node Condition 추가
          • Custom Event 추가
        • Pod의 가용성 관리
          • Pod는 Kubernetes에 의해 자동으로 관리된다.
          • 문제는 사용자도 모르게 Pod를 너무 잘 살려주기 때문에 Pod에 문제가 생겨 원하는 동작 생략해도 모르고 지나가는 경우가 있다.
      • 용량 관리
      • 연속성관리
      • 보안성관리
    • 서비스 전환
      • 변화 관리
      • 릴리즈 관리
      • 설정 관리
    • 서비스 운영
      • 장애관리
      • 문제관리
      • 요구수행
      • 조직
        • DevOps 조직 구성
          • 개발팀 = 운영팀
          • 모든 개발자가 Weekly On-call 참여
          • 장점
            • 서비스 품질이 올라감
            • 코드 품질이 올라감
            • 빠른 대응
      • 문화
        • Agile
          • On-call에서 발견된 이슈들을 다시 개발 요구사항에 반영
      • 프로세스
        • Automation First
          • 운영 업무의 발견(인지)에서 해결까지 이벤트 기반 자동화

 

마무리

kubernetes를 활용해 CICD 자동화, 모니터링, 재사용성, self-healing 등 유지보수성이 높은 ITMS 활동을 위한 시스템인것 같다.