3장 컨테이너를 다루는 표준 아키텍처, 쿠버네티스

sua·2022년 9월 20일
1
post-thumbnail

컨테이너 인프라 환경 : 리눅스 운영 체제의 커널 하나에서 여러 개의 컨테이너가 격리된 상태로 실행되는 인프라 환경

  • 컨테이너 : 하나 이상의 목적을 위해 독립적으로 작동하는 프로세스
  • 눈송이 서버(여러 사람이 만져서 설정의 일관성이 떨어진 서버)를 방지하는 데 효과적
  • 자원을 효율적으로 사용할 수 있고 거치는 단계가 적어서 속도도 훨씬 빠름

3.1 쿠버네티스 이해하기

쿠버네티스는 컨테이너 관리 도구라기 보다는 컨테이너 오케스트레이션을 위한 솔루션

  • 오케스트레이션 : 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공하는 것

-> 다수의 컨테이너를 유기적으로 연결, 실행, 종료할 뿐만 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어주는 것

3.1.1 왜 쿠버네티스일까

[컨테이너 오케스트레이션 솔루션 비교]

구분도커 스웜메소스노매드쿠버네티스
설치 난이도쉬움매우 어려움쉬움어려움
사용 편의성매우 좋음좋음매우 좋음좋음
세부 설정 지원거의 없음있음거의 없음다양하게 있음
안정성매우 안정적임안정적임안정적임매우 안정적임
확장성어려움매우 잘 됨어려움매우 잘 됨
정보량많음적음적음매우 많음
에코 파트너없음거의 없음있음매우 많음
학습 곡선쉬움매우 어려움어려움어려움

-> 이렇게 설치 난이도는 어려워도 그 밖의 요소들에서 많은 장점을 가지고 있기 때문에 쿠버네티스를 사용한다.


3.1.2 쿠버네티스 구성 방법 (3가지)

  1. 퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스인 EKS, AKS, GKE 등을 사용 - 구성 다 갖춰져 있고 마스터 노드를 클라우드 업체에서 관리 -> 학습용으로는 적합하지 x
  2. 수세의 Rancher, 레드햇의 OpenShift와 같은 플랫폼에서 제공하는 설치형 쿠버네티스를 사용 - 유료라 쉽게 접근하기 어려움
  3. 사용하는 시스템에 쿠버네티스 클러스터를 자동으로 구성해주는 솔루션을 사용 (구성형 쿠버네티스) - 그중에서 kubeadm이 사용자가 변경하기도 수월하고 온프레미스와 클라우드를 모두 지원하며 배우기도 쉬움

3.1.3 쿠버네티스 구성하기

이 책에서는 학습을 위해 사용자 설정이 가장 많이 필요한 kubeadm으로 쿠버네티스를 구성함.
또한 쿠버네티스가 설치되는 서버 노드는 가상 머신을 이용해 실제 온프레미스에 가깝게 구성

이 책의 실습 코드는 아래 주소에서 확인할 수 있다.
https://github.com/sysnet4admin/_Book_k8sInfra

  1. Vagrantfile 작성

    (1) 5번째 줄 : 쿠버네티스에서 작업을 수행할 워커 노드의 수를 변수(N = 3)으로 받고 해당 변수를 args: N에서 config.sh로 넘김 -> 사용자가 워커 노드의 개수를 직접 조절할 수 있게 함
    (2) 6번째 줄 : 쿠버네티스 버전을 사용자가 선택할 수 있도록 변수 Ver = '1.18.4'로 저장함.
    (3) 25번째 줄 : args:[ Ver, "Main"] 코드를 추가해 쿠버네티스 버전 정보와 Main이라는 문자를 install_pkg.sh로 넘김 -> Ver 변수는 각 노드에 해당 버전의 쿠버네티스 버전을 설치하게 함. Main 문자는 install_pkg.sh에서 조건문으로 처리해 마스터 노드에만 이 책의 전체 실행 코드를 내려받게 함
    (4) 26번째 줄/48번째 줄 : 쿠버네티스 마스터 노드를 위한 master_node.sh와 워커 노드를 위한 work_nodes.sh 코드를 추가

  1. config.sh 작성 (kubeadm으로 쿠버네티스를 설치하기 위한 사전 조건을 설정하는 스크립트 파일)

    (1) 4번째 줄 : vi를 호출하면 vim을 호출하도록 프로파일에 입력 -> 코드에 하이라이트를 넣어 코드를 쉽게 구분할 수 있음
    (2) 7번째 줄 : 쿠버네티스의 설치 요구 조건을 맞추기 위해 스왑되지 않도록 설정
    (3) 9번째 줄 : 시스템이 다시 시작되더라도 스왑되지 않도록 설정
    (4) 12번째 줄 : 쿠버네티스의 리포지토리를 설정하기 위한 경로가 너무 길어지지 않게 경로를 변수로 처리
    (5) 13~21번째 줄 : 쿠버네티스를 내려받을 리포지터리를 설정하는 구문
    (6) 24~25번째 줄 : selinux가 제한적으로 사용되지 않도록 permissive 모드로 변경
    (7) 28~31번째 줄 : 브리지 네트워크를 통과하는 IPv4와 IPv6의 패킷을 iptables가 관리하게 설정 -> 파드의 통신을 iptables로 제어
    (8) 32번째 줄 : br_netfilter 커널 모듈을 사용해 브리지로 네트워크를 구성 -> iptables가 활성화됨
    (9) 35~36번째 줄 : 쿠버네티스 안에서 노드 간 통신을 이름으로 할 수 있도록 각 노드의 호스트 이름과 IP를 /etc/hosts에 설정. 이때 워커 노드는 Vagrantfile에서 넘겨받은 N 변수로 전달된 노드 수에 맞게 동적으로 생성함
    (10) 39~42번째 줄 : 외부와 통신할 수 있게 DNS 서버를 지정

  1. Install_pkg.sh 작성 - 클러스터를 구성하기 위해 가상 머신에 설치돼야 하는 의존성 패키지를 명시, 실습에 필요한 소스 코드를 특정 가상 머신(m-k8s) 내부에 내려받도록 설정됨

    (1) 6번째 줄 : 깃허브에서 코드를 내려받을 수 있게 깃을 설치
    (2) 9번째 줄 : 쿠버네티스를 관리하는 컨테이너를 설치하기 위해 도커를 설치하고 구동
    (3) 12~13번째 줄 : 쿠버네티스를 구성하기 위해 첫 번째 변수로 넘겨받은 1.18.4 버전의 kubectl, kubelet, kubeadm을 설치하고 kubelet을 시작함
    (4) 16~20번째 줄 : 이 책의 전체 실행 코드를 마스터 노드에만 내려받도록 Vagrantfile에서 두 번째 변수를 넘겨받음. 그리고 깃에서 코드를 내려받아 실습을 진행할 루트 홈디렉터리로 옮김. 배시 스크립트를 find로 찾아서 바로 실행 가능한 상태가 되도록 chmod 700으로 설정함

  1. master_node.sh 작성(1개의 가상 머신(m-k8s)을 쿠버네티스 마스터 노드로 구성하는 스크립트) - 쿠버네티스 클러스터를 구성할 때 꼭 선택해야 하는 컨테이너 네트워크 인터페이스(CNI)도 함께 구성함

    (1) 4~5번째 줄 : kubeadm을 통해 쿠버네티스의 워커 노드를 받아들일 준비를 함. 토큰을 123456.1234567890123456으로 지정하고 ttl을 0으로 설정해서 기본값인 24시간 후에 토큰이 계속 유지되게 함. 워커 노드가 정해진 토큰으로 들어오게 함. 쿠버네티스가 자동으로 컨테이너에 부여하는 네트워크를 172.16.0.0/16(172.16.0.1~172.16.255.254)로 제공하고, 워커 노드가 접속하는 API 서버의 IP를 192.168.1.10으로 지정해 워커 노드들이 자동으로 API 서버에 연결되게 함
    (2) 8~10번째 줄 : 마스터 노드에서 현재 사용자가 쿠버네티스를 정상적으로 구동할 수 있게 설정 파일을 루트의 홈디렉터리에 복사하고 쿠버네티스를 이용할 사용자에게 권한을 줌
    (3) 13~14번째 줄 : 컨테이너 네트워크 인터페이스인 캘리코의 설정을 적용해 쿠버네티스의 네트워크를 구성

  1. work_nodes.sh 작성 (3대의 가상 머신(w1-k8s, w2-k8s, w3-k8s)에 쿠버네티스 워커 노드를 구성하는 스크립트)

    (1) 4~5번째 줄 : kubeadm을 이용해 쿠버네티스 마스터 노드에 접속. 이때 연결에 필요한 토큰은 기존에 마스터 노드에서 생성한 그대로 사용. 간단하게 구성하기 위해 --discovery-token-unsafe-skip-ca-verification으로 인증을 무시하고, API 서버 주소인 192.168.1.10으로 기본 포트 번호인 6443번 포트에 접속하도록 설정

  1. cmd창을 열고 vagrant up 명령 실행 -> 지금까지 작성한 파일들로 쿠버네티스 클러스터가 자동으로 구성됨.

  1. 슈퍼푸티를 열어 m-k8s를 더블클릭해 터미널에 접속

  2. kubectl get nodes 명령으로 쿠버네티스 클러스터에 마스터 노드와 워커 노드들이 정상적으로 생성되고 연결됐는지 확인


