쿠버네티스 CORE CONCEPT 2

Kubernetes 기본 Object

 

파드(pod)

• 쿠버네티스에서 실행되는 최소 단위, 독립적인 공간과 ip를 가진다

네임스페이스

• 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해서 관리하는 그룹

볼륨

• 파드가 사라지더라도 저장/보존이 가능한 비휘발성 저장 공간

서비스

• 파드는 유동적으로 생성 삭제 될 수 있기 때문에 접속 정보가 고정되지 않음. 이러한 파드에 안정적으로 접속 가능하도록 해주는 오브젝트

 

Kubernetes Scheduler

• Pod를 Node에 최적화하여 배치

아래 3가지 기준으로 Pod를 배치할 수 있다.

1. 컴퓨팅 자원(cpu, mem) 기준으로 Pod 배치
2. Node Selector (or Node Affinity)를 활용한 pod 배치
3. Taint & Tolerance를 활용한 Pod 배치

 

 

Node Selector (or Node Affinity)를 활용한 pod 배치

• 노드 label을 사용한 필터링 처리
• kubernetes.io/hostname : worker1 이라는 key value를 갖고있는 노드들에게 nginx를 배포하겠다. (worker1 번만 갖고있는 라벨이기 때문에 worker1만 배포가 됨.)
• nodeSelector가 여러개인 경우에는 and 조건이므로 모두 포함되는 조건들을 찾는다.
• yaml파일에 nodeName을 지정해서 pod를 다이렉트로 생성할 수 있지만 , label을 통해 아래와 같이 필터링 설정.
• 정상적으로 worker노드에 pod가 생성된것을 알 수 있다.

 

 

 

 

Taint & Tolerance 를 활용한 Pod 배치

• Taint란 노드에 활용되는 명령어, 특정 기능을 하는 명령어, 노드에 더러움을 묻히는것
• 깨끗한 pod는 깨끗한 node에만 스케쥴링이 된다.
• pod에 tolerance(인내)를 할 수 있으면, taint position=low에도 배치가 된다.
• kubectl edit node master 명령어를 쳐서 보게되면, taints 설정에 키 값이 설정되어있다.
• 따라서 pod가 master노드에 할당이 되기 위해서는 위 키 값을 가지고 있어야한다.
• 일반적으로 master는 taint 설정이 되어서 클러스터링 된다.

 

 

worker 노드에 taint 설정하기

• 아래와 같이 명령어로도 설정이 가능.
• kubectl taint nodes worker node=worker:NoSchedule
•                                            (key=value) : 속성  
• noScheduel은 현재 taint적용하는 기존의 pod는 냅두고, 이후에 생성되는 pod의 요청은 schedule하지 않는다는 내용.
• node에 taint설정이 되어있고, nginx 의 yaml파일에 노드샐럭터로만 설정이 되어있는 상태에서 pod를 생성했을때

• 위와같이 pending 상태만 무한정 대기…
• kubectl edit pod nginx 명령어로 pod 확인결과 untolerated taint 라는 오류 확인

• 위 내용들은 스케쥴러의 알고리즘에 의해 처리가 된다.

• nginx 에 tolerance 를 적용한 결과
• 정상적으로 pod 스케쥴 됨.

• 노드샐랙터로 만으로는 원하는 노드에 그룹단위로 배포하기에는 부족한 부분이 존재하여, taint tolerance, nodeAffinity를 통해서 스케쥴할지 범위를 조절하고, 노드들은 taint가 있거나 없으며, 필터링 조건을 유연하게 사용한다.

 

 

Container 및 Pod.yaml 응용 및 실습

파드 생성

kubectl apply -y pod-v2.yaml

 

파드 상세보기

kubectl get po -owide

 

파드 삭제

kubectl delete -f pod-v2.yaml

 

voluems

  -name

    hostPath

      path

        type을 Directory가 아닌 DirectoryOrCreate 로 변경해줌

 

 

kubeconfig를 본다

kubectl config view

 

 

