쿠버네티스 밋업(2018년 11월) 세션 내용 요약

Session1. Spinnaker on Kubernetes

• 해외에서 스피너커로 많이 발음
• Spinnaker
  • 넷플리에서 시작
  • 구글과 함께 오픈소스로 공개 후 관리
• 클라우드에서 Spinnaker
  • Inventory + Pipelines

핵심 기능

• Cluster

  • 쿠버네티스의 클러스터가 아닌 어플리케이션의 집합

• Deployment

  • 배포

• 멀티 클라우드

  • 대부분의 Public Cloud, Private Cloud 지원
    • 오픈스택은 V3 API 지원
  • 테라폼도 지원 예정

• 알림 기능

• 승인 기능

  • 관리자 판단 하에 수동으로 배포 진행할 수 있는 단계

• 딜리버리 영역의 대부분의 작업을 스피너커가 대신 해줌

• Chaos Monkey 오픈소스가 내장되어 있어서 카오스엔지니어링 지원

• 배포 전략

  • 블루/그린
  • 카나리
  • 롤링

커뮤니티

• Community.spinnaker.io가 활발

주요 마이크로서비스

• Clouddriver : 멀티 클라우드 관련
• Kayenta : 카나리 배포 분석 관련
  • 카나리 배포 시 배포 내용은 분석하는 것을 Spinnaker에서 제공
• Orca : 오케스트레이션 관련

CLI 도구

• Halyard
  • CLI 도구
  • kubectl과 같이 Spinnaker를 관리하기 위한 도구

Spinnaker on kubernetes

• Legacy(V1) 버전과 Maifest(V2) 버전이 지원됨
  • V1에서는 Spinnaker와 Kubernetes의 중복 용어들이 존재하여 혼란이 있었음
  • V2에서 개선
    • 파일로 형상 관리
    • 외부 저장소를 사용하여 관리 가능
    • 대부분 V2를 사용

젠킨스와 비교

• 젠킨스는 CI 도구
• Spinnaker는 클라우드 API를 직접 호출하기 떄문에 스크립팅 요소가 적음
• 빌드가 필요한 경우 Spinnaker에서 젠킨스를 호출해서 사용할 수 있음

Native 쿠버네티스와 비교

• 다양한 배포 전략
  • 승인 기능
  • 인프라 관리
  • 빠른 롤백 등
• Spinnaker를 관리해야하는 관리비용이 있음

파이프라인

• Stage : 워크플로우 단위
• 코드 커밋 -> docker hub에서 트리거 -> Spinnaker 웹 훅 -> 스테이징에 배포 -> QA 담당자가 테스트 후 승인 -> 라이브 배포
• 모니터링은 프로메테우스로

정리

• 단일 소스를 대상으로 신뢰성있는 배포를 위한 좋은 전략
• 실행에 대한 감사 기능
• 코드와 컨테이너 이미지 검증
• 베스트 전략 : Spinnaker + Jenkins + Packer + Helm + Terraform
• Redis에 성능저하가 발생하면 Spinnaker 전반적인 성능에 영향
  • 튜닝 포인트
• 모니터링에는 Datadog, Prometheus, Stackdriver
• 노드 로깅은 fluentd, ElasticStack
• 개발팀은 골든 이미지 생성, 운영팀이 Spinnaker를 통한 배포면 좋지 않을까

Session2. Chaos Engineering

클라우드 여정을 통해 배운 점

• 서비스 운영의 숙명 '장애'

  • 빨리 전파되고 늦게 복구 됨
  • 어디든 장애는 날 수 있음
  • 어떻게 빠르고 안전하게 복구 할 수 있는 가가 중요

• 많은 회사들의 장애 대응 히스토리 : github.com/danluu/post-mortems

• Jesse Robbins

  • 실제 서비스에서 장애가 발생하면 어떻게 복구가 되는가
  • 넷플릭스에서 2011년에 인프라를 위한 장애 대응 서비스 제안 - 카오스 몽키
    • 2008년에 데이터 센터 장애 발생 이후 클라우드로 이전 시작

• 넷플릭스의 마이크로서비스

  • ELB -> Zuul (API Gateway) -> 각 서비스로 전파
  • 마이크로서비스간 인터페이스 이슈 해결
    • Hystrix
      • Circuit Breaker
      • Fallback
      • 장애가 발생하면 조기에 Circuit Breaker가 차단하고 장애 확대를 방지
      • Circuit Breaker가 가동되면 미리 만들어진 응답 제공
    • Ribbon
      • Client Side Load Balancer
        • 서버의 부하 방지
    • Eureka
      • 서비스 디스커버리

Chaos Engineering 적용 방법

