k8s- 2

쿠버네티스 클러스터 구성

• control plane(master node)

• 워커 노드들의 상태를 관리하고 제어
• single master
• multi master(3, 5개의 master nodes)

• worker node

• 도커 플랫폼을 통해 컨테이너를 동작하며 실제 서비스 제공

---

• CNI : 플란넬, 칼리코, 이브넷(weavenet) (내부 네트워크)
• 도커설치 ⇒ 쿠버설치 환경설정 ⇒ kubeadm/kubectl/kubelet 설치 ⇒ control-plane 구성 ⇒ worker node

● 쿠버네티스가 필요하게 된 이유

-컨테이너화 증가
-컨테이너를 사용한 어플리케이션이 증가하였다

• (개발하는데 컨테이너가 편리하기 때문에)

-컨테이너를 관리 할 수 있는 플랫폼에 대한 필요성 증가

-클라우드의 증가

• 과거에는 On Premise 환경에서 직접 서버를 관리했다. (기본적으로 클라우드보다 어렵다)

-On Premise의 문제점

• 확장성 (Scalability) 제한적이다
• (예시: 만약 사용량이 증가하면 직접 물리적 서버를 사와서 설치까지 해야한다)

배포 관리 방법이 기본적으로 어려웠다.

• (예시: 모든 물리적 서버에 소프트웨어같은거 설치 똑같이 해줘야 한다)
  • 클라우드가 보편화되면서, 애플리케이션을 클라우드에서 더 유연하게 분산되고 확정되어야 하는 필요성 증가
  • 클라우드에서는 배포/확장 관리 해주는 플랫폼만 있다면 더 유연하게 확장될 수 있기 때문에...
  • 배포/확장 할 수 있는 플랫폼에 대한 필요성 증가

● 쿠버네티스의 특징

-자동 배포, 확장 (오케스트레이션)

• Auto Scaling : 트레픽 양에 따라 각 서비스의 리소스를 자동으로 변경하는 기능.

-수직 오토 스케일링 (Vertical Pod Autoscaler - VPA):

• 리소스의 크기를 동적으로 조절하여 트래픽의 증가 또는 감소에 대응한다.
• 리소스의 성능을 높이는 것 이다.

-수평 오토 스케일링 (Horizontal Pod Autoscaler - HPA):

• 리소스의 수를 동적으로 조절하여 트래픽의 증가 또는 감소에 대응한다.
• 리소스의 갯수를 늘리는 것 이다.

-Auto Healing

• 서비스에 장애나 이상 상태에 대응하여 자동으로 복구하는 기능.
• 서버(노드) 와 컨테이너를 주기적으로 체크하고, 문제가 발생하면 해당 상태를 복구하려고 한다.

-Node Auto Healing:

• 노드(물리적 서버) 중 하나에 문제가 생기면, 클러스터는 해당 노드를 자동으로 감지하고 대체 노드를 만들어서 애플리케이션의 중단 없이 계속 실행될 수 있도록 한다.

-Pod Auto Healing:

• Pod(컨테이너)가 이상 상태에 빠졌을 때 해당 Pod을 다시 시작하거나 대체 Pod을 생성하여 서비스를 유지한다.

---

쿠버네티스 용어

▶kubectl : 쿠버네티스의 명령줄 툴

• kubectl를 사용하여 쿠버네티스의 상태를 확인하거나 원하는 상태로 변하게 명령어를 입력할 수 있다

▶노드 (Node) : 컴퓨터

• 쿠버네티스의 노드는 컨테이너를 실행하는 물리 서버 또는 가상 머신이다

▶클러스터 (Cluster)

• 쿠버네티스의 클러스터는 컨테이너를 실행하는 노드의 집합이다.
• 여러 컴퓨터를 묶어서 하나의 시스템처럼 동작하도록 한다. 즉 컴퓨터의 집합

▶클러스터 구성요소 : 쿠버네티스 클러스터는 컨트롤 플레인(마스터 노드)과 컴퓨팅 머신(워커 노드)