kubectl이 바라보고 있는 namespace이다.

namespace를 변경하는 명령어

kubectl config set-context --current --namespace=practice

 

 

 

 

 

bind mount

호스트에 마운트하는 방법)

docker run --name mysql-v2 -e MYSQL_ROOT_PASSWORD=password -v /home/ubuntu/mysql-datas:/var/lib/mysql -d mysql

 

호스트에 mysql-datas:/var/lib/mysql -d mysql 여기에 보관한다

 

kubectl create ns practice

 

kubectl config set-context --current --namespace=practice

 

//도커허브에서 mysql을 받아서 컨테이너d와 컨테이너를 실행

docker run --name mysql-v1 -e MYSQL_ROOT_PASSWORD=password -d mysql

 

접속방법1)

docker exec -it mysql-v1 mysql -ppassword

 

접속방법2) 빈배쉬로 접속

docker exec -it mysql-v1 mysql /bin/bash

 

 

//mysql 컨테이너 레이어 접속 , 컨테이너 안에서만 유효하므로 docker로 띄운 mysql 제거시 해당 db 날라간다.

cd /var/lib/mysql

 

 

호스트에 마운트하는 방법) //절대 경로를 지정해야한다.

docker run --name mysql-v2 -e MYSQL_ROOT_PASSWORD=password -v /home/ubuntu/mysql-datas:/var/lib/mysql -d mysql

 

 

더미 데이터 생성

curl -L https://sample-videos.com/sql/Sample-SQL-File-1000rows.sql -o dump.sql

 

 

 

//초기 데이터베이스 생성 , dump.sql 파일을 컨테이너가 실행되면 가장먼 저 실행되는 디렉토리에 마운트 시켜준다. 호스트 → 도커

docker run --name mysql-v3 -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=samplevideo_db -v /home/ubuntu/dump.sql:/docker-entrypoint-initdb.d/dump.sql -d mysql

 

 

 

//마운트를 다중으로 지정.

docker run --name mysql-v4 -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=samplevideo_db -v /home/ubuntu/dump.sql:/docker-entrypoint-initdb.d/dump.sql -v /home/ubuntu/mysql-datas:/var/lib/mysql -d mysql

 

 

k exec -it mysql-v1 -- mysql -ppassword

 

 

echo password | base64 --encode

 

 

 

pod-v5-cm-data

kubectl create configmap dumpsql --from-file=/home/ubuntu/dump.sql

//파일 자체를 configmap으로 생성

 

 

pod로 바인드 마운트 설정방법

• pod에 볼륨(sql-data-volume)을 마운트하며, /home/ubuntu/mysql-datas 라는 host 디렉토리를 pod에 마운트한다.
• /home/ubuntu/mysql-datas 가 sql-data-volume 라는 이름으로 pod에 마운트 되었다.
• 컨테이너는 sql-data-volume을 /var/lib/mysql에 마운트한다.
• pod 생성 결과, 아래와같이 worker에 mysql-datas 폴더 생성

 

볼륨 2개 마운트

• pod-v4.yaml 실행 후 , worker노드에 sql.dump 다운
• 위와같이 설정이 가능하다.
• subPath
  • 컨테이너에 있는것을 쓰되, 호스트에 겹치는것만 오버라이드 해서 사용하겠다.

 

 

환경변수

• 각 pod마다 static하게 환경변수의 name, value가 지정되어있다면, 일괄적으로 변경하기에 어려움이 존재한다, 오른쪽 이미지와 같은 방법으로 번거로움을 해소할 수 있다.
• ConfigMap
  • 데이터를 key, value 형태로 보관하는 리소스 형태
  • kubectl apply -f comfigmap.yaml
  • kubectl get configmap 명령어로 조회 가능.
  • kubectl get cm -oyaml 명령어로 배포된 내역 확인.
    •  

• secretKeyRef
  • key, value형태이며, value를 base64 인코딩 상태로 전달받는다.
  •  

 

 

 

ConfigMap 형태로 마운트