• 넷플릭스는 모든 인프라에 대한 실패를 가정하고 인프라를 운영
• 카오스 엔지니어링은 실제 서비스에 장애를 주입
  • 출시 전 테스트에서 드러나지 않은 아키텍처상의 문제를 직접 드러내는 것
• Chaos Monkey
  • 실제 서비스를 죽이면 어떤 현상이 발생할까를 테스트
• Chaos Gorilla
  • 가용 영역을 날려버리면 어떤 현상이 발생할까를 테스트
• Chaos Kong
  • 리전을 날려버리면 어떤현상이 발생할까를 테스트
• 장애 발생 방법
  • 애플리케이션 부하 테스트
  • …
• 카오스 엔지니어링의 목적은 문제를 만들려는 것은 아니고 문제를 해결하기 위한 것
• 넷플릭스에는 별도의 카오스팀이 존재
  • 카오스 엔지니어링에도 원칙이 있음
    • 폭발 반경 최소화 등
  • 책도 출간함
• 진행 과정
  • 정상 상태 : 실제 노말하게 운영되고 있는 상태
    • 노말하냐의 기준은 실제 비즈니스에서 산정되는 통계치를 기준으로 삼음
  • 가설 수립 : 장애가 나타날 수 있는 상황의 가설을 세움
  • 실험 디자인 : 어떤 시나리오로 테스트를 할 것인지를 계획하고 전파
    • 카나리 배포
  • 실험 결과 측정
    • 장애 감지 시간, 문제 인지 및 알림 시간, 사내 전파 시간, 자동 롤백 시작 시점, 복구되는 시간 등등
  • 문제점 수정
    • Post Mortems 및 오류 해결
• 전제 조건
  • 클라우드 환경
  • 마이크로서비스 환경
  • DevOps 문화

Kubernetes를 위한 카오스 도구

Kube Monkey

• Chaos Monkey와 의미가 동일
• Kube Monkey는 Kubernetes의 Pod들을 임의로 죽임
• Config 파일을 통해 전략을 설정
• Kube Monkey도 Kubernetes의 Deployment로 생성됨
• 데모
  • Redis Master/Slave 안정성 테스트
  • 운영 중인 Redis 클러스터를 Kube Monkey를 통해 주기적으로 랜덤하게 Terminate 시키는데 정상 운영이 되는 지를 확인

Istio

• 서비스메시 : 라이브러리 방식을 벗어나 경량 프록시로 비즈니스 로직과 내부 네트워크 분리
  • 서비스 구동 시 통신을 위한 Proxy를 함께 배포하고 서비스간 통신은 Proxy를 통해서만 수행 (사이드카)
    • Service Mesh Plane을 통해 Proxy 통신에 대한 데이터를 수집하고 관리
• Istio는 서비스 매시용 오픈소스
  • 마이크로 서비스의 서비스간 통신, 운영 및 배포 복잡성을 해결하기 위한 분산 서비스 관리 도구
    • 지능적 라우팅, 로드밸런싱
    • 언어 및 프레임워크 독립적인 복원성
• Proxy로 Envoy 오픈소스 사용
  • 다른 프록시를 사용해도 무관함
• 트래픽 관리
  • 서비스별로 로드 밸런싱 조절 가능
  • 트래픽 정책 설정으로 Circuit Breaker 역할 수행도 가능
  • Fault Injection 기능을 통해 카오스 엔지니어링
    • Timeout
    • HTTP Abort

그 외 오픈소스 도구

• Chaos Toolkit

• PowerfulSeal

• Gremlin

  • 카오스 엔지니어링 관련 가장 상품성 있는 제품을 만들고 있음

Session3. Kubernetes Calico

프로덕션에 필요한 요소

• 마스터
  • Calico
  • Etcd
    • Key-Value로 쿠버네티스의 모든 정보 저장
  • Kube-API
  • Kube-Scheduler
  • Kube-Controller
  • Kube-Proxy
  • kubelet
• 워커 노드
  • Calico
    • 쿠버네티스 네트워크 모듈
  • Nginx
    • Master 노드의 API와 밸런싱하게 통신하게 하기 위함
  • Kube-Proxy
  • Kubelet

쿠버네티스를 설치하는 방법

• kubespray

  • Ansible 기반
  • 사전 준비 작업 필요
    • swapoff
      • 네트워크가 안되거나 메모리가 부족하면 쿠버네티스는 관리할 수 없다고 판단하여 팟들을 죽임
      • 팟들이 갑자기 죽는 다면 노드 분산 필요
    • 패스워드 없이 sudo 권한을 사용 해야 한다던가, Ansible을 설치해야한다거나 등등
  • Ansible Inventory 파일을 샘플로 제공
    • 중요 파일
      • k8s-cluster.yml
        • 쿠버네티스에 관련된 설정 모음
      • etcd.yml
        • etcd는 메모리를 늘려놔야함 기본값이 적게 설정되어 있음
    • Inventory 내 그룹명들은 수정하면 안됨
  • Calico가 기본으로 설치됨
    • Mesh 형태로 구성
      • 따로 설정하지않으면 BGP 피어링을 기본으로 메시 구성
    • Mesh 구조는 노드가 50대 이내 일때만 사용 권장. 그 이후부터는 메시구조가 너무 복잡해짐
  • 관리용 Ansible playbook
    • cluster.yml
    • reset.yml
    • scale.yml
    • upgrade.yml

