14주차 - 쿠버네티스

기간	230807 - 230811
배운 내용	쿠버네티스

◎ 쿠버네티스

1. 도커 / 도커 컴포즈 / 쿠버네티스

- 도커        

: 컨테이너를 체계적으로 관리해 줌. 

  한번에 하나의 컨테이너만 관리
  + 하나의 호스트에서만 동작

- 도커 컴포즈   

: 도커와 하나의 호스트에서만 동작한다는 공통점 있지만,

  한 번에 여러 개의 컨테이너를 일관적으로 관리해줌. 묶어서 관리할 때 유리함. 

=> 하나의 호스트에서만 동작한다는 것이 공통적인 단점

- 쿠버네티스    

: 여러 대의 호스트에서 컨테이너를 실행.(안정성)
  한번에 여러 개의 컨테이너 일괄적으로 관리(확장성)

2. 쿠버네티스 아키텍처

1) 시스템 목적에 따른 분류
   - 컨트롤 플레인(마스터) 
   : 쿠버네티스 클러스터(하나의 목적을 가진 여러 대의 시스템 집합)를 전체적으로 운영(관리)하는 시스템

   - 노드(워커노드)
   : 컨테이너를 실행하는 환경. 물리적 리소스 제공. 
     이 외는 컨트롤 플레인에서 전부 관리

2) 컴포넌트
   - 컨트롤 플레인에 배치 (컨트롤 플레인에 배치되는 컴포넌트 5개)
    a) kube-controller-manager
      : 어플리케이션 포함 리소스 관리. 각 리소스의 배포 및 관리
    b) cloud-controller-manager
      : 클라우드 리소스 사용 시. 클라우드 환경에서 운영시 필요
    c) kube-apiserver
      : 컴포넌트 연동 시 필요   
        컴포넌트를 포함한 리소스들의 중심
        각 개체 api 통신 통해 작업 지시/요청함
        컨트롤 플레인의 프론트엔드 역할
    d) kube-scheduler
      : 어떤 노드에 컨테이너를 배치할지 지정
        가중치 주는 스케줄링 기법 포함됨
    e) etcd
      : 쿠버네티스 클러스터의 정보 저장해 두는 저장소
        
   - 노드 배치
    a) 컨테이너 런타임(도커)
      : 컨테이너를 제어(생성/실행/중지/제거)
        -> 컨트롤 플레인의 지시를 따라 제어
    b) kubelet 
      : api 서버 통해 실질적 작업 전달받고 지시(관리자)
        노드의 리소스를 관리. 노드의 상태 관리 및 리소스 제어(모니터링)
    c) kube-proxy
      : 네트워크 연결 담당.
        각 컨테이너들의 네트워크 구성 관리. 파드들의 네트워크 연결 구성

3) 배포 및 설치 방식
   a) minkube : 최소화된 쿠버네티스 환경 설치할 수 있도록 제공. 가상머신 이용해서 설치
   b) kubeadm : 명령어 도구 사용하는 설치방식(환경제약 없음)
   c) kubespray : kubeadm을 바탕으로 ansible 방식으로 설치 (ansible=자동화 도구)
   d) kops : AWS 등의 클라우드 환경에서 사용하는 배포도구. 클라우드 환경에서만 쓸 수 있음

3. 쿠버네티스 워크로드

- 워크로드 : 어플리케이션 배포 방식
   1) 파드 : 하나 이상의(캡슐화된) 컨테이너의 집합
       쿠버네티스 기준에서는 최소 관리 단위 (각 노드에 배치/실행. 노드마다 파드 단위로 실행)
       파드라는 단위 안에 컨테이너가 묶여 있음.
       파드 하나는 하나의 어플리케이션

   2) 컨트롤러 : 파드를 관리하는 개체
      -레플리카셋 : 복제본 만들어서 그 개수를 관리.
      -디플로이먼트 : 래플리카셋의 버전 관리. (배포전략)
      -데몬셋 : 노드마다 하나씩만 파드를 배치
      -스테이트풀셋 : 파드의 순서/이름 등 일부 상태를 유지
      -잡 : 지정한 횟수만큼 실행완료하도록 보장(즉시)
      -크론잡 : 정해준 시각에 주기적으로 실행

 

 

4. 쿠버네티스 환경에서 리소스 배포

