데이터센터프로그래밍18(1)

18-Nodes and Pods

🔵 Basic Objects in k8s(=쿠버네티스)

• Node
• Cluster
• Container
• Pod
• Deployment
• Ingress

🔵 Container

• 자신이 만든 프로그램들, database, 관련된 환경변수들을 묶어서 Container에 집어넣었음
• Container 1개가 이미지로 부터 만들어져서 작업을 할 수 있음
• 이는 컴퓨터의 메모리구조가 bite로 되어있다는 의미이며, 거대한 상용 어플리케이션의 경우에는 작은 최소단위가 될 수 있음
• "이 보다 더 나은 개념은 없을까?" 하여 쿠버네티스는 Pods이라는 개념을 생각함

🔵 Pods (1)

• 쿠버네티스는 개별 컨테이너 보단 묶여있는 것을 보고자 함
• ex. Front-end service, UI service, database을 포함한 3개가 있다고 쉽게 이야기를 했지만, "Front-end" 사용자를 받아주는 프로그램도 1개의 컨테이너로 실행되면 다행이지만, 작동이 안 될 수도 있음
• 🙂 따라서, Front-end들 & back-end들 & databases로 이야기를 하고 싶은 것임
• ex. Front-end의 경우, 1개의 컨테이너로 실행된다는 보장은 없기 때문에 Front-end의 기능을 모두 묶어서 Pods라고 칭하고, Front-end 기능 안에 있는 Pods의 안을 보면, 컨테이너가 여러개 있을 수 있음
• 🙂 따라서, 컨테이너는 기계적 의미에서의 단위인데, Pods는 컨테이너 보다 좀 더 유의미하다고 볼 수 있음
• 🦜 정리
  : Front-end & back-end & data-logic이 있으면, 각각 하나의 컨테이너로 동작할 수 있으면 좋지만, 복잡해지고, modual화 되면 Front-end 구성하는 것들 & back-end 구성하는 것들 & data를 처리 기능들로 부를 수 있고, 이들의 묶음을 Pods라고 함
  : 컨테이너는 재료, 기계적인 입장에서 하나의 기능이고, Pods는 좀 더 유의미한 하나의 개념적 기능이며, 이를 구현하기 위해 컨테이너 1개 or 여러개가 들어갈 수 있음
• 🙂 따라서, 컨테이너는 기술적으로 아래에 있으며, 서비스를 만드는 사람은 1개의 마이크로서비스를 구성할 때, 컨테이너가 2-3개 라고 하더라도 개념적으로 한 덩어리를 Pods라고 함
  

🔵 Pods (2)

• 도커에서는 컨테이너를 많이 다뤘지만, 쿠버네티스에서는 Pods이 유의미한 basic building이 되며, Pods 여러개의 컨테이너들로 구성되어 있음
• 후에 Cluster을 만들어서 유의미한 someting(사용자에게 제공할 어플리케이션)을 제공할 것임
• Pods은 제공해야 할 컨테이너들이 기능적으로 포함되며 (multiple or single 컨테이너), storage가 필요하고, 하나의 network IP 안에 속해있음
• 🔔Pods 단위로 어플리케이션이 동작을 한다는 것이 핵심!!

🔵 Pods Networking

• 컨테이너들을 하나의 Pod 담았을 때, Pod은 IP adress 하나를 공유함
• 각각의 Pod은 Unique(특별)한 IP address를 갖으며, Pod은 운영체제 간의 network namespace를 공유함 (하나의 운영체제 위에 떠있는 것인데, IP address는 공유함)
• 각각은 서로 다른 network port를 가짐
• 하나의 pod 안에 담겨져 있는 container들은 localhost에 port number를 줌으로써 서로 연결을 할 수 있음
• 하나의 pod 안에 담겨져 있는 것들은 IP address를 공유하고, 각각의 port number가 다르며, 각각 pod 안에 있는 container 끼리 통신할 경우에 서로 IP address를 알 필요없이 localhost에 port number만 주면 됨(단, pod 밖에 있는 container의 경우 : IP address에 대한 고민 필요)

🔵 Nodes

• docker machine에 해당됨
• 쿠버네티스에서 nodes는?
  : (1) machine; (2) VM(가상); (3) physical machine
