Error rendering WebPanel: No renderer found for resource type: velocity Template contents: <meta name="ajs-keyboardshortcut-hash" content="$keyboardShortcutManager.shortcutsHash">
메타 데이터의 끝으로 건너뛰기
메타 데이터의 시작으로 이동

쿠버네티스 첫 걸음

  1. 클러스터 구성확인
    1. K8s 클러스터 환경의 정보 출력(macOS 미니쿠배
    2. 싱글 노드 K8s 클러스터에서 구성 노드 출력
      2. Role : 책과 다르게 control-plane 이 나오는 이유?
  2. 파드 실행
    1. 파드는 쿠버네티스에서 컨테이너를 실행하는 최소 단위.
      1.  kubectl : K8s 클러스터를 조작하기 위해 사용되는 커맨드
      2. run : 컨테이너 실행을 명령하는 서브 커맨드
      3. hello-world : 쿠버네티스 오브젝트의 이름(파드나 컨트롤러 등)
      4. —image=hello-world : 컨테이너의 이미지, 쿠버네티스에서는 파드 단위로 컨테이너가 기동되며 리포지터리명이 생략된 경우에는 도커 허브를 사용
      5. -it : 도커에서의 -it와 마찬가지로, -i는 키보드 표준 입력에 연결하고, -t는 유사터미널과 연결하여 대화 모드 설정. 옵션 ‘—restart=Never’인 경우에만 유효하며, 그 외에는 백그라운드로 실행.
      6. —restart=Never : 이 옵션에 따라 파드의 기동 방법 변경. Never는 직접 파드가 기동되며 Always나 OnFailure는 컨트롤러를 통해 파드가 기동
    2. 파드 실행 

    3. 파드목록 출력 


매니페스트와 파드

  1. 매니페스트 

    1. 매니페스트란 쿠버네티스의 오브젝트를 생성하기 위한 메타 정보를 YAML이나 JSON으로 기술한 파일이다.

    2. 매니페스트는 kubectl run nginx —image=nginx:lastest —restart=Never 를 실행한 것과 같은 의미를 가진다.

  2. 파드API

    1. apiVersion : v1 설정

    2. Kind : Pod설정

    3. Metadata : 파드의 이름을 지정하는 name은 필수 항목이며, 네임스페이스 내에서 유일한 이름이어야 함.

    4. Spec : 파드의 사양을 기술

  3. 파드의 사양

    1. Containers : 컨테이너의 사양을 배열로 기술

    2. initContainers : 초기화 전용 컨테이너의 사양을 배열로 기술.

    3. nodeSelector : 파드가 배포될 노드의 레이블을 지정.

    4. Volumes : 파드 내 컨테이너 간에 공유할 수 있는 볼륨을 설정

  4. 컨테이너 설정

    1. Image : 이미지의 리포지터리명과 태그

    2. Name : 컨테이너를 여러 개 기술할 경우 필수 항목

    3. livenessProbe : 컨테이너 애플리케이션이 정상적으로 동작 주인지 검사하는 프로브

    4. readinessProbe : 컨테이너 애플리케이션이 사용자의 요청을 받을 준비가 되었는지 검사하는 프로브

    5. Ports : 외부로부터 요청을 전달받기 위한 포트 목록

    6. Resources : cpu와 메모리 요구량과 상한치

    7. volumeMounts : 파드에 정의한 볼륨을 컨테이너의 파일 시스템에 마운트하는 설정. 복수 개 기술 가능

    8. Command : 컨테이너 가동 시 실행할 커맨드. args가 인자로 적용

    9. Args : command의 실행 인자

    10. Env : 컨테이너 내에 환경 변수를 설정

  5. 매니 페스트의 적용과 확인

  6. 파드를 만드는 매니페스트 적용 & 파드의 상태 목록
  7. 파드의 IP 주소와 파드가 배포된 노드 표시
  • 레이블 없음

7 댓글

  1. 김대겸

    Q&A 

    1. 싱글 노드 K8s 클러스터에서 구성 노드 출력 시, Role이 책과 다르게 control-plane 이 나오는 이유? - 김대겸
    2. vagrant up 원래 이렇게 속도가 오래걸리나요~? - 김대겸
    3. vagrant up issue (m1) - 김학건, 천정대, 서경진

  2. 김학건

    1. 사이드카 부분이 잘 이해가 안가는데 was를 초기 상태로 띄우고, 이후 작언을 다른 POD로 세팅한다는걸까요?

    2. pg215 처음에는 git clone으로 모든 컨텐츠를 다운받고, git pull로 변경점을 다운받는다
      → 레포지토리 같은 기능을 하는 것
    3. vagrant가 처음이라, 사용해보신 분들의 사용 경험을 듣고 싶어요

  3. 김학건

    1. 김학건

      실제 예시


      NAME STATUS ROLES AGE VERSION
      kube01 Ready control-plane,master,worker 16d v1.20.4
      kube02 Ready worker 13d v1.20.4
      kube03 Ready worker 13d v1.20.4
      kube04 Ready worker 13d v1.20.4

  4. 김대겸

    k8s Control Plane

    혹시 control plane 혹은 data plane 이란 용어를 들어보셨나요? 원래 network 분야에서 먼저 쓰였던 용어인데 이곳을 살펴보면 그 정의를 어느 정도 파악할 수 있습니다. k8s 에서의 control plane은 쉽게 풀어 얘기하자면 현재의 클러스터 상태를 사용자가 원하는 클러스터 상태로 끊임없이 조정해 주는 컨트롤 센터라고 보면 됩니다. control plane에는 실제 서비스와는 무관한 기본적인 k8s 클러스터의 운영과 관련 있는 컴포넌트들이 존재합니다.

    사용자가 원하는 클러스터 상태란 영어로 the desired state라고 표현합니다. 주로 사용자가 yaml 파일로 자신이 최종적으로 원하는 서비스(클러스터) 상태를 명세(manifest)해서 k8s object와 controller를 정의합니다. 이를 클러스터에 적용하면 k8s control plane에 있는 컴포넌트들이 사용자가 바라는 상태(사용자의 명세)대로 끊임없이 그리고 스마트하게 클러스터 상태를 맞춰 조정합니다.

    하나의 k8s 클러스터의 control plane에는 크게 다음과 같은 두가지 컴포넌트가 존재합니다.

    1. Master: 클러스터의 컨트롤 타워 역할을 하고, master node라고도 불립니다. 보통 작은 규모의 클러스터라면 vm 한대를 사용하고, HA(고가용성, high-availability) 클러스터에서는 vm 3대로 구성됩니다. Master 안에는 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 등의 하위 컴포넌트들이 존재합니다.

    출처 : Kubernetes 공식 홈페이지 (https://kubernetes.io)

    위 그림은 k8s 공식문서에서 가져온 k8s control plane 구성요소를 표현한 것입니다. 하나의 k8s 클러스터에 1개의 master node, 3개의 worker node가 존재합니다. 그리고, 각 worker node에 kubelet 과 docker system이 worker node 상에서 실행되고 있는 프로세스로 작게 그려져 있습니다.


    출처 : 

    https://medium.com/coinone/%EC%A2%8C%EC%B6%A9%EC%9A%B0%EB%8F%8C-kubernetes-%EC%9D%B5%ED%9E%88%EA%B8%B0-2-36e17a75d36c

    1. 김학건

  5. 김대겸

    yaml 사용방법

    참고링크 : 

    https://subicura.com/k8s/prepare/yaml.html#%E1%84%80%E1%85%B5%E1%84%87%E1%85%A9%E1%86%AB%E1%84%86%E1%85%AE%E1%86%AB%E1%84%87%E1%85%A5%E1%86%B8