3.1.4 파드 배포를 중심으로 쿠버네티스 구성 요소 살펴보기

  1. kubectl get pods --all-namespaces 명령으로 설치된 쿠버네티스 구성 요소를 확인

    --all-namespaces : 기본 네임스페이스인 default 외에 모든 것을 표시하겠다는 의미 -> 모든 네임스페이스에서 파드를 수집해 보여줌

관리자나 개발자가 파드를 배포할 때

  1. kubectl : 쿠버네티스 클러스터에 명령을 내리는 역할. API 서버와 주로 통신하므로 이 책에서는 API 서버가 위치한 마스터 노드에 구성함
  2. API 서버 : 쿠버네티스 클러스터의 중심 역할을 하는 통로. 상태 값을 저장하는 etcd 뿐만 아니라 그 밖의 요소들 또한 API 서버를 중심에 두고 통신하므로 API 서버의 역할이 매우 중요함.
  3. etcd : 구성 요소들의 상태 값이 모두 저장되는 곳. -> etcd의 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구할 수 있음.
  4. 컨트롤러 매니저 : 쿠버네티스 클러스터의 오브젝트 상태를 관리. 다양한 상태 값을 관리하는 주체들이 컨트롤러 매니저에 소속돼 각자의 역할을 수행함.
  5. 스케줄러 : 노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정하고 할당함. 파드가 워커 노드에 할당되는 일정을 관리하는 역할
  6. kubelet : 파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링함.
  7. 컨테이너 런타임 : 파드를 이루는 컨테이너의 실행을 담당함.
  8. 파드 : 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 단위. 파드는 언제라도 죽을 수 있는 존재라는 점이 중요함.
  9. 네트워크 플러그인 : 쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성해야 함. 일반적으로 CNI로 구성하는데, 주로 사용하는 것은 캘리코이다.
  10. CoreDNS : 빠르고 유연한 DNS 서버. 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는 데 사용함. 실무에서 쿠버네티스 클러스터를 구성하여 사용할 때는 CoreDNS를 사용하는 것이 일반적.

사용자가 배포된 파드에 접속할 때
1. kube-proxy : 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정함.
2. 파드 : 이미 배포된 파드에 접속하고 필요한 내용을 전달받음. 이때 대부분 사용자는 파드가 어느 워커 노드에 위치하는지 신경쓰지 않아도 됨.


3.1.5 파드의 생명주기로 쿠버네티스 구성 요소 살펴보기

  1. kubectl을 통해 API 서버에 파드 생성을 요청함.
  2. (업데이트가 있을 때 마다 매번) API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로 유지함. -> 각 요소가 상태를 업데이트할 때 마다 모두 API 서버를 통해 etcd에 기록됨.
  3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고, 이 상태를 API 서버에 전달함. 아직 어떤 워커 노드에 파드를 적용할지는 결정되지 않은 상태로 파드만 생성됨.
  4. API 서버에 파드가 생성됐다는 정보를 스케줄러가 인지함. 스케줄러는 생성된 파드를 어떤 워커 노드에 적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청함.
  5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지 스케줄러가 kubelet으로 확인함
  6. kubelet에서 컨테이너 런타임으로 파드 생성을 요청함.
  7. 파드가 생성됨.
  8. 파드가 사용 가능한 상태가 됨.

