[따배쿠 youtube] kubectl , container 동작 flow

kubectl [command] [TYPE] [NAME] [flags]

command = 자원에 실행할 명령 e.g) create, get ,delete ,edit 

TYPE = node,pod,service 자원의 타입이 들어간다.

NAME = 자원의 이름 

e.g) kubectl get pod webserver -o wide 

 

명령어 자동완성 되게 하는법

source <(kubectl completion bash)

source <(kubeadm completion bash)

echo "source <(kubectl completion bash)" >> ~/.bashrc

echo "source <(kubeadm completion bash)" >> ~/.bashrc

앞에서 이미 설치과정에서 진행했다.

 

kubectl describe nodes "name" = 특정노드에 자세한 정보를 확인

kubectl api resources 를 통해 약어정보를 확인 할 수 있다

 

 

- system5 계열 -- BSD계열  option의 - 수에 따라서 나뉜다.

kubectl run webserver --image=nginx:1.14 --port 80 

성공적으로 nginx webserver를 master node 에 띄웠다. curl , elinks 명령어를 통해 확인이 가능하다.

 

kubectl create deployment mainui --image=httpd:latest --replicas=3 

아파치 최신 버전을 띄워본다 이것을 3개 띄워줘라. 여러개를 띄우니 create deployment 명령어를 쓰는 것이다.

이제 3개의 mainui 아파치 서버가 도는 것을 확인할 수 있다.

kubectl get pod webserver -o yaml == yaml 의 형태로 출력해준다.

 

kubectl exec webserver -it -- /bin/bash  == webserver nginx 로 접속하되 bash 로 실행해줘라는 거다.

그 다음 기본으로 있는 index.html 에 "SMLEE web" 을 리다이렉션을 통해 덮어 씌워서 바꾸고 밖에 나와서 확인 하면 바뀐것을 확인할 수 있다.

master node에서 pod 안쪽에 접속해서 마음대로 할 수가 있다.

 

port forward 가능하다. 현재 localhost:8080 으로 들어오면 webserver의 port 80 으로 보내준다. 세션을 복제해서 curl을 실행해 보면

잘 접속이 되는것을 확인 할 수 있다.

 

kubectl edit 명렁어를 통해 pod의 설정을 변경해줄 수 있다.

replica 를 3개에서 5개로 막 수정한 상태이다. 아직 available하지 않다.

 

kubectl run webserver --image=nginx:1.14 --port 80 --dry-run -o yaml > webserver-pod.yaml 

실행가능한지 상태를 yaml로 보여줘~

명렁어를 통해 yaml을 만들어준다. 이미 같은 이름으로 돌아가고 있는 pod 가 존재하기에 --dry-run 옵션을 붙여준 것이다.

기존것들을 delete 를 통해 다 지우고 새롭게 create 와 -f 옵션을 통해서 만든 yaml 파일을 통해 pod를 실행 시켰다. 

 

 

 

1. image 들을 Docker Hub 에 올린다. private public 둘다 존재한다. 이 예시의 경우에는 public 

2. yaml 이나 CLI 의 kubectl 을 통하여 master node에게 request를 보낸다. 

3. 해당 request를 master node api sever에서 받은후에 Scheduler 에게 어떤 worker node가 available한지 물어본다.

4. available 한 worker node 의 kubelet 에게 현재 띄우고싶은 app 을 말해준다.

5. workder node의 kubelet 이 docker daemon으로 하여금 Docker Hub에서 해당 container를 띄워준다. 이런 컨테이너(들)을 pod라는 단위로 관리한다.

 

 

etcd 저장소는 key value 타입으로 저장한다. worker node 의 kubelet (daemon) 에는 cAdvisor 를 통해서 컨테이너 기반의 상태정보를 수집해서 master node의 etcd저장소에 전달한다. 

API가 kubectl create webserver~ 같은 명령어를 처리해주는 API Server이다. etcd의 저장소의 정보와 자신의 command를 scheduler 에게 보내준다. scheduler는 가능한 worker node를 알려준다. 이때 Scheduler는 etcd저장소에 저장된 pod정보들을 참고한다.

API Sever가 worker node 의 kubelet에게 예)nginx 1개 를 실행해달라고 요청한다. kubelet이 docker daemon으로 하여금 DockerHub에 있는 nginx image를 자신의 worker node에서 컨테이너를 실행시켜준다. 이떄 실제로 컨테이너를 실행시켜주는 녀석은 Docker다. 

이떄 worker node가 고장났다면 master node에 있는 controller가 상태 유지를 위해 API Sever로 하여금 1개가 고장 났으니 보충 해줘야한다고 요청을 보낸다. 그러면 다시 위의 동작들을 반복한다.

컨테이너와 컨테이너 간의 통신을 지원해주는 CNI (이런것들을 Add ons program) 가 존재한다. 나의 경우는 weave.