• docker machine 위에서 container를 실행한 것처럼 쿠버네티스의 nodes 위에서 service를 돌릴 것인데, 이를 Pods의 집합이라고 함
• label(라벨)은 docker에서는 많이 사용하지 않지만, 쿠버네티스에서는 많이 사용함(Pods을 구분하고, 관리를 용이하게 하기 위해 라벨을 사용함)
• 🙂 container들을 묶어서 유의미한 Pods을 만들고, Pods은 VM, physical machine들 node 위에서 동작을 할 것이며, 이들을 묶어서 쿠버네티스가 관리할 것임 (이때, 주로 사용하는 명령어들이 있음 kube-ctl)또한, docker에서 docker-daemon처럼 쿠버네티스 안에 많은 어플리케이션을 실행되고 있음
• docker-daemon만이 아닌, kubelet & kube-proxy를 사용하게 될 것임

🔵 Clusters (1)

• Node을 묶어서 하나의 관리체계 안으로 총칭하는 것을 Clusters라고 함
• Pods이 동작하고 있는 Node들이 모임 (ex. Pods이 동작하기 전에 이미 machine들이 묶여 운동장(Clusters)을 만듦-node가 붙을수록 Clusters의 CPU, RAM이 증가함)
• 🙂 따라서, Clusters는 Node의 집합체라고 함

🔵 Clusters (2)

• 쿠버네티스도 docker와 마찬가지로 storage가 붙음
• Clusters에 필요한 disk를 붙이는 작업도 할 수 있음

🔵 Clusters (3)

• container와 docker-swarm만 있었던 것에 비하면, container와 container가 묶인 Pods들이 동작하는 Node(docker machine과 같음)들이 묶여 있는 Clusters
• 어플리케이션을 띄울 때, Clusters를 운동장으로 삼아서 그 위에 container applications를 띄우는 작업을 수행 할 것임
• 🙂 따라서, 쿠버네티스는 기술적인 개별 container 보단, service에 의미가 있는 측면에서 여러개로 나눈 것을 의미
• Node들이나 Clusters가 public internet part는 아님(네트워크 방어가 되어 있음)
• Clusters가 있으면, Clusters를 담당하는 master가 본인에게 속해있는 Node, 그 안에 있는 Pods에게 일을 시킴
• 🙂 따라서, Node의 상황을 잘 봐서 어느 Node 위에 Pods이 올라가야 할지에 대한 scheduling을 하고, "scaling up & down", "upgrade"에 대한 문제를 docker-swarm보다 훨씬 더 풍부하고, 많은 기능을 안정적으로 제공함

🔵 Deployment (1)

• Node or Clusters는 작업이 이루어지기 위한 운동장이며, 그 위에 이루는 작업을 Pods로 함
• 실제로 Pods 통해서 일을 하기 위해 Pods 몇개가 필요한지(몇개가 동작할지)를 알아야 하는데, 이를 판단할 수 있음
• ex. yaml-file, docker-file, docker-compose가 어떤 목적인지를 묻는다면, docker-compose의 경우, 하나의 어플리케이션을 구성하는 서비스들, 그 서비스들이 실현되는 이미지들을 기술을 하고 여기에 자신이 필요한 개수를 쓴후에 docker-compose를 실행하면, 3개의 이미지로 부터 각각의 서비스들이 만들어지는데, 각각의 container 마다 어플리케이션을 실행함 (쿠버네티스의 경우, Deployment(=도입한다)라고 함)
• 쿠버네티스에게 Deployment를 부탁함

🔵 Deployment (2)

• 프로그래머가 쿠버네티스에게 본인이 희망하는 바를 dedired state(유지되는 인프라)가 되길 바람 (쿠버네티스가 dedired state를 만들고, 유지함)
• 프로그래머는 desired state(본인이 희망하는 상태)를 쿠버네티스에게 전달하는 것을 Deployment라고 함
• 쿠버네티스는 현재상태가 actual state인데, 현재상태가 desired state(본인이 희망하는 상태)에 도달할 수 있도록 해줌
• ex. 4개의 pod가 실행되야 하는데 1개가 죽었다면? 쿠버네티스는 프로그래머가 필요없이 스스로 죽은 1개를 새롭게 만들어서 유지해줌
• 쿠버네티스에서 desired state(본인이 희망하는 상태)를 생성 & 유지하는 것을 Deployment controller이라고 함
• example: kubectl create deployment --help

