가상환경 플랫폼 실행 단위

가상머신: Instance

도커: Container

쿠버네티스: Pod

 

Containers in Pod

기본적으로 하나의 Pod 당 1개의 컨테이너를 갖게 하는 걸 권장한다. 사이드카로 보조 컨테이너를 넣어 2개의 컨테이너를 돌아가게 하는 경우도 있지만, 3개부터는 권장하지 않는다.

 

쿠버네티스에서는 NAT 통신 없이도 Pod 고유의 IP + 컨테이너 별 Port 주소를 통해 각 컨테이너에 접근할 수 있다. 같은 Pod 내의 컨테이너들은 사실 상 모두 같은 IP 주소를 가진 상태이기에 서로 localhost와 개별 포트넘버를 통해 네트워크 접근을 한다.

 

같은 Pod 내의 컨테이너들은 반드시 동일 노드에 할당되며 동일한 생명 주기를 가진다. Pod 삭제 시, 그 Pod 내의 모든 컨테이너가 전부 같이 삭제된다. 또한 모두 같은 볼륨에 연결되어 있어 파일 시스템을 기반으로 서로 파일을 주고 받을 수 있다.


[labels] in [metadata]

 

# 원래 상태

kubectl get pod mynginx -o yaml

 

# 라벨 추가

kubectl label pod mynginx hello=world

 

# 변경점 확인

kubectl get pod mynginx -o yaml

 

# 라벨 확인

kubectl get pod mynginx --show-labels

 

# run label이 다른 또 하나의 Pod 생성

kubectl run yournginx --image nginx

 

# key가 run인 Pod 출력

kubectl get pod mynginx -l run

-l = label

 

# key가 run, value가 mynginx인 Pod 출력

kubectl get pod mynginx -l run=mynginx


# 워커 노드1에 라벨 부여

kubectl label node k8s-w1 disktype=ssd

 

# 워커 노드2에 라벨 부여

kubectl label node k8s-w2 disktype=hdd

 

# 워커 노드3에 라벨 부여

kubectl label node k8s-w3 disktype=hdd

 

# disktype에 대해 노드들의 라벨 확인

kubectl get node --show-labels | grep disktype

 

# 새로 만들 Pod(node-selector)의 yaml 파일 생성

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: ssd

# nodeSelector 프로퍼티로 인해 이 Pod는 disktype이 ssd인 노드에서 실행될 것이다.

 

# node-selector Pod 생성

kubectl apply -f node-selector.yaml

 

# Pod가 어느 노드에서 실행되고 있는지 확인 : disktype을 ssd로 지정해뒀던 k8s-w1에서 실행되고 있을 것이다.

kubectl get pod node-selector -o wide

 

# node-selector.yaml 수정

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: hdd

# disktype이 hdd인 노드는 2개이기 때문에 쿠버네티스 마스터가 알아서 판단해서 할당한다.

 

# yaml 파일 재적용

kubectl apply -f node-selector.yaml

 

# Pod가 어느 노드에서 실행되고 있는지 확인 : k8s-w2, k8s-w3 중 하나일 것이다.

kubectl get pod node-selector -o wide


[command], [args] in [spec]

 

# vi editor 사용해보기 - i로 편집 모드 진입 → 수정 후 esc키 → :wq 입력으로 저장 & 나가기

vi cmd.yaml

# cmd.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cmd
spec:
  restartPolicy: OnFailure
  containers: 
  - name: nginx
    image: nginx
    # 실행명령
    command: ["/bin/echo"]
    # 파라미터
    args: ["hello"]

# 여기서 눈여겨 봐야 하는 부분은 restartPolicy인데, Always, Never, OnFailure 3가지 값을 줄 수 있다.

# Always: Pod 종료 시 항상 재시작(default), Never: 재시작을 시도하지 않음, OnFailure: 실패 시 재시작

# 그런데 여기서 echo 명령은 웹 서버와 다르게 실행 후 종료되기 때문에 OnFailure로 주어야 하는 것.

 

# Pod 생성

kubectl apply -f cmd.yaml

-f = file

 

# 로그 확인 : 만약 restartPolicy를 Always로 했다면 무수히 많은 hello가 찍힐 것이다.

kubectl logs -f cmd

-f = flow


Volume Mounting

 

# volume.yaml 파일 생성