쿠버네티스틑 선언적인 시스템 구조 -> 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다는 뜻.


3.1.6 쿠버네티스 구성 요소의 기능 검증하기

kubectl
1. 슈퍼푸티에서 w3-k8s를 더블클릭해 터미널에 접속


  1. kubectl get nodes를 실행

    -> 쿠버테시트의 노드들에 대한 정보가 표시되지 않음. 쿠버네티스 클러스터의 정보를 kubectl이 알지 못하기 때문. -> API 서버의 접속 정보만 있다면 어느 곳에서든 쿠버네티스 클러스터에 명령을 내릴 수 있음

  1. 쿠버네티스 클러스터의 정보를 마스터 노드에서 scp 명령으로 w3-k8s의 현재 티렉터리에 받아옴. (접속 암호인 vagrant 입력하기)

  1. kubectl get nodes 명령에 추가로 쿠버네티스 클러스터 정보를 입력받는 옵션인 --kubeconfig와 마스터 노드에서 받아온 admin.conf를 입력하고 실행

    -> 노드 정보가 정상적으로 표시됨.

kubelet

  1. m-k8s에서 nginx 웹 서버 파드를 배포

  2. 배포된 파드가 정상적으로 배포된 상태인지 확인

  3. 파드가 배포된 워커 노드를 확인

    -o : 출력을 특정 형식으로 해주는 옵션. wide : 제공되는 출력 형식 중에서 출력 정보를 더 많이 표시해주는 옵션


  1. 배포된 노드인 w1-k8s에 접속해 kubelet 서비스를 멈춤

  2. m-k8s에서 상태를 확인하고 파드를 삭제

  3. 파드의 상태를 확인

    -> 삭제하고 있지만 kubelet이 작동하지 않는 상태라 파드는 삭제되지 않는다.


  1. w1-k8s에서 kubelet을 복구

  2. m-k8s에서 nginx-pod가 삭제됐는지 확인

-> kubelet에 문제가 생기면 파드가 제대로 관리되지 않음을 확인


kube-proxy

  1. kube-proxy에 문제가 생기는 상황을 테스트하기 위해 m-k8s에서 다시 파드를 배포

  2. 파드의 IP와 워커 노드를 확인

  3. 파드의 IP로 nginx 웹 서버 메인 페이지 내용을 확인

  4. w3-k8s에 접속해 파드가 위치한 워커 노드에서 br_netfilter 모듈을 제거

  5. 네트워크를 다시 시작해 변경된 내용을 적용

-> kube-proxy에 문제가 생기는 상황을 만듦

  1. m-k8s에서 파드의 nginx 웹 서버 페이지 정보를 받아옴

  2. 파드 상태를 확인

    -> 파드의 노드 위치와 IP, 상태 모두 문제 없음. 하지만, kube-proxy가 이용하는 br_netfilter에 문제가 있어서 파드의 nginx 웹 서버와의 통신만이 정상적으로 이루어지지 않는 상태


  1. 정상적으로 파드의 nginx 웹 서버 정보를 받아올 수 있는 상태로 만들기 위해 워커 노드에서 br_netfilter를 커널에 적재하고 시스템을 다시 시작해 적용

  2. m-k8s에서 파드 상태를 확인

    -> RESTART가 1로 증가돼 파드가 1회 다시 시작했다고 뜨고, IP가 변경된 것을 확인할 수 있음


  1. 바뀐 IP로 curl 명령을 실행해 파드로부터 정보를 정상적으로 받아오는지 확인

  2. 배포한 파드를 삭제



3.2 쿠버네티스 기본 사용법 배우기

3.2.1 파드를 생성하는 방법

  1. 파드 생성

    -> nginx : 파드의 이름, --image=nginx : 생성할 이미지의 이름

  1. 파드가 잘 생성됐는지 확인

  2. create 방식으로 파드 생성해보기 (deployment를 추가해서 실행해야 함)

  3. 생성된 파드 확인

  4. 생성된 파드의 IP 확인

  5. 각 파드에서 curl 명령을 실행해 웹 페이지 정보를 받아오는지 확인

run으로 파드를 생성하면 단일 파드 1개만 생성되고 관리.
create deployment로 파드를 생성하면 디플로이먼트라는 관리 그룹 내에서 파드가 생성됨.


3.2.2 오브젝트란

파드와 디플로이먼트는 스펙과 상태 등의 값을 가지고 있음. 이러한 값을 가지고 있는 파드와 디플로이먼트를 개별 속성을 포함해 부르는 단위가 오브젝트임.

기본 오브젝트

  1. 파드 : 쿠버네티스에서 실행되는 최소 단위. 독립적인 공간과 사용 가능한 IP를 가지고 있음. 하나의 파드는 1개 이상의 컨테이너를 갖고 있기 때문에 여러 기능을 묶어 하나의 목적으로 사용할 수 있음. 그러나 대부분 1개의 파드에 1개의 컨테이너를 적용함

  2. 네임스페이스 : 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹. 특별히 지정하지 않으면 기본으로 할당되는 default, 쿠버네티스 시스템에서 사용되는 kube-system, 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속해있는 metallb-system 등이 있음

  3. 볼륨 : 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공하지만 파드가 사라지더라도 저장과 보존이 가능한 디렉터리를 볼륨 오브젝트를 통해 생성하고 사용할 수 있음.

  4. 서비스 : 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결됨. 기존 인프라에서 로드밸런서, 게이트웨이와 비슷한 역할을 함.


디플로이먼트
효율적으로 작동하도록 기능들을 조합하고 추가해 구현한 것이 디플로이먼트.

  1. 디플로이먼트 생성

    system4admin은 계정이름, echo-hname은 이미지 이름

  1. 생성된 디플로이먼트 확인

    -> dpy-hname을 확인함

  1. 디플로이먼트 삭제

  2. 디플로이먼트가 삭제됐는지 확인