• 두 개의 부분으로 구분.
  • 마스터 : 관리자
  • 워커노드: 실행
    • 마스터 노드가 죽으면 클러스터를 관리할 노드가 없기에 이성적으로는 3개 이상의 마스터 노드를 사용하는 것이 권장된다.
    • 워커 노드 : 배포되는 애플리케이션의 크기와 요구사항에 따라 다르지만 이성적으로는 수십 개에서 수백 개의 워커 노드를 갖는 클러스터가 일반적이다.

▶네임스페이스 (Namespace) : 클러스터 내의 논리적인 분리 단위이다.
@네임스페이스가 필요한 이유

• 규모가 큰 시스템의 클러스터를 분리하고 싶을 때 네임스페이스를 사용하면 좋다.
• 동일한 클러스터에서 여러 팀이나 프로젝트가 서로 간섭 없이 독립적으로 동작할 수 있다.
• 각 네임스페이스는 독립된 가상 클러스터처럼 작동하며, 같은 이름의 리소스도 서로 다른
  네임스페이스에서 격리되어 사용된다.

▶파드 (Pod) : 컨테이너의 집합

• Pod는 쿠버네티스에서 컨테이너를 실행하는 가장 기본 단위이다. (컨테이너를 배포하려면 Pod을
  생성해야 한다.)
• Pod는 하나 이상의 Container 로 구성된다.
• 웬만한 어플리케이션은 하나 이상의 container를 동시에 실행해야 된다.
  • (Ex. 웹 서버 컨테이너와 데이터베이스 container → 2개의 컨테이너를 포함하는 Pod)

▶네트워크 공유: Pod에 포함된 모든 Container는 동일한 하나의 IP 주소를 갖는다.

• Pod의 Container가 서로 통신하기 위해, Pod는 Node IP와 별개로 고유 IP를 할당 받는다
• 서로 localhost 로 통신 가능

▶Volume 공유: Pod의 Container들은 Volume 을 공유하여 사용하는 것이 가능하다.

• Volume이란, Container가 삭제되어도 독립적으로 남아 있는 데이터를 의미한다.

▶컨트롤 플레인 (Control Plane) : 쿠버네티스의 노드를 제어하는 프로세스들이 모여있는 곳이다.

• 클러스터의 상태를 모니터링하고, 애플리케이션을 배포하고, 노드를 관리하는 데 사용되는 컴포넌트 세트입니다.

▶컨트롤 플레인 구성 요소
-kube-apiserver (API 서버)
-etcd (분산 저장소)
-kube-controller-manager (컨트롤러 관리자)
-kube-scheduler (스케줄러)

• @ kube-apiserver (API 서버): kube-apiserver를 아주 쉽게 비유하면 "중앙 통제실"이다.

  • 중앙 통제자로서 조직 내에서 의사소통을 중앙에서 관리하고, 중요한 결정을 하는 역할을 한다.
  • 클러스터와 상호 작용하는 모든 구성 요소(kubectl, etcd, scheduler, ...etc)는 kube-apiserver를 통해 통신한다.
  • kube-apiserver는 이름 그대로 API 웹 서버이다.
  • RESTful 서버로 동작한다.
  • API 엔드포인트 제공한다 → HTTP나 HTTPS를 통해 개발자는 서버에 접근해서 작업 할 수 있다
  • 기본적으로 HTTP나 HTTPS로 통신한다.

• @ etcd (분산 저장소): etcd를 쉽게 비유하면 "클러스터의 저장소"이다

  • 클러스터에서 사용되는 모든 데이터가 etcd에 key-value 형태로 저장된다.
    • (Ex. 클러스터에 어떤 노드가 몇 개나 있는지와 같은 정보가 etcd에 저장된다)
  • Cluster에 문제가 생겼더라도 etcd에 문제없이 백업되어있다면 Cluster를 복구하는것이 가능하다.
  • etcd의 데이터가 유실되어버리면 Cluster가 사용하는 모든 리소스(ex.컨테이너)들을 활용할 수 없게 된다.