• CNI 선정 기준 중 하나는 네트워크 통신 방식

  • Calico는 iptables를 사용하는데 더 빠른 것을 원한다면 ipvs 기반의 CNI를 선택

• kubespray에 설정된 기본 설정 그대로 사용하는 것을 권장

  • 버전 정보 정도만 수정해서 사용

• local volume의 경우에는 파일시스템에 따라 생성 실패할 수도 있음 Pod 재생성하면 해결됨

Kubeadm vs kubespray

• kubeadm을 사용하면 각 노드마다 동일 설정 명령을 수행해야함
• 자동화를 위해서는 결국 Ansible을 사용해야하지 않을 까
• kubespray에서도 kubeadm 사용을 지원
  • 설정을 통해 쿠버네티스 설치 시 내부적으로 kubeadm을 사용

Tip

• kubespray 원본은 놔두고 동일 레벨에 사용자디렉토리 생성 후 참조할 yml 파일의 경로를 상대경로로 지정해서 사용
• 쿠버네티스 코드를 분석하고 중간에 로그를 삽입해서 디버깅 용도로 활용하고 있음
• CNI 플러그인을 체이닝 방식으로 여러가지를 연계해서 사용할 수는 있는데 굳이 써야하나 생각이 듬
  • Calico는 Network Policy 지정이 가능
  • 질문자 중에 Calico를 ipip 터널링을 위해 사용

Keyword

• BGP
• NAT outgoing
• ipipMode

SK 활용

• 오픈스택을 전부 컨테이너기반으로 전환

  • CI/CD
    • Jenkins, Rally/Tempest, Chaos Monkey
    • 마스터 노드에 Jenkins 마스터를 설치하고, 설정은 SAP에 안전하게 보관
    • Jenkins에서 Job을 실행하면 워커 노드에 Jenkins Slave가 생성되고 실행됨
  • OpenStack Container
    • Docker, Kolla

Session4. Serverless in K8S

• 서버리스란?
  • BaaS나 FaaS, 혹은 둘 다를 이용한 어플리케이션 아키텍처 설계 방법론
  • AWS의 대표적인 FaaS는 Lambda, BaaS는 S3, DynamoDB 등
• 사용자의 요청은 FaaS의 API Gateway를 거쳐 추상화된 Controller가 요청에 해당하는 Function을 실행하고, 필요 시 BaaS(내부 서비스나 데이터베이스)를 사용하여 응답을 사용자에게 반환

Serverless vs Serverless Functions vs FaaS

• Serverless는 사상
• Serverless Functions는 서버리스 사상으로 커스텀한 함수를 실행시킬 수 있도록 하는 것
• FaaS는 이러한 Serverless Functions를 각 클라우드 프로바이더가 각 환경에 적합한 서비스로 제공하는 것

MSA vs Serverless Functions

• 구분 짓기 애매
• MSA가 서비스 단위로 잘게 쪼갰다면 Serverless Functions는 더 잘게 쪼갬 (코드 조각)

서버리스 장점

• 저렴
• 서버 관리 불필요
• 확장성
• 작은 비즈니스에 유리
• 빠른 프로토타입

서버리스 단점

• 콜드 스타트
  • 첫 실행 시 컨테이너가 구동되는 시간이 필요
• Nano Service
  • 너무 잘개 쪼개져있어서 관리의 어려움
  • 안티패턴
• 서버리스도 서버가 있음
  • 사내에서 자체 구성하기 위해서는 서버리스 서비스를 제공하는 부서에서는 서버 관리가 필요
  • 클라우드 프로바이더가 제공하는 서비스는 서버 관리를 프로바이더에서 하기 때문에 서버리스라 할 수 있음

SK에서 활용

• Private FaaS를 위해 자체 구현
• 쿠버네티스 기반으로 구현
  • Fission 오픈소스
    • Serverless Functions Framework
    • CNCF에 등록된 오픈소스
    • 서버리스 출현이 근래이기 떄문에 대부분의 오픈소스가 인지도가 없었음
    • 콜드 부팅의 문제가 가장 적은 오픈소스를 선택
    • 함수를 생성/삭제/관리 할 수 있는 오픈소스
    • Fission Workflow 오픈소스
      • 너무 잘개 쪼개진 함수들의 관리가 어려운데 이를 묶어서 워크플로우를 생성해주는 프로젝트
  • Dispatch 오픈소스
    • 서버리스 프레임워크
    • Dispatch 위에 Fission이 올라가는 방식