3.2.3 레플리카셋으로 파드 수 관리하기

많은 사용자를 대상으로 웹 서비스를 하려면 다수의 파드가 필요한데, 하나씩 생성한다면 매우 비효율적 -> 쿠버네티스에서는 다수의 파드를 만드는 레플리카셋 오브젝트를 제공
그러나, 레플리카셋은 파드 수를 보장하는 기능만 제공하기 때문에 디플로이먼트를 사용해 파드 수를 관리하는 것이 권장된다.

  1. 배포된 파드의 상태를 확인

  2. nginx-pod를 3개로 증가시키기

    -> 리소스를 찾을 수 없다는 에러 메시지가 나옴. 파드로 생성됐기 때문에 디플로이먼트 오브젝트에 속하지 않아서 발생하는 에러임.

  3. 디플로이먼트로 생성된 dpy-nginx의 파드의 수를 3개로 만들기

  4. 추가된 2개의 nginx 파드 확인

  5. 모든 파드가 정상적으로 워커 노드에 적용되고 IP가 부여됐는지 확인

  1. 생성한 디플로이먼트 dpy-nginx 삭제

  2. 삭제한 후에 배포된 파드 또는 디플로이먼트의 상태 확인


3.2.4 스펙을 지정해 오브젝트 생성하기

create에서 디플로이먼트를 생성하면서 한번에 여러 개의 파드를 만들기 위해서는 오브젝트 스펙 파일을 작성해서 설정을 적용해야 한다.

  1. echo-hname.yaml 작성 (3개의 nginx 파드를 디플로이먼트 오브젝트로 만드는 오브젝트 스펙)

  1. echo-hname.yaml 파일을 이용해 디플로이먼트를 생성

  2. 새로 생성된 echo-hname 파드가 3개인지 확인

  3. echo-hname.yaml 파일을 수정해 파드를 6개로 늘리기

    sed : 파일 수정해주는 명령어 / -i : 변경한 내용을 현재 파일에 바로 적용하겠다는 의미


  1. replicas의 값이 3에서 6으로 변경됐는지 확인

  2. 변경된 내용을 적용

    -> 이미 있다는 문구만 뜸


3.2.5 apply로 오브젝트 생성하고 관리하기

create로 디플로이먼트를 생성하면 파일의 변경 사항을 바로 적용할 수 없다는 단점이 있음. -> 쿠버네티스틑 apply라는 명령어를 제공함.

  1. echo-hname.yaml 파일을 kubectl apply 명령으로 적용

  2. 6개로 늘어났는지 확인

-> 일회적 사용(애드혹)으로 오브젝트를 생성할 때는 create를 사용하고, 변경이 생길 가능성이 있는 복잡한 오브젝트는 파일로 작성한 후 apply로 적용하는 것이 좋음.


3.2.6 파드의 컨테이너 자동 복구 방법

쿠버네티스는 거의 모든 부분이 자동 복구되도록 설계.
파드의 자동 복구 기술을 셀프 힐링이라고 함. -> 제대로 작동하지 않는 컨테이너를 다시 시작하거나 교체해 파드가 정상적으로 작동하게 함.

  1. 접속할 파드의 IP를 확인

  2. 파드 컨테이너의 셸에 접속하기

    it 옵션 : 표준 입력을 명령줄 인터페이스로 작성한다는 의미 / 파드인 nginx-pod에 /bin/bash를 실행해 nginx-pod의 컨테이너에서 배시 셸에 접속


  1. 컨테이너에서 구동하는 nginx의 PID를 확인

  2. 프로세스가 생성된 시간을 확인

  3. m-k8s의 터미널을 1개 더 띄우고 nginx-pod의 IP에서 돌아가는 웹 페이지를 1초마다 한 번씩 요청하는 스크립트를 실행

  4. 배시 셸에서 nginx 프로세서인 PID 1번을 종료

  5. 추가한 터미널에서 1초마다 nginx 웹 페이지를 받아오는 스크립트가 잘 작동하는지 확인하고 자동으로 다시 복구되는지도 함께 확인

  6. 배시셸에서 ls -l을 실행하여 nginx.pid가 생성된 시간으로 새로 생성된 프로세스인지 확인

  7. exit 명령을 수행해 다시 m-k8x의 배시 셸로 나옴


3.2.7 파드의 동작 보증 기능

쿠버네티스는 파드 자체에 문제가 발생하면 파드를 자동 복구해서 파드가 항상 동작하도록 보장하는 기능이 있음

  1. 파드에 문제가 발생하는 상황을 만들기 위해 앞에서 생성한 파드를 삭제하기 전에 현재 어떤 파드들이 있는지 먼저 확인

  2. nginx-pod 삭제

  3. 파드 목록 중에서 가장 위에 있떤 파드를 삭제

  4. 삭제가 잘 됐는지 확인

    -> 아직도 6개의 파드가 살아있으며 AGE를 봤을 때 하나는 최근에 생성된 것으로 보임. 또한 앞에서 삭제한 것은 목록에 없음.

nginx-pod는 디플로이먼트에 속한 파드가 아니며 어떤 컨트롤러도 이 파드를 관리하지 않기 때문에 바로 삭제되고 다시 생성되지도 않음.

echo-hname은 디플로이먼트에 속한 파드이고 replicas에서 6개로 선언했음. replicas는 파드를 선언한 수대로 유지하도록 파드의 수를 항상 확인하고 부족하면 새로운 파드를 만들어냄. 그렇기 때문에 삭제해도 1개가 생성됐던 것이다.


  1. 디플로이먼트에 속한 파드는 상위 디플로이먼트를 삭제해야 파드가 삭제됨. 디플로이먼트를 삭제하기

  2. 배포된 파드가 남아있는지 확인


3.2.8 노드 자원 보호하기

