티스토리 뷰







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 혹은 유사 인스턴스


댓글
댓글쓰기 폼