vi volume.yaml

# volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume
spec:
  containers: 
  - name: nginx
    image: nginx

    # 컨테이너 내부의 연결 위치 지정
    volumeMounts:
    - mountPath: /container-volume
      name: my-volume
  
  # host 서버의 연결 위치 지정
  volumes:
  - name: my-volume
    hostPath:
      path: /home

# [spec]-[containers]-[volumeMounts] 부분에 컨테이너 내부의 경로와 이름을 잡고,

# [spec]-[volumes] 부분에 노드(호스트 서버) 쪽의 경로와 이름을 잡는다.

 

# Pod 생성

kubectl apply -f volume.yaml

 

# volume Pod 안으로 접속해 연결시켜준 위치를 ls 명령어를 통해 확인한다.

kubectl exec volume -- ls /container-volume

 

# 호스트 서버의 디렉토리에서 목록 출력

ls /home


[resources]-[limits]-[cpu], [memory] in [spec] for Resource Management

 

# limits.yaml 파일 생성

vi limits.yaml

# limits.yaml
apiVersion: v1
kind: Pod
metadata:
  name: limits
spec:
  restartPolicy: OnFailure
  containers: 
  - name: mynginx
    image: python:3.7
    command: [ "python" ]
    args: [ "-c", "arr = []\nwhile True: arr.append(range(1000))" ]
    resources:
      limits:
        cpu: "500m"
        memory: "1Gi"

# 파이썬 이미지를 사용해 파이썬 코드를 작성하고 수행하는 컨테이너를 만들 수 있다.

 

# limits Pod 생성

kubectl apply -f limits.yaml

 

# watch 명령어의 지속적인 체크로 STATUS 변화 확인 : Running → OOMKilled

watch -d 'kubectl get pod limits'


[livenessProbe] in [spec] for Health Check

 

# yaml 파일 생성

vi liveness.yaml

# liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers: 
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /live
        port: 80

# 상태 확인 및 자가치유 부분은 확인 과정이 복잡하기 때문에 단순히 위의 속성을 주게 되면

#정상적으로 작동하는지 실시간으로 체크하고 자가치유를 수행한다는 것만 알면 될 것 같다.


2개의 컨테이너 실행 (Sidecar)

 

# yaml 파일 생성

vi second.yaml

# second.yaml
apiVersion: v1
kind: Pod
metadata:
  name: second
spec:
  containers: 
  - name: nginx
    image: nginx
  - name: curl
    image: curlimages/curl
    command: ["/bin/sh"]
    args: ["-c", "while true; do sleep 5; curl -s localhost; done"]

# containers 아래에 name이 두 개가 있는 모습. 하나의 Pod 안에 두 개의 Container를 생성하는 것이다.

# 아래의 명령어는 5초마다 로컬호스트로 시그널을 보내며, 응답을 받지 못하면 에러가 뜨게 되는 코드이다.

 

# Pod 생성

kubectl apply -f second.yaml

 

# 생성 확인. 그리고 다른 Pod들과는 다르게 second는 READY 컬럼에 2개가 있는 것을 볼 수 있다.

kubectl get pod

 

# second 컨테이너의 (nginx 컨테이너에 대한) 로그를 출력

kubectl logs second -f -c nginx

-f = flow

-c = container

 

# Pods 확인 명령어

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\sort


Init Container

 

# yaml 파일 생성

vi init-container.yaml

# init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-container
spec:
  restartPolicy: OnFailure
  containers: 
  - name: busybox
    image: k8s.gcr.io/busybox
    command: [ "ls" ]
    args: [ "/tmp/moby" ]
    volumeMounts:
    - name: workdir
      mountPath: /tmp
  initContainers:
  - name: git
    image: alpine/git
    command: ["sh"]
    args:
    - "-c"
    - "git clone https://github.com/moby/moby.git /tmp/moby"
    volumeMounts:
    - name: workdir
      mountPath: "/tmp"
  volumes:
  - name: workdir
    emptyDir: {}

# 메인 컨테이너가 실행되기 전에 초기화 컨테이너에서 미리 git pull을 받아서

# 컨테이너끼리의 공유 공간인 emptyDir volume(/tmp)를 통해 git 레파지토리를 전달한다.

 

# Pod 생성

kubectl apply -f init-container.yaml

 

# initContainer 로그 확인

