YAML: data를 나타내는 파일 형식으로 JSON, XML과 동일하지만 다른 표현 방법이라고 생각하면 편함

 

[data 표현 방법]

1. Key:Value

    key:(스페이스)value

 

2. Arrays/Lists

    a:

      - sss

    * 대쉬가 있어야하며, ordered 형식임

 

3.Dictionary/Map

    a:

      b: 2

    c: aesd

    * 무조건 앞에 스페이스 있어야 하며, 같은 레벨로 기입해야 함

    * identation이 더 있다는 것은 상위의 속성이라는 의미이기 때문에 확인 필수 (python 유사)

    * unordered 형식임

 

4. comment

    #: comment

    * 주석 표기 방법

 

 

위의 3개 항목을 혼합해서 사용할 수도 있음

마지막 Health 항목은 List와 Dictionary를 혼합한 경우로, 모든 표기 방법에 익숙해지는 게 좋다

k8s 기본 실습, 나는 Windows 환경에서 수행했고 설치 방법은 아래 링크를 참조하면 된다.

 

k8s설치: https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/

 

Install and Set Up kubectl on Windows

Before you begin You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.30 client can communicate with v1.29, v1.30, and v1.31 control planes. Using the latest compatible version of kubectl helps avoid

kubernetes.io

 

minikube 설치: https://minikube.sigs.k8s.io/docs/start/?arch=%2Fwindows%2Fx86-64%2Fstable%2F.exe+download

 

minikube start

minikube is local Kubernetes, focusing on making it easy to learn and develop for Kubernetes. All you need is Docker (or similarly compatible) container or a Virtual Machine environment, and Kubernetes is a single command away: minikube start What you’ll

minikube.sigs.k8s.io

 

[Windows 환경변수 설정 방법]

고급 시스템 설정 보기 > 고급 > 환경변수 > 시스템 변수 내 Path 선택 후 편집 > 찾아보기 > minikube 설치 경로 추가

 

 

[설치 후 수행]

minikube 수행 시 시작된 모습 확인 가능

 

minikube 수행되면 VirtualBox에서 자동 생성된 모습 확인 가능
expose 명령어를 통해 외부 접근 가능하도록 설정한 모습
nginx image 통해 pod 수행
describe 명령어를 통해 pod 상세 내역 확인 가능

 

 

[실습 구조]

Minikube Node 안에 nginx container를 가진 pod를 만든 구조

 

[참고]

node = master & worker node

pod = container를 실제 지니고 있는? 것이라 할 수 있음

CKA 획득을 하려 Udemy 쿠버네티스 강의를 등록했는데,

쿠버네티스 지식이 없으면 Beginner 코스가 있는데 이를 듣고 CKA 강의를 들으면 된다.

 

나는 쿠버네티스에 대한 지식이 거의 없어 Beginner부터 등록했고, 열심히 수강해보려 한다 :)

 

[Kubernetes 정의와 등장 이유]

- Kubernetes = k8s 라고도 불리며, 이는 k와 s 사이에 8개 알파벳이 있어 이렇게 표기

- 서비스에 필요한 웹서버, DB에서 호환되는 OS, 필요한 라이브러리 버전 다양화의 이슈로 인해 등장

- k8s = container orchestration 기술 = container 배포, 개수 조절 등 기능

 

[Docker의 구조]

- Docker = lxc container

  >> 하위 level 컨테이너라 설정 어려움

- 구성: OS kernel + software set 

  >> 단인 HW에서 여러 SW가 돌아가는 것

  >> SW의 경우 각 OS를 구별하게 하는 다양한 요소를 지니고 있음

  >> Linux 커널에 SW set이 달라 Ubuntu, Debian, Red hat 등으로 구별되는 것(= 다른 Linux 배포판)

       = Windows는 커널을 공유하지 않기 때문에 Linux 위의 container로 실행 불가능

       왜? Docker는 sw 부분에서 나누는 것이고 아래는 같아야 하기 때문

       VM은 커널 단계부터 분리하기 때문에 Linux, Window 같이 가능

 

[가상화의 장점]

- 기존 dev > ops로 이동시 관련 dependency 등 전달해야 하나 docker image 전달로 ops에서 쉽게 설정 및 배포 가능

 

[Node]

- Node = k8s가 설치된 vm 혹은 hw, 그 안에 여러 container 띄워짐

  >> Node 죽으면 container 다 죽음 = 서비스 장애 발생, 따라서 2개 이상이어야 하고 이런 Node 집합을 Cluster라 부름

- Master Node = k8s 설치된 또 다른 노드로 cluster 관리하는 역할

- Worker Node = 실제 서비스 등이 올라간 Node

 

[k8s 구성 요소]

- 실제 구성 요소 = 설치할 때

- API 서버 = front-end 같은 서버

- etcd = Cluster 관리에 필요한 데이터 저장

- Scheduler = 새로 배포된 container 찾아 Node에 할당

- Controller = 죽은 자원 있는지 확인 후 해당 자원 새로 올릴지 결정

- Container Runtime = container 실행을 위한 sw, e.g: Docker

- kubelet = 각 Node에서 실행되는 Agent, container가 Node에서 실행되는지 확인하는 역할

(빨강은 Mater-Node, 파랑은 Worker-Node)

 

[기본 명령어]

kubectl run = cluster에 app 배포

kubectl cluster-info = cluster 정보를 보는데 사용

kubectl get nodes = node 모두 열거

 

 

[Docker vs Container d]

- cri(container runtime interface) : 어떤 container runtime이든 지원(oci 사양 충족하는 경우)
- oci(open container initiative): imagespec과 runtimespec으로 구별

  >>imagespec: image 만드는 spec = image 빌드되는 사양, runtimespec: container runtime이 개발되어야 하는 사양

- dockershim: oci 기준 전 개발된 docker가 k8s 사용 가능하도록 지원하는 임시 툴

  >> 이를 위한 관리가 불필요하여 관련 지원 중단, 그 부분이 container c

- oci 기준 준수하는 container d, 이는 docker와 별개이며 ctr이라는 명령어 사용 (디버깅 위해서만 사용하는 명령어)
- nerdctl: container d에서 사용하는 명령어로 기존 docker 명령어와 유사, 신규 기능에 접근 가능한 장점이 있음

- crictl: cri와 상호작용을 위함 = k8s와 관련된 것으로 볼 수 있음, container runtime 관리 및 디버깅에 사용

 

+ Recent posts