노드는 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할을 함.
문제가 생길 가능성이 있는 노드라는 것을 쿠버네티스에 어떻게 알려줄까?
이런 경우에 cordon 기능을 사용한다.

  1. echo-hname.yaml을 적용해 파드를 생성

  2. 배포한 파드를 9개로 늘리기

  3. 배포된 9개의 파드가 제대로 작동하는지, IP 할당이 잘 됐는지, 각 노드로 공평하게 배분됐는지를 확인

    custom-columns : 사용자가 임의루 구성할 수 있는 열을 의미 / NAME, IP, STATUS, NODE는 열의 제목 / 콜론 뒤에 내용 값을 넣고 콤마로 구분


  1. 파드의 수를 3개로 줄이기

  2. 각 노드에 파드가 1개씩만 남았는지 확인

  3. w3-k8s 노드에서 문제가 자주 발생해 현재 상태를 보존시키기.

  4. cordon 명령이 제대로 적용됐는지 확인

    -> w3-k8s가 더 이상 파드가 할당되지 않는 상태로 변경됨.


  1. 파드 수를 9개로 늘리기

  2. 노드에 배포된 파드를 확인

    -> w3-k8s에 추가로 배포된 파드는 없음


  1. 파드 수를 3개로 줄이기

  2. 각 노드에 할당된 파드 수가 공평하게 1개씩인지 확인

  3. w3-k8s에 파드가 할당되지 않게 설정했던 것을 해제

  4. uncordon이 적용됐는지 확인


3.2.9 노드 유지보수하기

쿠버네티스를 사용하다 보면 정기 및 비정기적인 유지보수를 위해 노드를 꺼야 하는 상황이 발생함. 이런 경우를 대비해 쿠버네티스는 drain 기능을 제공.
drain은 지정된 노드의 파드를 전부 다른 곳으로 이동시켜 해당 노드를 유지보수할 수 있게 함.

  1. 유지보수할 노드 w3-k8s를 파드가 없는 상태로 만들기

    -> w3-k8s에서 데몬셋을 지울 수 없어서 명령을 수행할 수 없다고 나옴

drain은 실제로 파드를 옮기는 것이 아니라 노드에서 파드를 삭제하고 다른 곳에 다시 생성함. 그러나, DemonSet은 각 노드에 1개만 존재하는 파드라서 drain으로는 삭제할 수 없음.

  1. DemonSet을 무시하고 진행 (ignore-daemonsets 옵션 함께 사용)

    -> 경고가 발생하지만 모든 파드가 이동됨

  1. 노드 w3-k8s에 파드가 없는지 확인. 옮긴 노드에 파드가 새로 생성돼 파드 이름과 IP가 부여된 것도 확인

  2. w3-k8s 노드의 상태를 확인

  3. 유지보수가 끝났다고 가정하고 w3-k8s가 스케줄을 받을 수 있는 상태로 복귀시키기

  4. 다시 노드 상태를 확인

  5. 배포한 echo-hname을 삭제

  6. 배포된 파드가 없음을 확인


3.2.10 파드 업데이트하고 복구하기

파드 업데이트하기

  1. rollout-nginx.yaml 작성

    image: nginx: 1.15.12 : 설치할 컨테이너 버전을 지정하고, 설치한 후에 단계별로 버전을 업데이트할 예정

  1. 컨테이너 버전 업데이트를 테스트하기 위한 파드를 배포

    --record 옵션 : 배포한 정보의 히스토리를 기록함

  1. record 옵션으로 기록된 히스토리 확인

  2. 배포한 파드의 정보를 확인

  3. 배포된 파드에 속해 있는 nginx 컨테이너 버전을 확인

  4. 파드의 nginx 컨테이너 버전을 1.16.0으로 업데이트하기 + --record도 사용

  5. 파드의 상태를 확인

    -> 파드들의 이름과 IP가 변경됨

파드에 속한 nginx 컨테이너를 업데이트하는 가장 쉬운 방법은 파드를 관리하는 replicas의 수를 줄이고 늘려 파드를 새로 생성하는 것이라서 이렇게 변경되는 거임.


  1. Deployment 상태를 확인

  2. rolout-nginx에 적용된 명령들을 확인

  3. 업데이트가 제대로 이루어졌는지도 확인


업데이트 실패 시 파드 복구하기

  1. nginx 컨테이너 버전을 의도(1.17.2)와 다르게 1.17.23을 입력

  2. 상태 확인

    -> 파드가 삭제되지 않고 pending(대기 중) 상태에서 넘어가지 않음


  1. 어떤 문제인지를 확인하기 위해 rollout status 실행

    -> 새로운 replicas는 생성했으나 디플로이먼트를 배포하는 단계에서 대기 중으로 더이상 진행되지 않은 것을 확인할 수 있음

  1. 문제점을 좀 더 자세히 살펴보기. describe 명령은 쿠버네티스의 상태를 살펴볼 때 유용


    -> replicas가 새로 생성되는 과정에서 멈춰 있음. 이유는 1.17.23 버전의 nginx 컨테이너가 없기 때문.

  1. 복구하기 위해 업데이트할 때 사용했던 명령들을 확인

  2. 명령 실행을 취소해 마지막 단계에서 전 단계로 상태를 되돌림

  3. 파드 상태를 다시 확인

  4. 실행된 명령을 확인

    -> revision 4가 추가되고 revision 2가 삭제됨. 현재 상태를 2로 되돌렸기 때문에 2는 삭제되고 가장 최근 상태는 4가 됨


  1. 배포된 컨테이너의 nginx 버전 확인

  2. 변경이 정상적으로 적용됐는지 확인

  3. 현재 디플로이먼트 상태도 세부적으로 점검


특정 시점으로 파드 복구하기

  1. 처음 상태인 revision 1로 돌아가보기

  2. 새로 생성된 파드들의 IP를 확인

  3. nginx 컨테이너의 버전을 확인

    -> 처음 상태로 복구됨


  1. rollout-nginx 디플로이먼트 삭제

  2. 배포된 파드가 없는지 확인



3.3 쿠버네티스 연결을 담당하는 서비스

서비스 : 쿠버네티스에서 외부에서 쿠버네티스 클러스터에 접속하는 방법

3.3.1 가장 간단하게 연결하는 노드포트

노드포트 서비스를 설정하면 모든 워커 노드의 특정 포트(노드 포트)를 열고 여기로 오는 모든 요청을 노드포트 서비스로 전달함. -> 노드포트 서비스는 해당 업무를 처리할 수 있는 파드로 요청을 전달함.