kubectl logs init-container -f -c git

 

# 메인 컨테이너(busybox) 로그 확인

kubectl logs init-container


Delete all Pods

kubectl delete pod --all

'IT > Kubernetes' 카테고리의 다른 글

Kubernetes Components & Operation  (0) 2021.10.29
[Lab] Kubernetes Pod YAML file / Namespace  (0) 2021.10.28
Configure of Kubernetes on VMware (Windows10)  (0) 2021.10.28
Kubernetes 기능과 용어  (0) 2021.10.27

 


 

아래 사진은 쿠버네티스의 전체적인 프로세스 구조이다.


Control Plane Components

 

API Server

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

 

etcd

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

etcd에 대한 자세한 정보는, 공식 문서를 참고한다.

 

Scheduler

노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다

 

Controller Manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.

논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

이들 컨트롤러는 다음을 포함한다.

  • 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
  • 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
  • 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
  • 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

Node Components

 

kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

 

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

 

Cloud controller manager

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.

다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.

  • 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
  • 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
  • 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것

자료 출처: https://kubernetes.io/ko/docs/concepts/overview/components/

 

쿠버네티스 컴포넌트

쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.

kubernetes.io


Operation


자료 출처: Pod | 쿠버네티스 안내서 (subicura.com)

 

Pod

Pod이 무엇인지 알아보고 기본적인 사용법을 익힙니다. YAML을 이용하여 설정파일을 작성합니다.

subicura.com

 

'IT > Kubernetes' 카테고리의 다른 글

[Lab] Kubernetes Pod & YAML file  (0) 2021.10.29
[Lab] Kubernetes Pod YAML file / Namespace  (0) 2021.10.28
Configure of Kubernetes on VMware (Windows10)  (0) 2021.10.28
Kubernetes 기능과 용어  (0) 2021.10.27

yaml 파일을 통한 Pod 생성/수정

# yaml 파일 생성
nano mynginx.yaml

# yaml 파일 작성

apiVersion: v1
kind: Pod
metadata:
    name: mynginx
spec:
    containers:
    - name: mynginx
      image: nginx


# yaml 파일 적용
kubectl apply -f mynginx.yaml

-f = file

# Pod 생성 확인 (뒤에 -n 등 속성을 안 붙이면 default 네임 스페이스로 잡는다)
kubectl get pod


# yaml 파일 확인
kubectl get pod mynginx -o yaml

-o = output


# 웹에서 불러온 yaml 파일로 Pod 생성
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/simple-pod.yaml

 

# Pod 생성 확인
kubectl get pod


# yaml 파일 확인
kubectl get pod nginx -o yaml


# yaml 파일 수정

nano mynginx.yaml

apiVersion: v1
kind: Pod
metadata:
    labels:
       hello: world
    name: mynginx
spec:
    containers:
    - name: mynginx
      image: nginx:1.17.2


# yaml 파일 재적용 (Configured 출력 확인)
kubectl apply -f mynginx.yaml

# yaml 파일 확인
kubectl get pod mynginx -o yaml

# yaml 파일 재적용 시도 (Unchanged 출력 확인)
kubectl apply -f mynginx.yaml


네임 스페이스의 명령어 속성으로써의 활용

# default 네임 스페이스

kubectl get pod -n default

-n = namespace

 

# 쿠버네티스가 동작하는 데에 반드시 필요한 것이 들어있는 네임 스페이스

kubectl get pod -n kube-system


# kube-system 네임 스페이스 위에서 mynginx-ns Pod 돌리기

kubectl run mynginx-ns --image nginx -n kube-system

 

# Pod 확인

kubectl get pod mynginx-ns -n kube-system

 

# 다시 지워서 원 상태로 만들기

kubectl delete pod mynginx-ns -n kube-system

 


kubectl Commands

https://subicura.com/k8s/guide/kubectl.html

 

기본 명령어

kubectl의 기본적인 사용법을 익힙니다.

subicura.com

 

 

'IT > Kubernetes' 카테고리의 다른 글

[Lab] Kubernetes Pod & YAML file  (0) 2021.10.29
Kubernetes Components & Operation  (0) 2021.10.29
Configure of Kubernetes on VMware (Windows10)  (0) 2021.10.28
Kubernetes 기능과 용어  (0) 2021.10.27

+ Recent posts