• @ kube-scheduler (스케줄러): kube-scheduler를 아주 쉽게 비유하면 "창고 관리자"이다.

  • 여러 종류의 물건(파드)들이 창고로 들어오는데 각각은 특정 크기와 무게를 가지고 있다.
  • kube-scheduler는 창고 관리자로서, 새로운 물건(파드)이 창고에 들어올 때 이 물건을 어느 섹션에 어떻게 배치할지 결정한다.
  • 마스터 노드에 위치해있다.
  • Pod를 어떤 워커 노드에 배치할지 결정하는 역할을 한다.
  • kube-scheduler는 다양한 정책과 알고리즘(리소스 요구, 제약 조건, 사용자 정의 정책 등)을 사용하여 최적의 노드를 찾아내 Pod를 배치한다.

• @ kube-controller-manager (컨트롤 매니저):
  • kube-controller-manager를 아주 쉽게 비유하면 클러스터의 "경비원"이다.
  • 경비원은 건물을 안전하게 유지하기 위해 다양한 작업을 수행한다. (출입 통제, 비상 상황 대응, 정기적인 점검 및 유지보수 등)
  • kube-controller-manager의 역할은 클러스터의 상태를 지속적으로 모니터링하고, 개발자가 지정한 상태로 유지하기 위해 다양한 작업을 수행합니다
  • kube-controller-manager에는 다양한 컨트롤러가 있다

---

*kubectl 명령어

• [root@master ~]# kubectl logs --help
  [root@master ~]# kubectl get nodes
  [root@master ~]# kubectl get nodes -o wide
  [root@master ~]# kubectl describe node master.example.com

kubectl ( 확인 명령어 )

• Kubernetes 클러스터 내의 노드들의 상태를 확인
  ( kubectl get nodes )
• 등록된 노드들의 상세 정보를 넓은(wide) 형식으로 출력
  ( kubectl get nodes -o wide )
• 해당 노드의 자원 상태, 이벤트, 조인된 파드, 용량, 라벨, 애너테이션 등의 상세 정보를 확인 ( kubectl describe node master.example.com )

---

*파드 생성 CLI

• [root@master ~]# kubectl run webserver --image=nginx:1.14 --port 80

• [root@master ~]# kubectl get pods
  [root@master ~]# kubectl describe pod webserver
  [root@master ~]# kubectl get pods -o wide ⇒ 어느 노드에 생성 되었는지 확인

• [root@master ~]# curl http://10.44.0.1 ⇒ webserver IP
  [root@master ~]# kubectl get pods webserver ⇒ 여러개의 파드중에서 확인 하고 싶은거 .

• [root@master ~]# kubectl create deployment mainui --image=httpd --replicas=3
  ⇒ run 은 하나만 생성 , create deployment 는 여러개 생성

• [root@master ~]# kubectl describe deployments.apps mainui

• [root@master ~]# kubectl get pod webserver -o wide
  [root@master ~]# kubectl get pod webserver -o yaml
  [root@master ~]# kubectl get pod webserver -o json

파드 생성 ( CLI 방식 )

• 파드 생성
  ( 이미지와 포트 지정, kubectl run webserver --image=nginx:1.14 --port 80 )
• Kubernetes 클러스터 내 현재 실행 중인 파드들의 목록을 표시
  ( kubectl get pods )
• Kubernetes 클러스터 내에서 특정 파드인 "webserver"의 상세 정보를 출력
  ( kubectl describe pod webserver )
  • node2에서 동작 중 ( 로드 밸런서 역할 )
  • curl을 통해 호출

deployment mainui 삭제

• [root@master ~]# kubectl get deployments
  [root@master ~]# kubectl delete deployments mainui

파드 생성 ( create, create와 run의 차이점 : create는 여러 개 생성 가능 )

• Kubernetes 클러스터 내에 "mainui"라는 이름의 디플로이먼트를 생성하고, 이를 위한 파드를 관리 ( kubectl create deployment mainui --image=httpd --replicas=3 )
• JSON 형식으로 "webserver" 파드의 정보를 출력
  ( kubectl get pod webserver -o json )
• yaml 형식으로 "webserver" 파드의 정보를 출력
  ( kubectl get pod webserver -o yaml )
  • kubectl delete deployments mainui

---

[root@master ~]# kubectl run echoserver --image="k8s.gcr.io/echoserver:1.10" --port=8080

• [root@master ~]# kubectl get pods