노드포트 서비스로 외부에서 접속하기

  1. 디플로이먼트로 파드를 생성

  2. 배포된 파드를 확인

  3. 노드포트 서비스 생성 (편의를 위해 이미 정의한 오브젝트 스펙을 이용)


    nodeport.yaml에서 kind가 Service로 바뀌었고 서비스의 type을 NodePort로 지정함


  1. 노드포트 서비스로 생성한 np-svc 서비스를 확인

    -> 노드포트의 포트 번호가 30000번으로 지정됨. CLUSTER-IP는 쿠버네티스 클러스터의 내부에서 사용하는 IP로, 자동으로 지정됨.

  1. 쿠버네티스 클러스터의 워커 노드 IP를 확인

  2. 웹 브라우저를 띄우고 확인한 워커 노드의 IP와 노드포트의 포트번호인 30000번으로 접속해 외부에서 접속되는지 확인



    -> 배포된 파드에 모든 노드의 노드포트를 통해 외부에서도 접속할 수 있음을 확인


부하 분산 테스트하기

  1. cmd 창을 띄우고 해당 명령 실행

  2. 마스터노드에서 파드를 3개로 증가시키기

  3. 배포된 파드를 확인

  4. 파워셸 명령 창을 확인해 표시하는 파드 이름에 배포된 파드 3개가 돌아가면서 표시되는지 확인

    -> 부하 분산이 제대로 되고 있음

노드포트의 오브젝트 스펙에 적힌 np-pods와 디플로이먼트의 이름을 확인해 동일하면 같은 파드라고 간주했기 때문에 추가된 파드를 외부에서 추적해 접속하는 것임.


expose로 노드포트 서비스 생성하기

  1. 서비스로 내보낼 디플로이먼트를 np-pods로 지정. 해당 서비스의 이름은 np-svc-v2로, 타입은 NodePort로 지정, 연결 포트를 80번으로 지정

  2. 생성된 서비스를 확인

    -> expose를 사용하면 노드포트의 포트 번호를 지정할 수 없음. 포트 번호는 30000~32767에서 임의로 지정됨.


  1. 웹 브라우저를 띄우고 192.168.1.101:32672에 접속

    -> 배포된 파드 중 하나의 이름이 웹 브라우저에 표시됨

  1. 배포한 디플로이먼트와 서비스 2개를 모두 삭제

3.2.2 사용 목적별로 연결하는 인그레스

여러 개의 디플로이먼트가 있을 때 그 수만큼 노드포트 서비스를 구동할 순 없기 때문에 이런 경우에 인그레스를 사용함.

인그레스 : 고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공할 수 있고, 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공

인그레스를 사용하려면 인그레스 컨트롤러가 필요함. 여기서는 NGINX 인그레스 컨트롤러로 구성함.

[NGINX 인그레스 컨트롤러가 작동하는 단계]
1. 사용자는 노드마다 설정된 노드포트를 통해 노드포트 서비스로 접속함. 이때 노드포트 서비스를 NGINX 인그레스 컨트롤러로 구성
2. NGINX 인그레스 컨트롤러는 사용자의 접속 경로에 따라 적합한 클러스터 IP 서비스로 경로를 제공
3. 클러스터 IP 서비스는 사용자를 해당 파드로 연결해 줌

  1. 테스트용으로 디플로이먼트 2개(in-hname-pod, in-ip-pod)를 배포

  2. 배포된 파드의 상태 확인

  3. NGINX 인그레스 컨트롤러를 설치

  4. NGINX 인그레스 컨트롤러의 파드가 배포됐는지 확인 ingress-nginx 네임스페이스에 속하므로 옵션을 추가함.

  5. 인그레스를 사용자 요구 사항에 맞게 설정하기 위해 경로와 작동을 정의


    ingress-config.yaml은 들어오는 주소 값과 포트에 따라 노출된 서비스를 연결하는 역할을 설정. 외부에서 주소 값과 노드포트를 가지고 들어오는 것은 hname-svc-default 서비스와 연결된 파드로 넘기고, 외부에서 들어오는 주소 값, 노드포트와 함께 뒤에 /ip를 추가한 주소값은 ip-svc 서비스와 연결된 파드로 접속하게 설정


  1. 인그레스 설정 파일이 제대로 등록 됐는지 확인

  2. 인그레스에 요청한 내용이 확실하게 적용됐는지 확인


    -> 인그레스에 적용된 내용을 야믈 형식으로 출력해 적용된 내용을 확인할 수 있음


  1. 외부에서 NGINX 인그레스 컨트롤러에 접속할 수 있게 노드포트 서비스로 NGINX 인그레스 컨트롤러를 외부에 노출하기


    ingress.yaml : 기존 노드포트와 달리 http를 처리하기 위해 30100번 포트로 들어온 요청을 80번으로 넘기고, https를 처리하기 위해 30101번 포트로 들어온 것을 443번 포트로 넘김.

  1. 노드포트 서비스로 생성된 NGINX 인그레스 컨트롤러를 확인

  2. 디플로이먼트도 서비스로 노출하기. (외부와 통신하기 위해 클러스터 내부에서만 사용하는 파드를 클러스터 외부에 노출할 수 있는 구역으로 옮기는 것)

  3. 생성된 서비스들을 점검해 디플로이먼트들이 서비스에 정상적으로 노출되는지 확인

  4. 웹 브라우저를 띄우고 192.168.1.101:30100에 접속

  5. 192.168.1.101:30100/ip에 접속

    -> 요청 방법과 파드의 ip가 반환됨


  1. https://192.168.1.101:30101로 접속해 HTTPS 연결도 정상적으로 작동하는지 확인

  2. https://192.168.1.101:30101/ip를 입력해 접속되는지 확인

  3. 배포한 디플로이먼트와 모든 서비스를 삭제

  4. NGINX 인그레스 컨트롤러와 관련된 내용도 모두 삭제


3.3.3 클라우드에서 쉽게 구성 가능한 로드밸런서

앞선 방식들은 매우 비효율적임.
그래서 쿠버네티스에서는 로드밸런서라는 서비스 타입을 제공해 간단한 구조로 파드를 외부에 노출하고 부하를 분산함.