# create a new deployment named my-dep taht runs the busybox image
# busybox image를 기반으로 해서 deployment를 생성하고 유지해주세요~ 그 이름은 my-dep라고 해주세요
kubectl create deployment my-dep --image=busybox

🔵 Deployment (3)

• busybox는 작은 Unix 위에 SW가 올라가 있음(*명령이 많다는 것은 Unix위에 돌아가는 프로그램이 많다는 의미)
• busybox는 개별적으로 수행되는 Unix의 명령들을 하나의 file에다가 모아놓았기 때문에 프로그램은 1개인데, 명령들은 하나의 프로그램에서 실행하는 것임
• ex. 리눅스, 안드로이드, FreeBSD와 같은 Unix 운영체제 위에서 busybox가 설치되면 다양한 기능들을 할 수 있는데, 프로그램 1개로 동작시키니 요구하는 자원은 작음 (embedded operating systems)

🔵 Ingress (1)

• docker는 각각의 컨테이너들이 만들어지는 등 전부 컨테이너에 국한되었지만, 쿠버네티스는 node가 Clusters로 묶여야 의미가 있음 (ex. Clusters로 고객에게 요청이 올 것이므로 외부와의 통신은 Clusters에게 있음)

🔵 Ingress (2)

• (1) HTTP 프로토콜을 통해서 접속을 하면, port가 받아서 정보를 기반으로 Clusters에게 전달
• (2) load balancing 할 수 있음
• (3) SSL termination (=암호를 푸는 통신 방식, ex:서비스에 접속하는 사람들이 암호를 풀어서 각각 처리하도록 Clusters에게 전달함)
• (4) viretual hosting
  : 1개의 컴퓨터가 2개 이상의 domain (즉, 웹주소를 가지고 있음)
• 🙂 따라서, 쿠버네티스는 서비스를 만들고, 유지관리 + 외부의 네트워크 관련 기능도 제공함

🔵 Activate Katacoda (실습)

• 사이트 접속 : https://www.katacoda.com/

lshw
# 디스크 공간표시
df -h
# 파일 내용을 보여줘~
cat /ect/os-release 
hostnamectl
uname --help
uname --all

🔵 Activate Minikube over Katacoda (실습)

minikube version
minikube start --wait=false
kubectl version
kubectl cluster-info
kubectl get nodes
kubectl get all

🔵 Create Example HTTP Serveice Deployment (실습)

kubectl create deployment first-deployment --image=katacoda/docker-http-server
kubectl get pods
kubectl get events
kubectl config view
kubectl get all

🔵 Create HTTP Serveice to External Network (실습)

kubectl expose deployment first-deployment --port=80 --type=NodePort --name=my-services

🔵 Verify Exposed HTTP Serveice Port Number (실습)

kubectl get services my-services
export PORT=$(kubectl get svc first-deployment -ogo-template='{{range.spec.ports}}{{if .nodePort}}{{.nodePort}}{{"\n"}}{{end}}{{end}}')
echo "Accessing host01:$PORT"
curl host01:$PORT
kubectl get all

🔵 Access HTTP Service Deployment (실습)

Press '+'
Press "Select port to view on Host 1"
Type port number at $PORT
Press "Display Port"

🔵 Activate Dashboard (실습)

Press '+'
Press "Open New Terminal"
minikube addons enable dashboard
kubectl apply -f /opot/kubernetes-dashboard.yaml
kubectl get pods -n kube-system -w

🔵 Access Dashboard (실습)

Select tap "Dashboard" or
https://{CHECK-YOUR-DOMAIN at Step4}.environments.katacoda.com/

🔵 Remove All (실습)

kubectl delete service my-services
kubectl delete service first-deployment
kubectl delete deployment first-deployment
kubectl delete -f /opt/kubernetes-dashboard.yaml
kubectl get all
minikube stop

💗 할일

• Activate Kubernetes for Docker
• Install Minikube
• Install Dashboard
  : https://kubernetes.io/ko/docs/tasks/access-application-cluster/web-ui-dashboard/