Udemy CKA course 10. 쿠버네티스 클러스터 디자인 및 설치 (고려사항, 인프라 구조, 고가용성 설정 및 ETCD)

Certified Kubernetes Administrator (CKA) with Practice Tests (강의 링크, 레퍼런스 노트)

• 평소 강의 할인도 많이 하고, 연습문제도 풀어볼 수 있으니 실제 강의 수강을 추천
• 아래는 강의 내용 번역 및 정리본 (문제 시 댓글로 알려주세요)

쿠버네티스 클러스터 디자인

목적

• 교육용
  • 미니큐브, 혹은 단일 노드로 충분
• 개발 혹은 테스트
  • 단일 마스터와 여러 개의 워커를 가진 멀티 노드 클러스터
  • kubeadm을 활용해 빠른 프로비져닝 유리
• 운영환경 어플리케이션
  • 여러 개의 마스터 노드를 가진 멀티 노드 클러스터가 유리
  • Kubeadm, GCP, AWS 등 지원 가능한 플랫폼들 고려

클라우드 혹은 On-Premise 환경 여부

• on-premise 환경에서는 Kubeadm 사용
• GCP에서는 GKE
• AWS에서는 Kops
• Azure에서는 Azure Kubernetes Service (AKS)

워크로드

저장공간

• 고성능의 워크로드를 위해서는 SSD 지원 저장공간 고려
• 동시에 여러 개의 연결을 필요로 한다면 네트워크 기반 저장공간 고려
• 여러 Pod에 걸쳐 공유된 접근을 필요로 한다면 Persistent shared volumes 고려
• 특정 디스크 종류를 가진 노드에 라벨링
  • 노드 셀렉터를 활용해 특정 디스크 종류를 가진 노드에 어플리케이션을 할당

노드

• 가상 혹은 물리적 머신
• 최소 4개의 노드를 가지는 클러스터 (워크로드에 따라 다름)
• 마스터, 워커 노드 분리
  • 워크로드를 마스터 노드에 호스팅하지 않는 것이 좋음
  • ETCD 클러스터 노드를 분리하는 것도 필요할 수 있음
• Linux X86_64 아키텍처

추가 고려사항

• 워크로드의 양
• 워크로드의 종류 (웹, 데이터, 분석 등)
• 어플리케이션 자원 요구사항 (CPU, Memory 등)
• 트래픽 (트래픽이 많은지, 한 번에 몰리는지 등)

쿠버네티스 인프라 구조 선택

• 리눅스의 경우, 수동으로 쿠버네티스를 설치할 수도 있고 여러 자동 솔루션을 선택할 수도 있음
• 윈도우의 경우, 바이너리 파일이 지원되지 않아 가상 소프트웨어를 활용해 LinuxVM 설치해야 함
• 솔루션 종류
  • Minikube
    • 단일 노드 클러스터
    • 스스로 configuration을 가진 VM을 프로비져닝 (VM을 배포)
  • Kubeadm
    • 단일 혹은 멀티 노드 클러스터
    • configuration을 직접 함으로써 필요한 호스트를 프로비져닝해야 함 (VM이 준비되어야 함)
  • Turnkey Solution
    • VM 프로비져닝, 환경설정(Configuration)을 사용자가 직접 수행
    • 클러스터를 배포하기 위해 스크립트 사용
    • VM을 사용자가 직접 유지보수
    • e.g. AWS에서 KOPS 사용
    • e.g. OpenShift, Cloud Foundry Container Runtime, VMware Cloud PKS, Vegrant, ...
  • Hosted Solution (Managed Solution)
    • Kubernetes-As-A-Service
    • 솔루션 제공자가 VM 프로비져닝, 쿠버네티스 설치, VM 유지보수 등을 담당
    • e.g. Google Container Engine (GKE)
    • e.g. OpenShift Online, Azure Kubernetes Service, Amazon Elastic Container Service (EKS), ...

고가용성 설정 (Configure High Availability)

• 클러스터 내 모든 요소에 대해 중복을 허용 (e.g. 멀티 마스터 노드 등)
  • 실패가 발생할 시에도 어플리케이션이 제대로 동작하게끔
• 마스터 노드가 2개일 때 (=여러 개일 때)
  • API 서버
    • 로드 밸런서로 트래픽을 나누어 활성화된 API 서버에 각기 다른 트래픽을 보냄
    • 둘 다 활성화 상태
  • Controller Manager, Scheduler
    • 하나는 활성화, 하나는 대기 상태로 사용
    • kube-controller-manager --leader-elect true [옵션들]
    • kube-controller-manager endpoint에서 활성화, 대기 상태 결정 (번갈아 사용)
  • ETCD
    • stacked topology
      • 컨트롤플레인 노드 내에 ETCD가 위치
      • 셋업과 관리가 쉽고 더 적은 서버가 필요
      • 실패 시 위험
    • external ETCD topology
      • 컨트롤플레인 노드 외부에 ETCD가 위치
      • 덜 위험
      • 셋업이 어렵고 더 많은 서버가 필요

고가용성과 ETCD

• ETCD
  • 간단하고 안전하고 빠른 믿을 수 있는 분산 키-값 저장공간
• 1. 분산
  • 여러 서버에 데이터 저장공간을 분산하여 사용
• 2. 일관성
  • 데이터의 일관된 복사본이 모든 ETCD 인스턴스에서 동시에 읽기/쓰기 가능
  • 쓰기의 경우, 하나의 노드가 리더가 되고 다른 노드들은 팔로워가 됨
    • 리더가 변경된 데이터를 다른 노드들에 보냄
    • 리더를 뽑는 과정은 RAFT 알고리즘 사용
    • N개의 노드가 있을 때, N/2 + 1 (Quorum) 개의 노드에 쓰기가 되면 완료되었다고 여김
      • 만약 3개 중에 1개 노드가 다운되었다면, 나머지 2개에 쓰기가 진행되면 쓰기가 완료되었다고 여겨짐
      • 다운되었던 노드가 돌아오면 해당 노드에 대해 쓰기가 진행됨
    • N개의 인스턴스 - Quorum(or Majority) = Fault Tolerance
  • 클러스터를 나눌 때 홀수 개의 노드를 갖도록 나누는 것이 클러스터를 활성화 상태로 유지하는 데에 용이
    • 충분한 Fault Tolerance를 가질 수 있음
    • 최소 3개의 노드가 있어야 고가용성 셋업이라고 일컬음
• etcd.service
  • --intial-cluster-peer
    • ETCD 인스턴스의 주소를 알 수 있음
• ETCDCTL
  • export ETCDCTL_API=3
    • 기본 버전 2, 우리가 사용하는 버전은 3
  • etcdctl put name john
    • 키와 값을 저장
  • etcdctl get name
    • 키로 값을 조회
  • etcdctl get / --prefix --keys-only
    • 키만 조회