1) 명령형 커맨드
   - kubectl 명령어를 사용하면서 직접 옵션으로 설정값 지정
   - 가장 직관적인 방법
   - 일회성이므로 실질적으로는 권장하지 않음
   - 간단한 테스트 등을 위해 사용

   $ kubectl run    -> 파드/컨트롤러를 실행
   $ kubectl expose -> 서비스 배포 시 사용
   $ kubectl get    -> 리소스 확인
   $ kubectl delete -> 리소스 제거(이름 지정해서 제거)

2) 명령형 구성
   - YAML 파일을 작성해서 kubectl 명령어로 관리하는 방식
   
   $ kubectl create -f FILE  -> 파일에서 정의한 리소스 생성
   $ kubectl delete -f FILE  -> 파일에서 정의한 리소스 삭제
   $ kubectl replace -f FILE -> 파일 수정 시 해당 내용 반영

3) 선언적 구성
   - YAML 파일을 작성해서 kubectl 명령어로 관리하는 방식

   $ kubectl apply -f FILE     -> 파일에서 정의한 리소스 배포
   

5. Pod 생성 시 yaml 파일 양식

apiVersion: v1
kind: Pod
metadata:
  name: 실제 파드의 이름
  labels:
    KEY: VALUE
  namespace: 네임스페이스의 이름(기본 default)
spec:
  containers:
  - name: 컨테이너 이름
    image: 이미지 이름

6. 업데이트 기술

1) 블루 그린 배포 : 서로 다른 버전의 어플리케이션을 동일 시점에 만드는 것. 로드밸런서 연결 유무에 따라 버전 바뀌는 업데이트

2) 롤링 업데이트 : 어플 제공할 때 인스턴스 여러 개에서 제공. 하나하나씩 순서대로 업데이트. 로드밸런서를 업데이트된 시스템으로 연결. 하나의 환경에서 순차적으로 업데이트

3) 카나리아 릴리스 : 제한된 사용자에게만 서비스 일부 제공해서 서비스 안전한지 확인하고 만족하면 업데이트(베타테스트 방식). 확인 후 변경

4) 다크런치 : 카나리아와 비슷한 방식. 백엔드 테스트에 한정

7. 쿠버네티스 네트워크

- 파드는 내부적/외부적으로 네트워크 연결이 필요
- 파드 생성 시 파드마다 내부적인 IP주소를 할당(밖에선 접속 불가)
   -> 실질적으로는 사용 불가
      1) 내부적인 IP라서
      2) 파드는 계속 새로 생성될 수 있고, 그에 따라 IP주소가 계속 변경
- 파드에 대한 네트워크 연결을 위해서 서비스라는 리소스를 사용

8. 서비스

- 파드에 대한 접근을 위해 사용. 파드에 대한 단일진입점을 제공
- 고정된 IP 주소를 제공(서비스 종류에 따라 내부/외부 둘 다 가능)
- 서비스에는 내부적인 DNS 주소도 할당
- 파드의 레이블과 서비스의 셀렉터가 일치하면 연결

 

1) 종류
   a) ClusterIP : 쿠버네티스 내부에서 사용하는 서비스
   b) NodePort : 외부에서 파드로 접근할 수 있게 사용하는 서비스.

        파드 실행하는 노드의 포트를 기준으로 접근할 수 있게 포트포워딩 방식 사용
   c) LoadBalancer : 별도의 로드밸런서 장치가 필요(metalLB, NLB) 외부에서 파드로 접근(별도의 퍼블릭 ip 사용)
   d) ExternalName : 파드에서 외부로 접근할 때에 사용. 외부 시스템에 대한 이름 주소를 설정해 두는 서비스
   * a, b는 별도 설정 필요 없음

9. 쿠버네티스 리소스 종류

1) 워크로드
- 파드 : 어플리케이션을 관리하는 최소 단위
- 레플리카셋 : 파드의 복제본 개수를 관리(유지)
- 디플로이먼트 : 레플리카셋의 버전관리(배포정책)
- 데몬셋 : 노드마다 파드를 하나씩 배치
- 스테이트풀셋 : 파드의 순서 및 속성 등을 유지

2) 서비스
- ClusterIP : 파드 끼리 통신할 때에 사용 (내부용)
- headlessService : IP주소가 없는 내부용 서비스
   (스테이트풀셋에 연결해서 특정 파드에 접속할 수 있는 DNS 주소가 생성)