*생성된 파드로 접근
[root@master ~]# kubectl port-forward svc/echoserver 8080:8080
⇒ 외부 로컬PC에서 접속하기 위해서 포트포워딩 하기

• 

파드 생성 후 포트 포워딩 및 접속 확인

• Kubernetes 클러스터 내에 "echoserver"라는 이름의 파드를 생성하고, 지정된 이미지를 사용하여 해당 파드를 실행
  ( kubectl run echoserver --image="k8s.gcr.io/echoserver:1.10" --port=8080 )
• "echoserver" 파드를 외부에 노출시키기 위해 서비스를 생성
  ( po: pod, kubectl expose po echoserver --type=NodePort )
• type과 port 확인 ( kubectl get services )
• 로컬 pc에서 접속하기 위한 포트 포워딩
  ( kubectl port-forward svc/echoserver 8080:8080 ( svc/echoserver: echoserver라는 이름의 서비스 ) , 포트 포워딩을 안해도 curl로 접속 가능 )
• 

---

-기존 마스터 에서

• [root@master ~]# kubectl delete pod echoserver
  [root@master ~]# kubectl delete service echoserver
  [root@master ~]# kubectl get pods
  [root@master ~]# kubectl get services

pods 삭제

• kubectl delete pod echoserver ( pod 삭제 후 service 삭제 )
• kubectl delete service echoserver
  • kubectl get pods, kubectl get services로 확인

---

새로운 마스터 창에
[root@master ~]# kubectl get pods -o wide --watch ⇒ 실시간 확인

pods 실시간 확인

• 실시간으로 pods를 확인 ( kubectl get pods -o wide --watch )

---

#vi example.yaml

• 

• [root@master ~]# kubectl create -f example.yaml
  [root@master ~]# kubectl get deploy
  [root@master ~]# kubectl get pods
  [root@master ~]# kubectl get rs ⇒ replicas: 1 개수 확인

pods 생성 (yaml 파일)

• vim example.yaml
• 지정된 이미지를 이용해서 배포하는 yaml 파일 작성
• Kubernetes 클러스터에 새로운 리소스를 생성하기 위해 YAML 파일을 사용
  ( -f: 파일 지정 옵션 , kubectl create -f example.yaml )
• 배포 확인 ( kubectl get deploy )
• kubectl get rs ( 갯수 확인 )

*야물파일로 만들고 실행된 deploy pod 개수를 늘려 보기 = scale

• [root@master ~]# kubectl scale deploy deploy-exam --replicas=5 ⇒ 5개가 되고,
  [root@master ~]# kubectl scale deploy deploy-exam --replicas=3 ⇒ 으로 하면 다시 3개가 됨.
  [root@master ~]# kubectl get pod -o wide ⇒ 설치된 노드 확인

pods 생성을 늘렸다 줄였다 할 수 있다 (scaling)

• --replicas 옵션을 이용해서 스케일링 ( kubectl scale deploy deploy-exam --replicas=5 )
  • kubectl get pod -o wide
• kubectl scale deploy deploy-exam --replicas=3
  • kubectl get pod -o wide

삭제

• kubectl delete deploy deploy-exam

*명령어

*파드 생성 두가지 방법

• CLI 명령으로 생성 run 은 1개만 생성 / replicas 로 여러개도 생성 가능
• ymal 파일로 생성 : 1개 또는 여러개 생성 가능
  생성한 후 에 scale 명령을 통해서 개수를 확장 / 축소 가능.

*외부에서 접속하기 위해 포트포워딩 .

---

*Pod 실행하고 생성된 컨테이너 안으로 접속 후 설정 변경 하고 TEST

• 이미지: httpd / 이름 : testui / create 명령으로 3개 생성
  • 생성된것 확인 ( 자세하게 확인 : describe / wide )
  • 확인 된 내용을 yaml 파일로 저장

이미지를 지정하여 배포 ( deploy )

• kubectl create deployment testui --image=httpd --replicas=3
  • kubectl describe deployments testui ( 자세하게 확인 )
  • kubectl get deployments testui -o wide
  • kubectl get deployment -o yaml ( 저장해서 배포 가능 )

삭제

• kubectl delete deployment testui

-외부접속 테스트

