Slipp) K8S 스터디1주차_개념 잡기 :: mightytedkim

회사에서 쿠버네티스를 사용하게 되서, 개념을 공부하고 있어요

책은 15단계로 배우는 도커와 쿠버네티스 (깔끔한 설명과 자연스러운 번역이 장점인 것같아요)

slipp스터디에서 9분과 함께 완독을 목표로 11월까지 달릴 예정입니다.

1장 도커와 쿠버네티스의 개요

책에서는 훨씬 자세하고 친절한 설명이 나와서, 나중에 복습할 용도로 요약했습니다.

쿠버네티스란

기본 개념과 장점에 대해서 알 수 있었어요. 곧 쿠버네티스도 백엔드 개발자가 모르면 안되는 기술이 될 것 같아요

• 정의
  1. 컨테이너화된 애플리케이션을 효율적으로 배포하고 운영하기 위해 설계된 오픈 소스 플랫폼
• 요약
  • 등장 배경
    1. 새로운 기능과 서비스를 빠르고 안정적으로 제공 필요
    2. 불변의 실행 환경(immutable infrastructure)이 필요
  • 특징
    1. 높은 유연성과 확장성 : 마이크로 서비스, 느슨한 결합 등
       1. 배포 계획에 맞춰 애플리케이션을 배포
       2. 가동 중인 앱을 스케일 업/다운
       3. 새로운 앱을 무정지로 업그레이드
    2. 고가용성과 성능 관리 : 서버 정지 시 앱 재배포 자동화, 높은 부하에서 자동 스케일 등
       1. 하드웨어 가동률 높여 자원 효율적 사용
    3. 다양한 환경 : 퍼블릭, 프라이빗, 멀티, 하이브리드 클라우드 + 온프렘

장점

1. 앱의 빈번한 출시 : 롤아웃, 롤백 기능 [디비의 롤백과 다름]
2. 무정지 서비스 : 응답 없는 컨테이너 재기동, k8s 클러스터 내 지정한 수만큼 컨테이너 실행
3. 규모 조정 : 초기에 낮은 비용으로 시작
4. 외부 서비스 연동 : db처럼 컨테이너화하기 힘든 서비스와 연동
5. 개발/운영 환경 분리 : 복수의 가상환경에 설정파일, 인증서, 비밀번호 등을 저장
6. 온프렘, 클라우드 : 인프라 복잡성 감추며, 일관된 인터페이스로 설계
7. 앱 중심 오케스트레이션 : yaml 파일을 기술하면, 환경 구성됨
8. 기술 표준 : 특정 기업 종속 x
9. 서버 가동률 높이기 : cpu 가동률 높게 유지하면서 안정적으로 서비스 제공

도커 컨테이너와의 관계

본격적인 설명 전에 도커와 쿠버네티스의 관계에 대해서 설명을 해줘요.

1. 컨테어너를 사용하는 이유
   1. 인프라 사용률 향상
   2. 빠른 기동 시간
   3. 불변의 실행 환경
2. VM에 비해 컨테이너는 더 가벼움
   1. 경량
   2. 빠른 기동
   3. 이식성 높음
3. 도커와 쿠버네티스의 관계(연동)
   1. 쿠버네티스는 도커를 컨테이너의 런타임 환경으로 사용
      1. 실행이 보증: 컨테이너를 위한 기술과 표준
         1. 리눅스 표준 규격(Linux Base Standard)
         2. 리눅스 ABI(Application Binary Interface)
   2. 컨테이너의 이미지를 보존하는 레스트리 -> 쿠버네티스에서 개발한 이미지 실행하는 중간 창고
   3. 컨테이너를 파드위에서 기동한다.

쿠버네티스의 기본

구성에 대해서 알려줘요

아키텍처

1. 마스터와 노드로 구성
   1. 마스터 : 목표 상태가 매니페스트 대로 유지되도록 오브젝트 제어
