Kubernetes - 미니큐브 CLI, 템플릿, 롤링 업데이트 제어

Kubernetes란?

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성[스크립트(템플릿)]과 자동화를 모두 용이하게 한다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소소화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.

---

쿠버네티스 아키텍처

---

컨트롤 플레인 컴포넌트

컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(ex. 스케줄링)을 수행하고 클러스터 이벤트(ex. 디 폴로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.

컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨틀롤 플레인 컴포넌트를 구동시키고, 사용자 컨테이너는 해당 머신 상에 동작시키지 않는다.

---

Kube-apiserver

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.

API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver이다. kube-apiserver는 수평으로 확장되도록 디자인되어 있다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

---

etcd

 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소(NoSQL). 쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

---

Kube-scheduler

노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드(worker)를 선택하는 컨트롤 플레인 컴포넌트. 스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.

---

Kube-controller-manager

컨트롤러를 구동하는 마스터 상의 컴포넌트. 논리적으로, 각 컨트롤러는 개별 프로세스지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. 이들 컨트롤러는 다음을 포함한다. 

• 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
• 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
• 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
• 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

---

Cloud-controller-manager

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.

Cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

 

kube-controller-manger와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다. 다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.

• 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
• 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
• 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서(CLB)를 생성, 업데이트 그리고 삭제하는 것.

---

노드 컴포넌트

노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.

---

Kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다. Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

---

Kube-proxy

Kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다. Kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. Kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, Kube-proxy는 트래픽 자체를 포워드(forward)한다. 즉, 웹에 접속할 수 있게하는 규칙을 담당.

---

Container-runtime

컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

쿠버네티스는 여러 컨테이너 런타임을 지원한다. Docker(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어. 

---

네임스페이스(namespace)

쿠버네티스는 동일한 물리클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다. 이런 가상 클러스터를 네임스페이스라고 한다.

네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우네는 네임스페이스를 전혀 고려할 필요가 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용할 수 있다.

---

Kubernetes

 VM 환경 세팅

VBox에서 기존의 CentOS7.ova 가져오기. 새 MAC 주소 생성.

---

아이피가 겹치는 것을 막기 위해, MAC 주소를 새로고침 해준다.

---

Minikube 설치(Single Node: Master Node + Worker Node)

# 업데이트
yum update -y

# 호스트 네임 변경
hostnamectl set-hostname minikube

# 도커 설치
curl -fsSL https://get.docker.com/ | sudo sh

# 도커 서비스 활성화
systemctl enable --now docker

# 미니큐브에 필요한 conntrack 설치 (만일을 위해 git도 설치)
yum install -y conntrack git

# 미니큐브 1.23 안정화 버전(최신x) 다운
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v1.23.2/minikube-linux-amd64 && chmod +x minikube

# 폴더 생성 (-p: 있으면 생략)
mkdir -p /usr/local/bin/

# 미니큐브 다음 경로에 설치
install minikube /usr/local/bin/

# 미니큐브 버전 확인
minikube version

# 미니큐브 시작
minikube start --driver=none

## 미니큐브 설치를 마치면 나오는 명령어를 복사해서 명령어 실행(자격증명)

미니큐브를 설치하면 다음과 같이 명령어가 출력되는데, 이는 자격증명이므로 복사해서 명령어를 실행한다.

 

---

kubectl 설치

# kubectl 설치 파일 다운
curl -LO https://dl.k8s.io/release/v1.22.2/bin/linux/amd64/kubectl

# kubectl를 다음 경로에 설치
install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# 자동완성 설치
yum install bash-completion -y

# 시스템이 재부팅되도 kubectl 자동완성 명령어가 자동으로 실행되도록 'bashrc'에 집어넣기
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

# 재부팅
exit

# 자동완성이 되는지 테스트
kubectl version

자동완성이 제대로 되는지 테스트. 명령어 실행에 오류가 난다면 자격증명이 안됐을 확률이 크다.

---

CLI 기본 사용법

# 실습용 폴더 생성, 이동
mkdir workspace && cd $_

# 노드의 정보 확인
kubectl get node

# nginx 이미지를 사용하는 파드 생성
kubectl run nginx-pod --image=nginx # pending > ContainerCreating > Running

# 파드의 정보 확인
kubectl get pod

# 서비스의 정보 확인
kubectl get service

# 'ningx-pod'에게 외부에서 파드 쪽으로 접속을 할 수 있게 해주는 ClusterIP타입(내부)의 80포트를 제공
kubectl expose pod nginx-pod --name clusterip --type=ClusterIP --port 80

# 'ningx-pod'에게 외부에서 파드 쪽으로 접속을 할 수 있게 해주는 nodePort타입(외부)의 80포트를 제공
kubectl expose pod nginx-pod --name nodeport --type=NodePort --port 80

# 'ningx-pod'에게 외부에서 파드 쪽으로 접속을 할 수 있게 해주는 loadbalancer타입(외부)의 80포트를 제공
kubectl expose pod nginx-pod --name loadbalancer --type=LoadBalancer --external-ip [minikube의 아이피] --port 80

노드 정보 확인

파드 정보 확인

서비스의 정보 확인

---

내부에서만 작동하는 클러스터 아이피 추가.

클러스터 내부에선 접속이 가능하나, 외부에선 불가능하다.(인터넷 창으로 불가)

---

노드 포트 추가. 80포트가 내부 포트이고 '30942'가 랜덤하게 받은 외부 포트이다.

VM의 아이피에 노드 포트에서 받은 외부 포트를 붙여서 접속할 수 있다.

내부 접속도 가능하다.

---

로드밸런서 추가. 외부 아이피(192.168.2.49)를 10.101.66.30 으로 포트포워딩

로드 밸런서 접속 방법 1: 포트 번호 이용

로드 밸런서 접속 방법 2: 외부 아이피 이용

로드 밸런서 접속 방법 3: 내부 아이피 접속

---

# pod의 상세정보
kubectl describe pod

# service의 상세 정보
kubectl describe  service

# pod에 접속
kubectl exec -it nginx-pod -- bash

# 파드 안의 컨테이너의 'index.html' 변경
echo "<h1>web01</h1>" > /usr/share/nginx/html/index.html

# 파드에서 나오기
exit

# 폴더 생성
mkdir html

## 웹페이지 html파일 업로드(ex: gcp.tar)

# tar파일 다음 경로에 풀기
tar xvf ~/gcp.tar -C html/

# 미니큐브의 폴더를 파드 안으로 복사
kubectl cp html nginx-pod:/usr/share/nginx

---

describe. 172.17.0.3 : conntrack의 아이피(브리지 역할)

이벤트도 확인 가능

---

서비스의 상세 정보.

---

pod안의 컨테이너의 index/html을 변경.

---

미니큐브에서 파드 안으로 파일을 복사한 결과.

---

## 삭제
# 모든 정보 확인
kubectl get all

# 서비스 삭제
kubectl delete svc clusterip

# 모든 서비스 삭제
kubectl delete svc --all

# 파드 삭제
kubectl delete pod nginx-pod

# 모든 파드, 서비스 삭제
kubectl delete pod,svc --all

---

모든 정보.

---

# kubectl 모든 명령어 옵션
kubectl options

# api와 관련된 자원 정보들
kubectl api-resources

# 노드의 정보(-o wide: 내부, 외부 아이피, 이미지 등도 추가 조회)
kubectl get nodes -o wide

# 항목을 제거하고 조회
kubectl get nodes -o wide --no-headers

# 항목을 제거하고 6번째 값(아이피) print. 정보를 추출할 때 awk 사용
kubectl get nodes -o wide --no-headers | awk '{print $6}'

kubectl get nodes -o wide

---

# 다시 파드 생성
kubectl run nginx-pod --image=kyounggu/web-site:aws
kubectl expose pod nginx-pod --name loadbalancer --type LoadBalancer --external-ip 192.168.2.49 --port 80

# deployment(파드를 묶어 놓은 것) 2개 생성 
kubectl create deployment nginx-app --replicas 2 --image nginx

# deployment 상세 확인
kubectl get deployments.apps -o wide

# replicasets 확인 
# replicasets: deployment가 나오기 전에 쓰임. 원하는 개수 만큼 늘이거나 줄이는 자가 치유 가능
# 하지만 롤링 업데이트가 안되므로, deployment로 넘어가게 됐다.
kubectl get replicasets.apps

# deployment에 ClusterIP 추가
kubectl expose deployment nginx-app --name clusterip-app --type ClusterIP --port 80

# deployment에 NodePort 추가
kubectl expose deployment nginx-app --name nodeport-app --type=NodePort --port 80

# deployment에 LoadBalancer 추가
kubectl expose deployment nginx-app --name loadbalancer-app --type=LoadBalancer --external-ip [미니큐브 아이피] --port 80

# deployment scale out
kubectl scale deployment nginx-app --replicas 4

# deployment scale in
kubectl scale deployment nginx-app --replicas=2

# deployment 삭제
 kubectl delete deployments.apps nginx-app
 
# 마무리 정리
kubectl delete all --all

deployment 상세 확인.

deployment를 생성하면 replicaset이 자동으로 생성된다.

replicaset의 이름을 가진 두개의 파드가 생겼다.

---

deployment에 ClusterIP 추가. 엔드포인트가 2개이다.(파드가 2개이므로)

즉, 하나의 클러스터 아이피에 2개의 파드가 연결된 것이다. 

테스트를 위해 각 파드의 index.html을 수정

ClusterIP로 접속하면 내부에서도 로드밸런스가 되고 있음을 알 수 있다.

---

노드 포트도 로드 밸런싱이 되고 있다.

웹에서도 확인이 가능하다.

---

로드밸런서 확인.

 참고로, 'PORT(S)'의 포트 번혼느 포트포워딩을 뜻하는 것이 아니다. 그러므로, 좌측의 컨테이너 포트를 포트포워딩 하듯이 바꾸면 안된다.

---

스케일을 늘렸더니 새로운 파드가 생겼다.

새로 생긴 파드들도 같이 로드밸런스된다.

스케일을 줄이면 나중에 생성됐던 파드가 먼저 사라진다.

---

레플리칸 세트를 지워도 자가 회복에 의해 자동으로 생성된다.

그러므로 deployment를 삭제해야 사라진다.

 

---

템플릿으로 컨테이너 실행하기

파드 생성

# nginx-pod 템플릿 작성
vi nginx-pod.yaml
//
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx-pod
spec:
  containers:
  - name: nginx-pod-container
    image: nginx
    ports:
    - containerPort: 8080 # 별도 지정된 포트가 없다면 8080으로 지정하라 (docker -P 유사)
//

# 템플릿 적용(파드 생성)
kubectl apply -f nginx-pod.yaml

# 확인
kubectl describe pod nginx-pod

---

템플릿으로 파드 생성

---

클러스터 아이피 생성 

# clusterip-pod 템플릿 작성
vi clusterip-pod.yaml
//
apiVersion: v1
kind: Service
metadata:
  name: clusterip-pod
spec:
  type: ClusterIP
  selector:
    app: nginx-pod
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
//

# 템플릿 적용으로 서비스 생성
kubectl apply -f clusterip-pod.yaml

# 서비스 확인
kubectl get svc -o wide

# 서비스 확인
kubectl get svc -o wide

# 상세 정보
kubectl describe svc clusterip-pod

# clusterip-pod 서비스 수정 (확인만)
kubectl edit svc clusterip-pod

edit 화면

---

노드 포트 생성

# nodeport-pod 템플릿 작성
vi nodeport-pod.yaml
//
apiVersion: v1
kind: Service
metadata:
  name: nodeport-pod
spec:
  type: NodePort
  selector:
    app: nginx-pod
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080
//

# 템플릿을 실행하여 nodeport 생성
kubectl apply -f nodeport-pod.yaml

# 서비스 확인
kubectl get svc -o wide

# nodeport 상세 정보
kubectl describe svc nodeport-pod

# nodeport 수정
kubectl edit svc nodeport-pod

---

edit을 통해 포트 변경

포트 번호가 변함.

변경한 포트로 접속 가능.

---

로드 밸런서 생성 

# loadbalancer-pod 템플릿 작성 
vi loadbalancer-pod.yaml
//
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-pod
spec:
  type: LoadBalancer
  externalIPs:
  - [연결할 VM의 아이피]
  selector:
    app: nginx-pod
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
//

# 템플릿을 실행하여 로드밸런서 생성
kubectl apply -f loadbalancer-pod.yaml

# 서비스 정보 확인
kubectl get svc -o wide

# 로드밸런서의 상세 정보 확인
kubectl describe svc loadbalancer-pod

# 로드밸런서 수정
kubectl edit svc loadbalancer-pod

externalIPs에 연결할 아이피를 적는다.

---

템플릿으로 ReplicaSet

ReplicaSet 

# replicaset 템플릿 생성
vi replicaset.yaml
//
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3 # desired state (kube-controller-manager)
  selector:		# 연결부
    matchLabels:	# 라벨명이 다음과 같은 템플릿과 연결
      app: nginx-replicaset

  template:
    metadata:
      name: nginx-replicaset
      labels:
        app: nginx-replicaset	# 라벨이 같아서 selector와 연결됨
    spec:
      containers:
      - name: nginx-replicaset-container
        image: nginx
        ports:
        - containerPort: 80
//

# 실행하여 레플리카셋 생성
kubectl apply -f replicaset.yaml

# 레플리카셋 확인
kubectl get replicasets.apps -o wide

# 레플리카셋 상세 정보
kubectl describe replicasets.apps nginx-replicaset

# 레필리카셋 수정 (스케일을 5로 변경)
kubectl edit replicasets.apps nginx-replicaset

# 레플리카셋 스케일 변경
kubectl scale replicaset nginx-replicaset --replicas 3

# replicaset 템플릿 생성
vi replicaset.yaml
//
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3 # desired state (kube-controller-manager)
  selector:		# 연결부
    matchLabels:	# 라벨명이 다음과 같은 템플릿과 연결
      app: nginx-replicaset

  template:
    metadata:
      name: nginx-replicaset
      labels:
        app: nginx-replicaset	# 라벨이 같아서 selector와 연결됨
    spec:
      containers:
      - name: nginx-replicaset-container
        image: nginx
        ports:
        - containerPort: 80
//

# 실행하여 레플리카셋 생성
kubectl apply -f replicaset.yaml

# 레플리카셋 확인
kubectl get replicasets.apps -o wide

# 레플리카셋 상세 정보
kubectl describe replicasets.apps nginx-replicaset

# 레필리카셋 수정
kubectl edit replicasets.apps nginx-replicaset

---

레플리카스를 5로 늘린다.

2개의 파드가 더 생성된다.

---

ReplicaSet - ClusterIP

# clusterip-replicaset 템플릿 생성
vi clusterip-replicaset.yaml 
//
apiVersion: v1
kind: Service
metadata:
  name: clusterip-replicaset
spec:
  type: ClusterIP
  selector:
    app: nginx-replicaset
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
//

# 템플릿을 적용하여 클러스터 아이피 생성
kubectl apply -f clusterip-replicaset.yaml

# 서비스 정보 확인
kubectl get svc -o wide

# 이런 식으로도 내부의 index.html을 수정할 수 있다.
kubectl exec -it [파드의 이름] -- /bin/sh -c 'echo "<h1>[수정내용]</h1>" > /usr/share/nginx/html/index.html'

# 상세 정보
kubectl describe svc clusterip-replicaset

# 수정
kubectl edit svc clusterip-replicaset

새로 생성된 파드들을 구별하기 위해 index.html을 수정

---

ReplicaSet - NodePort

# nodeport-replicaset 템플릿 작성
vi nodeport-replicaset.yaml
// 이번엔 노드포트를 작성하지 않는다 (자동으로 생김)
apiVersion: v1
kind: Service
metadata:
  name: nodeport-replicaset
spec:
  type: NodePort
  selector:
    app: nginx-replicaset
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort:
//

# 템플릿을 실행하여 노드포트 생성
kubectl apply -f nodeport-replicaset.yaml

# 서비스 정보 확인
kubectl get svc -o wide

# 상세 정보
kubectl describe svc nodeport-replicaset

# 수정
kubectl edit svc nodeport-replicaset

포트 번호가 자동으로 생성된다.

---

ReplicaSet - LoadBalancer

# loadbalancer-replicaset 템플릿 작성
vi loadbalancer-replicaset.yaml
//
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-replicaset
spec:
  type: LoadBalancer
  externalIPs:
  - [미니큐브의 아이피]
  selector:
    app: nginx-replicaset
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
//

# 템플릿을 실행하여 로드밸런서 생성
kubectl apply -f loadbalancer-replicaset.yaml

# 서비스 확인
kubectl get svc -o wide

# 상세 정보
kubectl describe svc loadbalancer-replicaset

# 수정
kubectl edit svc loadbalancer-replicaset

---

로드밸런서-레플리카셋 생성. 하지만 로드밸런서가 2개 있기 때문에 포트 번호 없이 접속 시, 먼저 생성한 loadbalancer-pod로만 접속이 될 것이다.

참고로, 로드 밸런서의 포트에서 왼쪽: 외부 포트 / 오른쪽: 노드 포트인데, 당장은 둘 사이의 큰 차이점은 찾을 수 없다.

실제로 loadbalancer-pod로만 접속이 된다.

edit을 통해 포트를 8088로 수정

8088포트를 통해 loadbalancer-replicaset을 사용 가능

물론 기존의 외부 포트로도 가능하다.

---

# 레플리카셋 수정
kubectl edit replicasets.apps nginx-replicaset
// 이미지 변경
      - image: kyounggu/web-site:aws
//
## 파드가 하나씩 지워지고 새로운 이미지로 생성되어야 하지만, 롤링 업데이트가 없기 때문에 안된다.

 

 

---

템플릿으로 Deployment

Deployment

# deployment 템플릿 작성
vi deployment.yaml
//
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment

  template:
    metadata:
      name: nginx-deployment
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx-deployment-container
        image: nginx
        ports:
        - containerPort: 80
//

# kubectl apply -f deployment.yaml

# kubectl get deployments.apps -o wide

# kubectl describe deployments.apps nginx-deployment
// 이미지 변경
      - image: kyounggu/web-site:aws
//
## 파드가 하나씩 지워지고 새로운 이미지로 생성된다.

# kubectl edit deployments.apps nginx-deployment

---

 

파드가 하나씩 지워지고 새로운 이미지로 생성된다.

이미지가 바뀐 것을 알 수 있다.

---

Deployment - ClusterIP

# clusterip-deployment 템플릿 작성
vi clusterip-deployment.yaml
//
apiVersion: v1
kind: Service
metadata:
  name: clusterip-deployment
spec:
  type: ClusterIP
  selector:
    app: nginx-deployment
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
//

# kubectl apply -f clusterip-deployment.yaml
# kubectl get svc -o wide
# kubectl describe svc clusterip-deployment
# kubectl edit svc clusterip-deployment

---

Deployment - NodePort

# nodeport-deployment 템플릿 작성 
vi nodeport-deployment.yaml
// 노드포트 넘버는 충돌을 피하는 것이 좋다.
apiVersion: v1
kind: Service
metadata:
  name: nodeport-deployment
spec:
  type: NodePort
  selector:
    app: nginx-deployment
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32080
//

# kubectl apply -f nodeport-deployment.yaml
# kubectl get svc -o wide
# kubectl describe svc nodeport-deployment
# kubectl edit svc nodeport-deployment

---

Deployment - LoadBalancer

# loadbalancer-deployment 템플릿 작성
vi loadbalancer-deployment.yaml
// 포트 번호 충돌을 피한다.
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-deployment
spec:
  type: LoadBalancer
  externalIPs:
  - [미니큐브 아이피]
  selector:
    app: nginx-deployment
  ports:
  - protocol: TCP
    port: 8888
    targetPort: 80
    nodePort: 32088
//

# kubectl apply -f loadbalancer-deployment.yaml
# kubectl get svc -o wide
# kubectl describe svc loadbalancer-deployment
# kubectl edit svc loadbalancer-deployment

---

 위의 yaml 파일들을 하나로 합쳐서 사용 가능하다.

## yaml 파일들 하나로 합치기

# deployment.yaml을 복사
cp deployment.yaml  deployment-service.yaml

# 복사한 새 yaml 파일 편집
vi deployment-service.yaml
// 아래에 '---'로 구분하고 로드밸런서 yaml 구문 추가
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment

  template:
    metadata:
      name: nginx-deployment
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx-deployment-container
        image: nginx
        ports:
        - containerPort: 80


---

apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-deployment
spec:
  type: LoadBalancer
  externalIPs:
  - [미니 큐브 아이피]
  selector:
    app: nginx-deployment
  ports:
  - protocol: TCP
    port: 8888
    targetPort: 80
    nodePort: 32088

//

# kubectl apply -f deployment-service.yaml

---

Deployment 롤링 업데이트 제어

# 이미지 변경
kubectl set image deployment.apps/nginx-deployment nginx-deployment-container=kyounggu/web-site:aws

# 이렇게도 가능
# kubectl set image deployment/nginx-deployment nginx-deployment-container=kyounggu/web-site:food

파드가 지워지고 새로 생성된다.

이미지가 변경되었다.

---

# 히스토리
kubectl rollout history deployment nginx-deployment

# 특정 REVISION 확인
kubectl rollout history deployment nginx-deployment --revision [리비전 번호]

총 3개의 히스토리가 있다.

총 2번의 이미지 변경이 있음을 알 수 있다. 현재는 food

---

## 롤백
# 바로 전의 REVISION으로 롤백
kubectl rollout undo deployment nginx-deployment

# 특정 REVISON으로 롤백도 가능
kubectl rollout undo deployment nginx-deployment --to-revision [리비전 번호]

롤백으로 인해 이미지가 변경됨.

undo로인해 기존의 2번이 4번으로 옮겨짐

가장 초기의 1번으로 롤백