• curl IP

-컨테이너 안으로 진입

• [root@master ~]# kubectl exec webserver2 -it -- /bin/bash
  • ⇒ 접속이 안되면 wide로 설치된 노드 확인 하고 해당 노드에서 접속 해보면 됨.
  • root@webserver2:/# cd /usr/share/nginx/html/
    root@webserver2:/usr/share/nginx/html# echo "05-08 TEST WebServer" > index.html
    root@webserver2:/usr/share/nginx/html# exit
• [root@master ~]# curl 10.44.0.3
  05-08 TEST WebServer
• [root@master ~]# kubectl logs webserver2 ⇒ 로그 확인

컨테이너 진입 (pod)

• kubectl run webserver --image=nginx:1.14 --port 80
• kubectl exec webserver -it -- /bin/bash
  • cd /usr/share/nginx/html/ (컨테이너로 진입 후)
  • echo "05-08 TEST WebServer" > index.html
• 빠져나와서 curl 10.36.0.6, kubectl logs webserver로 확인

-포트 포워딩 후 접속

• [root@master ~]# kubectl port-forward webserver2 80:80

포트 포워딩

• kubectl port-forward webserver 8080:80 ( 포트 포워딩 )
• 포트 포워딩 접속 확인

삭제

• kubectl delete pod webserver ( 삭제 )

[root@master ~]# kubectl run webserver2 --image=nginx:1.14 --port 80
Error from server (AlreadyExists): pods "webserver2" already exists

• ⇒ 똑같은 이름이 있으면 이미 실행중이라 에러~

*야물파일을 만들어 놓고 실행 하면 생성이 됨.

• #kubectl create -f testserver.yaml

yaml 파일을 이용해서 pod 생성

• kubectl create -f testserver.yaml

---

*쿠버네티스 아키텍처

*마스터용 컴포넌트

• etcd (분산 저장소): etcd를 쉽게 비유하면 "클러스터의 저장소"이다
• controller-manager (컨트롤 매니저): 클러스터의 "경비원"이다.
• scheduler (스케줄러): kube-scheduler를 아주 쉽게 비유하면 "창고 관리자"이다.

*노드 용 컴포넌트

• kubelet / kube-proxy(가상네트워크 관리에 사용) / 컨테이너 런타임(컨테이너 실행 시키는 역할)

*애드온( CNI )

• 네트워크 : weave, calico, flanneld [ 마스터와 노드들을 연결 해주는 ]

*NameSpace : k8s 네임스페이스

• 클러스터 하나를 여러개의 논리적으로 나누어서 사용하는거 ⇒ 관리에 편리함.
• 하나의 클러스터나 네임스페이스를 여러팀이 공동으로 함께 사용 가능.
• 용도에 따라서 앱을 구분하면 좋음.
• base 네임스페이스는 기본으로 하나 존재함.

---

*네임스페이스 생성

[root@master ~]# kubectl get namespaces
[root@master ~]# kubectl get pod --namespace default
[root@master ~]# kubectl get pod -n default

네임 스페이스

• kubectl get namespace로 네임 스페이스 확인
• kubectl get pod --namespace default( kubectl get pod -n default ) 로 확인

---

*CLI 방법으로 네임스페이스 생성

-야물파일 생성을 하면 기본적으로 default namespaces 에 지정, 생성됨
#cat > nginx.yaml ( 컨트롤 D로 저장 / 종료 )

• 

• [root@master ~]# kubectl create -f nginx.yaml
  [root@master ~]# kubectl get pods -n default

• [root@master ~]# kubectl create namespace orange --dry-run -o yaml
  ⇒ 만드는 방법을 보여줌.

  • 
  • -> 내용을 수정
  • 

• [root@master ~]# kubectl create namespace orange --dry-run -o yaml > orang-ns.yaml

yaml파일 생성 시 기본적으로 default namespace에 지정

• vi nginx.yaml
• 네임스페이스 지정 안함
• kubectl get pods --namespace default로 확인

네임 스페이스 생성

• 네임 스페이스 생성 방법
  ( orange라는 이름의 네임 스페이스를 요약해서 생성 ,
  kubectl create namespace orange --dry-run -o yaml )