2. 쿠버네티스에 대한 조작은 모두 API로 이루어진다.
   1. Kubectl, manifest(yaml/json) 이용

계층구조

1. 클라이언트
2. 마스터
   1. 노드1
      1. 컨테이너1,2,3
   2. 노드2
      1. 컨테이너1,2

오브젝트

• 오브젝트
  1. 지정된 상태가 유지되도록 쿠버네티스에 의해 제어됨
  2. 메타데이터에 이름을 지정하고, Namespace의 kind 중에는 유일해야함

1. 파드 : 컨테이너 실행용 오브젝트
2. 서비스 : 파드와 클라이언트 연결
3. 컨트롤러 : 파드의 실행 제어
4. 워크로드 : 오브젝트의 카테고리
5. 컨테이너 : 파드 내에서 실행되야함
6. 설정: 설정값, 비밀번호 저장
7. 스토리지 : 퍼시스턴트 볼륨

오브젝트 상세

1. 파드
   • 컨테이너를 실행하는 최소 단위
     1. 파드는 IP 주소 가지며, 복수의 컨테이너 담을 수 있으며, 하나의 가상서버처럼 동작
     2. 일시적인 존재 : 쓰고 버리는 일시적인 방식으로 설계
        1. 하나의 파드에 속하는 모든 컨테이너들은 같은 노드에서 동작
           1. 커네티이너 재사용
              1. 파드의 IP,port 공유
              2. localhost 통신 가능
              3. 파드의 볼륨과 마운트 가능
        2. 컨테이너의 실행상태 관리
           1. 활성 프로브, 준비상태 프로브
        3. 초기화도 전용 컨테이너 실행
           1. 초기화 후 핵심 기능 수행하는 컨테이너 실행
        4. 기타
           1. kubectl get pods
              1. pending, running, succeeded, failed, unknown
           2. 종료처리
2. 클러스터 네트워크
3. 1. K8S 내부에서 사용되는 네트워크 2. 대표적인 오픈소스 네트워크 애드온 1. Flannel 1. L3네트워크를 노드 간 구축 2. 네트워킹 기능만 가지고 있고 접근제어는 X 2. Calico 1. 네트워킹 + 접근제어
4. 서비스
5. 1. 클라이언트의 요청을 파드에 전달하는 역할 2. 필요한 이유 1. 파드의 IP 주소는 기동할 때마다 바뀜(일시적) 2. 로드밸런서의 역할을 가짐 3. 내부 DNS에 서비스 이름이 등록되고, 클라이언트는 서비스 이름으로 IP를 획득 3. 기타 1. 대표IP, 부하분산, 이름해결, 환경 변수, 서비스 타입, 어피니티, 실렉터와 라벨
6. 컨트롤러
7. 1. 파드를 제어한다. 1. 파드에게 워크로드를 부여함 (적절한 컨트롤러 선택이 필요) 2. 워크로드 & 컨트롤러 1. 워크로드의 타입 1. 프론트엔더 처리, 백엔드 서비스, 배치작업, 클러스터의 시스템 2. 컨트롤러의 타입 1. 컨트롤러 : 다양한 워크로드를 처리하기 위해 파드를 제어하고 실행하는 역할 2. 디플로이컨트, 스테이트풀셋, 잡, 크론잡, 데몬셋, 레플리카셋, 레플리케이션 컨트롤러 3. 대응 1. 프론트엔드 > 디플로이먼트 2. 백엔드 > 스테이트풀셋 3. 배치 처리 > 잡, 크론잡 4. 시스템 운영 > 데몬셋

후기

아직 쿠버네티스가 왜 필요한지, 기본 용어들이 뭔지에 대해서만 배워서 큰 그림은 그려지지가 않네요

다음 챕터에서는 도커를 좀 더 자세히 보고 본격적인 실습이 들어갈 것 같아 기대가 됩니다 ㅎ