지금까지 로드밸런서를 사용하지 않은 이유는 이를 사용하려면 로드밸런서를 이미 구현해 둔 서비스 업체의 도움을 받아 쿠버네티스 클러스터 외부에 구현해야 하기 때문임.
-> 우리가 만든 테스트 가상 환경에서 로드밸런서 사용방법을 알아볼 예정


3.3.4 온프레미스에서 로드밸런서를 제공하는 MetalLB

MetalLB : 온프레미스에서 로드밸런서를 사용하기 위해 내부에 로드밸런서 서비스를 받아주는 구성을 지원하는 것. 특별한 네트워크 설정이나 구성이 있는 것이 아니라 기존의 L2 네트워크와 L3 네트워크로 로드밸런서를 구현함.

이 책에서는 MetalLB의 L2 네트워크로 로드밸런서를 구현함.

MetalLB 컨트롤러는 작동 방식인 프로토콜을 정의하고 EXTERNAL-IP를 부여해 관리함. MetalLB 스피커는 정해진 작동 방식에 따라 경로를 만들 수 있도록 네트워크 정보를 광고하고 수집해 각 파드의 경로를 제공함.

  1. 디플로이먼트를 이용해 2종류(lb-hname-pods, lb-ip-pods)의 파드를 생성하고 파드를 3개로 늘려 노드당 1개씩 파드가 배포되게 함.

  2. 2종류의 파드가 3개씩 총 6개가 배포됐는지 확인

  3. 사전에 정의된 오브젝트 스펙으로 MetalLB를 구성. 필요한 요소가 모두 설치되고 독립적인 네임스페이스(metallb-system)도 함께 만들어짐

  4. 배포된 MetalLB의 파드가 5개인지 확인하고, IP와 상태도 확인

  5. MetalLB에 설정 적용 (오브젝트는 ConfigMap을 사용 - 설정이 정의된 포맷)

  6. ConfigMap이 생성됐는지 확인

  7. 옵션을 주고 다시 실행해 MetalLB의 설정이 올바르게 적용됐는지 확인

  8. 각 디플로이먼트(lb-hname-pods, lb-ip-pods)를 로드밸런서 서비스로 노출하기

  9. 생성된 로드밸런서 서비스별로 CLUSTER-IP와 EXTERNAL-IP가 잘 적용됐는지 확인. 특히 EXTERNAL-IP에 ConfigMap을 통해 부여한 IP를 확인

  10. 웹 브라우저에서 192.168.1.11로 접속

  11. 웹 브라우저에 192.168.1.12로 접속해 파드에 요청 방법과 IP가 표시되는지 확인

  12. 파워셸 명령 창을 띄우고 셸 스크립트 실행

  13. 파드를 6개로 늘리기

  14. 늘어난 파드 6개도 EXTERNAL-IP를 통해 접근되는지 확인

  15. 배포한 디플로이먼트와 서비스는 삭제. 단, MetalLB 설정은 계속 사용하므로 삭제하지 않음


3.3.5 부하에 따라 자동으로 파드 수를 조절하는 HPA

쿠버네티스는 사용자가 갑자기 늘어나는 경우를 대비해 부하량에 따라 디플로이먼트의 파드 수를 유동적으로 관리하는 기능을 제공함. 이것을 HPA라고 한다.

  1. 디플로이먼트 1개를 hpa-hname-pods라는 이름으로 생성

  2. hpa-hname-pods를 로드밸런서 서비스로 바로 설정

  3. 설정된 로드밸런서 서비스와 부여된 IP를 확인

  4. 부하를 확인

    -> 자원을 요청하는 설정이 없다며 에러가 생기고 진행되지 않음.

