[MLOps] Kubernetes CKA자격증 공부 (2)

 

ETCD Cluster

우리가 kubectl명령어로 가져오는 정보값들은 전부 ETCD Cluster를 통해서 가져오는것. 당연히 스케일링이나 삭제 추가 Pod등등 모든것이 ETCD에 저장된다. 현재 minikube를 통해서 설치했기 때문에 etcd-minikube라고 표시된다.

kubectl get pods -n kube-system

kube-apiserver

kubectl 명령어는 kube-apiserver를 통해서 작동하게된다. 즉 kubectl get nodes같은 명령어는 다음과 같이 작동하게 된다.

1. 명령어를 받고
2. 먼저 kubectl명령하는 사용자를 검증
3. 명령어가 유효한지 확인
4. 명령어가 유효하다면 명령어에 따라서 해당 명령실행(kubectl get nodes같은 경우엔 ETCD Cluster로 향하게 된다)

만일kubectl명령어가 worker node까지 가야하는 작업이라면 위와같은 순서로 동작하게된다

kube-controller-manager

Watch Status

Remediate(교정하다) Situation

 

ReplicaSets

두가지 종류가 있는데 ReplicaSets, Replication Controller가 있다. 이 두가지는 기능면에서는 동일하지만 다음과 같은 차이점이 있다.

• ReplicaSets은 Replication Controller의 새로운 버전(ReplicaSets이 뒤에나온것)
• ReplicaSet은 Replication Controller보다 풍부한 pod selector 표현식을 갖는다
  • Replication Controller는 단순히 같은지 틀린지만 비교한다면
  • ReplicaSets은 포함여부 표현식도 갖는다
  • 즉, Replication Controller는 하나의 label 환경만 갖을수있는반면에, ReplicaSets은 다수의 label환경을 가질수있다

 

다시 돌아와서, 만약에 replicas 개수를 조정하고싶다면 어떻게 해야할까? 두가지 방법이 있다

 

- 기존에 create한 yaml파일에서 replicas 개수를 수정하고 다음과 같은 명령어를 실행

 

kubectl replace -f replicaset-definition.yaml

 

- 만들었던 yaml파일에서 scale 명령어를 사용

kubectl scale --replicas=6 -f replicaset-definition.yaml

- 현재 띄워져있는 replicaset 이름을 이용해서 scale명령어 사용(대괄호 안에 있는건 설명)

kubectl scale --replicas=6 replicaset[type] myapp-replicaset[replicaset name]

namespace

우리가 여태까지 kubectl명령어를 이용해서 만든 pod, replicaset, deployment는 모두 default환경에서 만들어진것이다. 만약에 default환경이 아니고 따로 지정된 환경에 만들고싶다면 어떻게 해야할까? 다음 명령어를 사용하거나 yaml파일에 명시를 해주면된다

kubectl create -f myapp-pods.yaml --namespace=dev

또는 yaml파일의 metadata section에 namespace를 넣어주면된다

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
  labels:
    app: nginx
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx

이렇게 dev라는 환경에서 만들어진 pod정보를 얻고싶다면 다음과 같이 namespace로 환경을 지정해줘야한다

kubectl get pods --namespace=dev

만약에 dev라는 환경을 default환경으로 바꿔주고싶을때는

kubectl config set-context $(kubectl config current context) --namespace=dev

이렇게 명령어를 처리하면 get pods뒤에 굳이 --namespace=dev를 붙히지않아도 자동으로 dev환경에있는 pod을 불러읽게된다

 

아. 참고로 현재 환경에서 올려져있는 namespace 리스트는 pod을 얻는것처럼

kubectl get namespace

Imperative vs Declarative

여태까지 yaml파일에 object를 설정하고 실행을하여 object를 생성하는 방식을 Declarative 방식이라고 한다.

이와 반대로 커맨드라인에서 object를 생성하는 방식을 Imperative 방식이라고 한다.

 

ex1. pod네임을 nginx-pod이라고하고 image를 nginx:alpine으로 생성한다할때

kubectl run nginx-pod --image=nginx:alpine

 