• kubectl create namespace orange --dry-run -o yaml > orange-ns.yaml
  ( 네임 스페이스 생성 내용을 orange-ns.yaml 파일에 저장 )
• cat orange-ns.yaml로 확인

네임 스페이스 수정

• nano orange-ns.yaml ( 수정 )
• 필수 내용 제외하고 제거
• kubectl create -f orange-ns.yaml로 생성
• kubectl get namespace로 확인

[root@master ~]# kubectl create -f orange-ns.yaml
namespace/orange created

#kubectl get namespaces

*파드를 하나 생성 하면서 orange 네임스페이스로 지정

• [root@master ~]# kubectl create -f nginx.yaml -n orange
  ⇒ orange 네임스페이스에 생성 되고, 생략하면 default에 생성됨.

*야물파일을 수정해서 네임스페이스 생성 [ 야물파일에 위치를 지정 ]

• 

• [root@master ~]# kubectl create -f nginx.yaml
  [root@master ~]# kubectl get pods -n orange

pod 생성 ( 네임스페이스 : orange )

• kubectl create -f nginx.yaml -n orange
• 
• kubectl get pods -n orange로 확인
• 네임 스페이스를 지정 안하면 default로 생성, kubectl get pods는 default만 보여줌
• -n으로 네임 스페이스를 지정하면 이름이 같더라도 pods 생성 가능

*blue이름의 네임스페이스 생성

*nginx.yaml 파일을 수정 blue 네임스페이스에 mypod 생성
( 네임 스페이스가 다르기 때문에 같은 이름의 pods 생성 가능 )

#kubectl get pods하면 default 에 할당된 파드만 보이기에 orang, blue에 할당된 파드 는 안보임
⇒ 네임 스페이스에 할당된 파드를 지우려면 네임스페이스를 지우면됨.

---

*기본으로 사용할 네임스페이스를 변경 기본 default ⇒ 생성한 네임스페이스로 변경( blue, orange )

⇒context 수정을 해야함.

• [root@master ~]# kubectl config --help ⇒ context 확인
  [root@master ~]# kubectl config view

-중간에 contexts 부분을 blue 로 수정

• [root@master ~]# kubectl config set-context blue@kubernetes --cluster=kubernetes --user=kubernetes-admin --namespace=blue
  Context "blue@kubernetes" created.

• [root@master ~]# kubectl config view
  [root@master ~]# kubectl config current-context ⇒ 현재 사용되고 있는것 보여줘
  kubernetes-admin@kubernetes

• 

기본 네임스페이스를 만들어져 있는 네임 스페이스로 교체

• kubectl config view로 기본 정보 확인 ( context 내용 )
• kubectl config set-context blue@kubernetes --cluster=kubernetes --user=kubernetes-admin --namespace=blue
  • 변경된 정보 kubectl config view로 확인
  • 

클러스터 추가 설정

• kubectl config current-context
  ( 현재 활성화된 Kubernetes 클러스터의 컨텍스트 이름이 출력 )
• kubectl config use-context blue@kubernetes
  ( blue@kubernetes" 컨텍스트가 활성화되며,
  해당 컨텍스트에 정의된 클러스터와 네임스페이스가 현재 활성화 )

-다시 원래상태로 되돌리기

• #kubectl config use-context kubernetes-admin@kubernetes
  #kubectl get pods

*기본 네임스페이스를 변경 하고 노드를 추가 할 때 상황에 따라서 토큰이 필요로 할때 가 있음
[root@master ~]# kubeadm token list ⇒ 리스트 확인 [ 시간확인 ]

-1시간 짜리 토큰 생성

• 

-default 네임스페이스에서 생성된 파드 확인 / 삭제

• [root@master ~]# kubectl get pods -n default
• 

[root@master ~]# kubectl delete namespaces blue ⇒ blue 안에 있는 파드가 모두 삭제됨.
namespace "blue" deleted

토큰 설정

• 토큰 리스트 확인 ( 시간 확인, kubeadm token list )
• kubeadm token create --ttl 1h ( 토큰 생성, 만료 시간 1시간 )
• kubectl delete pods testpod -n default ( 원하는 pod 삭제 )