HPA가 자원을 요청할 때 메트릭 서버를 통해 계측값을 전달받음. but, 현재 우리에게는 메트릭 서버가 없기 때문에 에러가 발생하는 것임. 메트릭 서버를 설정해야 한다!


  1. 오브젝트 스펙 파일로 메트릭 서버 생성

  2. 부하를 다시 확인

    -> 현재는 아무런 부하가 없으므로 CPU와 MEMORY 값이 매우 낮게 나옴


  1. edit 명령을 실행해 배포된 디플로이먼트 내용을 확인하고 파드마다 주어진 부하량을 결정하는 기준을 추가.


    🚨적용하려는데 안되는 에러 발생..

    vim 에디터를 통해 다시 열어서 수정해보았다.


    그랬더니 됐음! (참고 사이트 출처 : https://jaynamm.tistory.com/entry/k8s-kubernetes-edit-Error-error-Edit-cancelled-no-valid-changes-were-saved)

  1. 다시 부하 확인

    -> 새로운 파드가 생성된 것을 확인할 수 있음

  1. autoscale을 설정해서 특정 조건이 만족되는 경우에 자동으로 scale 명령이 수행되도록 함.

    min은 최소 파드의 수, max는 최대 파드의 수. cpu percent는 CPU 사용량이 50%를 넘게 되면 autoscale하겠다는 뜻

  1. 왼쪽에 마스터 노드 창 두 개를 띄우고 오른쪽에는 파워셸 창 띄우기

  2. 왼쪽 상단 창에서는 watch kubectl top pods. 하단 창에서는 watch kubectl get pods를 실행.

    watch 사용 이유 : 2초에 한 번씩 자동으로 상태를 확인하기 위해


  1. 파워셸 창에서 반복문 실행

  2. 왼쪽 상단 창에서 부하량을 감지하는지 확인

  3. 부하량이 늘어남에 따라 왼쪽 하당 창에서 파드가 새로 생성되는지 확인

  4. 부하 분산으로 생성된 파드의 부하량이 증가하는지 확인

  5. 더 이상 파드가 새로 생성되지 않는 안정적인 상태가 되는 것일 확인하고 파워셸 창을 종료

  6. 더이상 부하가 없으면 autoscale의 최소 조건인 파드 1개의 상태로 돌아가기 위해 파드가 종료되는 것을 확인 -> 1개만 남음

  7. 생성한 디플로이먼트, 서비스, 메트릭 서버를 삭제 (MetalLB는 삭제하지 않음)



3.4 알아두면 쓸모 있는 쿠버네티스 오브젝트

3.4.1 데몬셋

데몬셋은 디플로이먼트의 replicas가 노드 수 만큼 정해져 있는 형태임.
노드를 관리하는 파드라면 데몬셋으로 만드는 게 가장 효율적이다.

  1. 현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인

  2. 워커 노드를 1개 늘리기 (Vagrantfile의 5번째 줄에 있는 N 인자의 값을 3에서 4로 수정)

  3. w4-k8s를 실행 (새로운 워커 노드를 추가하는 명령)

  4. m-k8s에서 확인

  5. 자동으로 추가된 노드에 설치된 스피커가 데몬셋이 맞는지 확인


3.4.2 컨피그맵

컨피그맵은 설정을 목적으로 사용하는 오브젝트. MetalLB는 프로젝트 타입으로 정해진 오브젝트가 없어서 범용 설정으로 사용되는 컨피그맵을 지정했음.

  1. 테스트용 디플로이먼트를 cfgmap이라는 이름으로 생성

  2. cfgmap을 로드밸런서를 통해 노출하고 이름은 cfgmap-svc로 지정

  3. 생성된 서비스의 IP를 확인

  4. 사전에 구성돼 있는 컨피그맵의 기존 IP를 sed 명령을 사용해 192.168.1.21~192.168.1.23으로 변경

  5. 컨피그맵 설정 파일에 apply를 실행해 변경된 설정을 적용

  6. MetalLB와 관련된 모든 파드를 삭제 -> 삭제하고나면 kubelet에서 해당 파드를 자동으로 모두 다시 생성

  7. 새로 생성된 MetalLB의 파드들을 확인

  8. 기존에 노출한 MetalLB 서비스를 삭제하고 동일한 이름으로 다시 생성해 새로운 컨피그맵을 적용한 서비스가 올라오게 함

  9. 변경된 설정이 적용돼 새로운 MetalLB 서비스의 IP가 192.168.1.21로 바뀌었는지 확인

  10. 웹브라우저에서 192.168.1.21로 접속해 파드의 이름이 화면에 표시되는지 확인

  11. 생성한 디플로이먼트와 서비스를 삭제


3.4.3 PV와 PVC

때때로 파드에서 생성한 내용을 기록하고 보관하거나 모든 파드가 동일한 설정 값을 유지하고 관리하기 위해 공유된 볼륨으로부터 공통된 설정을 가지고 올 수 있도록 설계해야 할 때가 있음. 이런 경우를 위해 다양한 형태의 볼륨을 제공함. 이책에서는 다양한 쿠버네티스 볼륨 스토리지 중에서 PV와 PVC를 설명함.

쿠버네티스틑 필요할 때 PVC(지속적으로 사용 가능한 볼륨 요청)을 요청해 사용. PVC를 사용하려면 PV(지속적으로 사용 가능한 볼륨)로 볼륨을 선언해야 함.
-> PV는 볼륨을 사용할 수 있게 준비하는 단계, PVC는 준비된 볼륨에서 일정 공간을 할당 받는 것.

가장 구현하기 쉬운 NFS 볼륨 타입으로 PV와 PVC를 생성하고 파드에 마운트해 볼 예정.


NFS 볼륨에 PV/PVC 만들고 파드에 연결하기

  1. PV로 선언할 볼륨을 만들기 위해 NFS 서버를 마스터 노드에 구성.

  2. 해당 내용을 시스템에 적용해 NFS 서버를 활성화하고 다음에 시작할 때도 자동으로 적용되도록 하기

  3. 다음 경로에 있는 오브젝트 스펙을 실행해 PV를 생성

  4. 생성된 PV의 상태가 사용 가능임을 확인

  5. 다음 경로에서 오브젝트 스펙을 실행해 PVC를 생성

  1. 생성된 PVC를 확인. PV와 PVC가 연결됐음을 의미하는 Bound확인.

  2. PV의 상태도 Bound로 바뀌었음을 확인

  3. 생성한 PVC를 볼륨으로 사용하는 디플로이먼트 오브젝트 스펙을 배포

  1. 생성된 파드를 확인
  1. 생성한 파드 중 하나에 exec로 접속

  2. 로드밸런서 서비스를 생성

kubectl expose deployment nfs-pvc-deploy --type=LoadBalancer --name=nfs-pvc-deploy-svc --port=80

NFS 볼륨을 파드에 직접 마운트하기

  1. nfs-ip.yaml 생성

  2. 설치한 PV와 PVC를 제외한 나머지 파드와 서비스를 삭제


3.4.4 스테이트풀셋

스테이트풀셋은 volumeClaimTemplates 기능을 사용해 PVC를 자동으로 생성할 수 있고, 각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있습니다. 그러나, 효율성 면에서 좋은 구조가 아니므로 요구 사항에 맞게 적절히 사용해야 함.

  1. 스테이트풀셋 생성

  2. 파드가 생성되는지 확인

  3. 로드밸런서 서비스를 작성 및 실행

  4. 로드밸런서 서비스 확인

  5. 스테이트풀셋의 파드 삭제


느낀점 및 응용할 부분

쿠버네티스 클러스터에서도 도메인 이름을 이용해 통신한다는 것을 처음 알게 되었다. IP주소로만 통신한다고 생각했는데, 어찌보면 당연한 일인데도 신기했다. 실무에서는 CoreDNS를 사용해서 도메인 이름을 이용해 통신하는 데에 사용한다고 하는데, IP 주소가 아니라 도메인 이름으로 통신 할 수 있으니 더 편리하겠다는 생각이 들었다.

디플로이먼트에 속한 파드를 삭제 하기 위해서는 상위 디플로이먼트를 삭제해야 파드가 삭제된다는 것을 알게 되었다.

우리가 서버가 터지면 aws에서 ec2 서버를 재시작하듯이 쿠버네티스에서도 그러한 문제가 발생했을 때 방안들이 많이 마련되어있는 것 같아서 좋은 것 같다. 예로들어 우리도 어떠한 문제가 발생해서 파드를 업데이트하거나 복구시킬 때 record 옵션로 히스토리를 이용해서 손쉽게 업데이트하거나 복구할 수 있겠다는 생각이 들었다.

profile
가보자고

0개의 댓글