Kubernetes(k8s)

쿠바네티스를 한마디로 정의하면 Container Orchestraion tool 이라고 표현할 수 있다.
이를 조금더 풀어서 쓴다면 서로 다른 환경에서 동적으로 container 수를 증감하면서 실행하는 방법이다.

그렇다면 왜 쿠바네티스가 필요할까?
-> 많은 수의 Contrainer들을 자동으로 관리해주기 위해서!

Kubernetes 특징

서비스 디스커버리와 로드 밸런싱: DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너 노출
스토리지 오케스트레이션: 원하는 저장소 시스템을 자동으로 탑재
자동화된 롤아웃 & 롤백: 자동 배포 및 복구
자동화된 빈(컨테이너) 패킹: 각 컨테이너가 필요로 하는 RAM과 PCU지정시 알아서 배정
자동화된 복구: 컨테이너 다시 시작 및 복구
시크릿과 구성관리: 중요한 정보 관리

Kubernetes 용어정리

쿠바네티스의 다양한 기능들을 설명하기전에 우선 용어들을 하나하나 알아보고 가보자

Node(Master Node & Worker Node)

Master Node(Control Plane): 클러스터에 관한 전반적인 결정을 수행한다

• API Server: 모든 요청(UI, API, CLI)을 처리하는 역할

• contoller-manager: 다양한 컨트롤러(deployment, replicaset) 관리

• scheduler: 상황에 맞게 적절한 worker node 선택

• etcd: 클러스터 내의 데이터를 담는 저장소
  

• Worker Node: 컨테이너화된 애플리케이션을 동작하고 유지

• Kubelet: master node와 통신하며 pod들의 상태를 관리

• Kube-proxy: pod로 연결되는 네트워크들을 관리(DNS기반)

• Pod: 컨테이너화된 애플리케이션 그룹(아래 추가 설명)

Pod

• 쿠바네티스의 최소 실행 단위(schedule, deploy하는 최소 단위)
• 적어도 한개 이상의 container를 포함
• Network namespace를 공유
• 동일한 Pod내의 container들은 운명을 같이한다(다같이 소멸)

Service

Pod들을 통해 실행되고 있는 애플리케이션을 네트워크에 expose(노출)시키는 가상의 컴포넌트
Service의 종류

• Cluster IP: 클러스터 내부에서 통신하는 Internal IP 주소(private IP)
• External Name: 클러스터 내부에서 외부로 접근할 때 사용
• Node Port: 클러스터 외부에서 내부로 접근할 때 특정 포트를 할당하는 방식
• Load Balancer: 네트워크 트래픽을 여러 서버나 리소스에 고르게 분산시키는 장치

Namespace

동일한 클러스터 내에서 리소스를 논리적으로 분리하고 그룹화하여 다양한 사용자 및 프로젝트가 충돌 없이 독립적으로 사용할 수 있도록 하는 가상 클러스터

• Permanent IP 주소 사용
• 분리(Pod와 Service의 분리, 네트워크와 리소스 분리)

Ingress

클러스터 외부에서 내부로 접근하는 요청을 어떻게 처리할지 정의해둔 규칙들의 모음

Volume

Pod의 일부분으로 정의되며 파드와 동일한 라이프사이클을 갖는 디스크 스토리지

ReplicaSet

Pod의 숫자를 보장해주는 Controller

Deployment

Pod와 ReplicaSet에 대한 선언적 업데이트를 제공

Statefulset

상태를 유지해야 하는 애플리케이션을 배포하고 관리할 때 사용

Kubeadm, Kubelet, Kubectl

쿠바네티스를 처음 설치할 때 위의 3개를 모두 설치한 기억이 있을 것이다. 사실 쿠바네티스를 사용할 때 kubectl명령을 대부분 사용하긴하지만 나머지 용어들도 정확히 이해하고 넘어가면 좋다.

Kubeadm

클러스터를 구성하기 위한 다양한 기능을 제공
명령어

• kubeadm init: control plane을 초기화 하는 명령어
• kubeadm join: worker node를 초기화하고 cluster에 가입시키는 명령어
• kubeadm reset: init + join으로 생성된 클러스터 설정을 모두 초기화하는 명령어
• kubeadm toekn: control plane과 worker node사이의 인증값 확인하는 명령어

Kubelet

위에서도 설명했듯이 control plane과 통신하며 pod들의 상태를 관리한다

주의: control plane에서도 pod를 실행시킬 수 있으므로 control plane에서도 kubelet을 설치

Kubectl

쿠바네티스 클러스터와 통신하는 CLI(Command Line Interface)
대부분의 명령어는 kubectl을 사용해서 작동
명령어

• kubectl create: 새로운 리소스(service, deploy등)를 생성하기 위한 명령어

kubectl create pod my-pod --image=nginx

• kubectl apply: 리소스의 현재상태를 파일(YAML, JSON)에서 지정된 원하는 상태와 비교하여 필요한 변경사항을 적용

create vs apply: create는 새로운 리소스 생성, apply는 기존 리소스의 수정 및 관리
꿀팁: create대신 대부분의 경우 apply를 사용할 수 있지만 apply는 반드시 파일이 필요

• kubectl descirbe deployment
  deplyment(특정 배포)에 대한 정보 → 상세 정보

• kubectl get
  리소스의 상태를 확인하는 명령어 (간단하게 확인)

Kubectl get deployments(deploy)

kubectl get deploy <deployment name> -o yaml

-> deployment의 현재 상태를 YAML형식으로 출력

kubectl get pods -o -wide

-> 더 자세한 정보

• kubectl expose
  특정 리소스를 외부에 노출시키기 위해 서비스를 생성

kubectl expose pod my-pod --port=80 --target-port=8080 --name=my-service

expose vs create service: 두 명령어 모두 서비스를 생성하는 데 사용되지만, expose는 간단하고 빠르게 서비스를 생성하고자 할 때, create service는 더 많은 제어가 필요할 때 사용

• kubectl delete
  리소스를 삭제

쿠바네티스 YAML 파일

k8s component(service, deploy, pod등)의 configuration을 기재한 선언문
사실 YAML파일 대신 kubectl의 위의 명령어들로 실행이가능하지만 YAML파일로 한번에 빠르고 쉽게 실행가능해서 편의성을 위해 사용

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Kind: 오브젝트 종류(Pod, Service, Deployment)
Metadata: 리소스의 라벨, 이름등을 지정
Spec: 각 컴포넌트에 대한 상세 설명. replicas의 개수 == pod의 개수
status:yaml파일에는 기록하지 않지만 쿠바네티스가 자동으로 생성해서 자신의 원하는 상태가 되도록 현재 상태를 기술. 지속적으로 update되며 self-healing(자동복구)시 사용

동작예시

1. 쿠바네티스 Pod를 관리하기 위해 YAML 파일 작성
2. kubectl명령어를 통해 해당 명령을 쿠버네티스 클러스터에 적용
3. 이때 YAML 명령이 kube-apiserver에서 kubelet으로 이동
4. Pod에 변경사항 적용

마치며

해당 정리 내용은 인터넷 및 강의록을 기반으로 작성하였음을 밝히며, 오류가 존재할 수 있음을 밝힙니다. 감사합니다.