- NodePort : 노드의 IP주소와 특정 포트를 통해서 파드로 접근
- LoadBalancer : 별도의 LB를 통해서 파드로 접근
- ExternalName : 파드에서 외부로 나갈 때 사용할 CNAME(별칭)을 설정

3) 인그레스
- 인그레스 컨트롤러 : (필수) 외부에서 사용자가 접근하는 대상 / 분산작업을 수행
- 인그레스 클래스 : 인그레스 컨트롤러를 여러 종류 사용하는 경우
- 인그레스 : 라우팅 규칙을 설정해서 특정 내부의 서비스로 연결

4) 컨피그맵
- 환경변수 혹은 설정파일 등을 통해 외부적인 요소들을 설정하고자 할 때에 사용
- 동일한 이미지로 환경에 따라 다른 설정을 사용하려고 활용
- 환경변수로 활용하거나 별도의 파일을 마운트 하는 볼륨 마운트 방식으로 사용
cf) 볼륨 마운트 방식은 파일 내용을 그대로 컨피그맵으로 작성해 두고 파드 실행할 때 특정 디렉토리 영역에 마운트 하는 것

- 환경변수 혹은 볼륨으로 사용 가능
- 환경변수의 경우 하나의 컨피그맵에서 여러 변수 설정 가능. 변수의 값을 관리할 때에 유리
- 마운트(볼륨) 방식의 경우 컨피그맵의 키가 파일이름, 값이 파일의 내용이 됨

5) 시크릿

- 컨피그맵과 대부분 유사
- 해당 데이터를 인코딩해서 숨겨주는 방식으로 관리
- 사용 방법은 컨피그맵과 동일(환경변수/볼륨마운트)
- 인증서를 시크릿으로 만들 경우에는 인그레스에서 설정하는 방법도 가능
- 임의의 문자열 / 인증서+키 / 도커레지스트리정보(주소/아이디/패스워드) 들을 저장해 두는 개체

10. 스토리지 관리

- 어플리케이션의 동작을 위해 기본적으로 스토리지 필요 (임시스토리지/영구스토리지)
- 쿠버네티스 등에서 사용하는 컨테이너는 기본적으로 데이터를 보관하지 않음. 

   따라서 보관 필요하면 별도의 설정 필요. 
- 쿠버네티스는 볼륨이라는 개념으로 스토리지 관리

1) 볼륨의 목적
   a) 하나의 파드에 존재하는 각 컨테이너의 데이터 공유 위해 (이때 사용하는 게 emptyDir)
   b) 파드의 라이프사이클과 별개로(파드가 삭제되더라도) 데이터를 저장
- 볼륨은 컨테이너에 마운트 해서 사용

2) 볼륨의 종류
   a) emptyDir : 노드가 갖고 있는 기본스토리지 사용
        임시로 연결해 주는 형태
        파드가 유지되는 동안만 데이터를 유지
        파드 내부의 컨테이너 간의 데이터 공유 위해 사용
   b) hostPath : 노드가 갖고 있는 기본스토리지 사용
        영구적으로(파드를 지워도) 데이터를 보관
        노드마다 데이터가 다르거나 없을 수도(치명적 단점)

3) PV / PVC
- PV : persistent volume(영구 볼륨)
   위에 거(emptyDir 제외) 그냥 쓰면 데이터는 남아있어도, 파드 연결 시 썼던 볼륨은 없어짐
   근데 PV라는 개체는 각종 스토리지 제품 다 활용 가능한데, 활용했을 때 파드와 별개로 만들고 지울 수 있음

   (파드와 별개의 라이프사이클 관리가 가능)
   emptyDir 빼고 주어진 스토리지 다 PV로 만들 수 있음
   
- PVC : 파드와 PV 연결해 주는 개체. 
   파드에 대한 PV 요청할 때 사용

4) 스토리지 클래스
- PV 만들 때 스토리지 클래스 이용해서 자동으로 만들고 싶을 때 사용.

- 볼륨이 자동으로 만들어짐

 

11. 프로브

1) startup prove : 컨테이너가 잘 실행 됐는지. 최초 한 번 확인

 

2) 활성프로브 : 어플리케이션이 잘 동작하고 있는지 확인. 문제 있다 판단되면 그 컨테이너를 재시작

3) 준비성프로브 : 어플 준비됐으면 서비스랑 파드를 연결해 줌. 
중간에 응답 못해주면 다시 서비스랑 파드 연결 끊기도 함
활성/준비성 프로브는 지속적으로 잘 동작하는지 모니터링