ex2. redis 이름을 가진 pod을 redis:alpine 이미지 및 라벨중 tier=db라는 형식을 갖게끔 생성할때

kubectl run redis --image=redis:alpine --labels="tier=db"

ex3. redis pod 을 연결해주는 service를 설정. service 이름은 redis-service, 포트넘버는 6379로 설정

kubectl expose pod redis --port=6379 --name redis-service

ex4. webapp 이라는 deployment를 띄우고 image는 kodekloud/webapp-color 를 사용하고 replicas 갯수는 3으로 설정

kubectl create deployment webapp --image=kodekloud/webapp-color --replicas=3

Taint & Toleration

개발환경을 만들다가 "특정 노드에만 내가원하는 컨테이너를 생성하면 어떨까" 라는 상황이 올때가 있다. (물론 난 아직 여기까지 해본적은없다)

 

약간 c++에서 class느낌이 나는 기능이였다. 이번꺼는 신기해서 문제 풀이 전체를 정리해본다.

 

- 특정노드에 Taint 기능이 켜져있는지 확인하는 방법

kubectl describe node node1

명령어 이후에 다음과 같은 부분에서 확인할수있다

Taint 설정안되어있는 Node

Taint 설정이 되어있는 Node

 

- Taint기능이 활성화된 Node만들기(이름은 node01이라고 하고, key는 spary, value는 mortein, effect는 NoSchedule로 설정)

kubectl taint node node01 spray=mortein:NoSchedule

- 자, 이제 간단한 nginx 이미지를 가진 mosquito Pod을 만들어보자

kubectl run mosquito --image=nginx

해당 pod의 상태를 확인해보자

Pending상태로 멈춰있다. 왜그럴까?

 

현재 띄워져있는 두개의 Node들의 상태를 보면 모두 Taint 기능이 활성화되어있다.

1. node-role.kubernetes.io

2. mortein

즉, 현재 Pod을 띄워서 정상적으로 돌게끔하려면 Taint의 설정에 맞게끔 올려줘야한다. 또는, 현재 Taint걸려있는 Node의 설정을 삭제해줘야함.

 

- 만일 mortein이라는 node에 팟을 띄우고싶다면 어떻게 해야할까?

다음과같이 yaml파일을 작성하면된다. 주의해야할점은 tolerations 섹션이 추가된점

apiVersion: v1
kind: Pod
metadata:
  name: bee
spec:
  containers:
  - image: nginx
    name: bee
  tolerations:
  - key: spray
    value: mortein
    effect: NoSchedule
    operator: Equal

자 이제 bee라는 Pod은 정상적으로 동작하는지 확인해보자.

이렇게 bee는 mortein이라는 Taint Node에 띄어지게됐다.

 

kubernetes apiVersion list

apiVersion을 설정해줘야할때가 있는데

apiVersion 이 어떤게 있는지 확인해보려면 다음과 같은 명령어가 필요함

kubectl api-versions

Statics Pod

statics pod의 위치를 찾기 위한 방법정리

먼저 kubelet관련된 프로세스 정보를 가져온다

- aux명령어는 ps명령어에서 a, u, x 를 합쳐서 쓰는 명령어이다

a: 터미널에 종속되지 않은 모든 프로세스 출력

u: 프로세스의 소유자를 기준으로 출력

x: BSD계열로 프로세스의 소유자를 기준으로 출력

ps -aux | grep kubelet

해당 명령어를 치게되면 다음과같은 부분이 보일텐데

--config=/var/lib/kubelet/config.yaml

이 파일안에 내용을 cat으로 읽어보면, 다음과같은 텍스트가 발견된다

staticPodPath: /etc/kubernetes/manifests

즉, 현재 Static Pod의 위치는 위와같이 설정되어있는것을 알수있다

 

Pod yaml로 가져오는방법

만일, pod이 올라가 있는상태이고, 해당 pod을 선언하기위한 yaml파일을 삭제했을경우. 올라와있는 pod을 이용해서 바로 yaml파일로 가져올수있다. (예시, orange라는 pod이 올라와있는상태)

kubectl get pod orange -o yaml > /root/orange.yaml