• Private 할 필요가 없다면 퍼블릭 클라우드를 이용하는 것이 좋음
• 콜드 스타트 문제를 해결하기 위해 고생함
  • 프리웜을 수행하는 방식으로 해결
  • 요청 -> 런타임생성 -> 코드 설치 -> 의존성 설치 -> 함수 실행
  • Fission은 런타임생성까지 프리웜하는 것으로 콜드 스타트 개선
  • SK에서는 코드 설치까지 프리웜 진행
    • 코드 설치는 코드가 커밋되면 docker volume을 통해 실제 호스트에 동기화
  • 각 코드와 자원에 따른 컨테이너들을 미리 구동시켜놓고 재사용
    • 구동된 컨테이너는 콜드 스타트 문제 때문에 정해진 개수만큼은 풀로 관리
    • 함수 실행 요청이 끝나면 해당 함수에 대한 부분만 메모리에서 제거하는 방식으로 사용
    • 이전 코드로 인해 환경이 변경될 수 있는 위험 요소가 있음
      • 이를 위해 컨테이너를 재생성하는 전략이 필요
    • 사용자의 니즈에 따라 컨테이너 지속성이 필요한 경우를 선택적으로 할 수 있도록 함
      • 선택에 따라 주기적으로 컨테이너가 종료되거나 유지를 결정
    • Fission내에 이러한 재사용에 대한 설정을 위해 3가지 타입을 제공
• 사용자 코드에 따른 부하 관리
  • 사용자 코드에 부하를 줄만한 코드가 있는지 검사하는 것은 불가능
  • 이를 검증하기 위해 노드를 분리
    • 미리 정상 범위의 메트릭을 산정하고 이를 초과하는 컨테이너들을 별도 관리
  • Management Worker Node
    • nodeSelector 방식
      • Pod이 노드를 선택해서 들어감
  • Runtime Worker Node
    • Taint & tolerations 방식
    • 이 방식을 사용하여 부하 분산
• 부하 관리
  • Docker는 현재 상태 지표를 파일로 저장함
    • /sys/fs/cgroup
  • 파일의 정보를 기반으로 부하를 많이 먹고 있는 사용자의 컨테이너를 제한

Tip

• Helm의 업데이트 히스토리 관리가 어려워서 Helm은 Template를 생성하는 용도로만 사용하고 이를 통해 나온 yaml 파일을 kubectl apply 명령으로 실행
  • kubectl apply 명령은 히스토리 관리가 가능

Session5. Journey to Windows Kubernetes

• 쿠키워즈에서 게임서버는 리눅스, 운영 도구는 윈도우

Windows Kubernetes

• 기존의 쿠버네티스와 크게 다르지 않음
• 고성능의 IOCP를 사용할 수 있다는 장점
• 기존 레거시 시스템을 쿠버네티스 환경으로 전환하여 클러스터 관리를 편하게 할 수 있다는 장점
• 안정화까지는 다소 시간이 걸릴 것으로 예상 됨
  • Windows Server 2019에서 안정화 될 것으로 예상
• Windows Server VM 필요
• 설치과정이 네트워크 설정부터 각 종 raw level의 설정을 수동으로 했어야 했는데 Rancher를 사용하여 어느정도 자동화 가능
• Windows 10에서는 컨테이너 기술을 사용하려면 무조건 가상화 기술이 필요

HCS(Host Compute Service)

• 쿠버네티스는 Docker REST API로 컨테이너 관리
• Docker는 HCS와 HNS로 커뮤니케이션
• 윈도우에서 컨테이너를 구동한다는 것은 커널에 있는 HCS를 사용해서 구동한다는 것

HNS(Host Network Service)

• Windows에서 쿠버네티스를 사용할 때 팟마다 네트워크 인터페이스가 생성되어서 엄청나게 많은 네트워크가 생성되는 문제가 발생함
• 이러한 이슈를 해결하기 위해 한단계 상위의 네트워크를 구성하게 되었는데 이것이 HNS (잘 이해 못함)

그 외

• 윈도우 10과 윈도우 서버에서 구동되는 Docker는 다름
• Rancher를 사용하는 경우 CNI로 flannel을 권장.
  • linux와 windows가 다르게 구현되어 있음
• 컨테이너용 windows server os가 따로 있음
중첩 가상화를 사용할 수 있는 환경이 필요
• Azure : 3세대 VM 이상
• AWS: i3.baremetal 혹은 유사 인스턴스