Kubernetes 특강 2회차 공부 내용 정리

 

 

 

Kubernetes 클러스터 연결 설정하기

멘토님께서 나눠주신 Kubernetes 클러스터의 구성을 정의하고 있는 yaml 파일을 가지고,

kubectl 명령어로 설정해 준다면

특정 클러스터와 사용자를 연결하여 클러스터 자원을 관리하고 접근할 수 있게 됩니다.

### 쿠버네티스 클러스터 연결을 위한 변수 선언
$ export KUBECONFIG=~/downloads/soma-k8s-lab-kubeconfig.yaml

또는

$ sudo cp ~/downloads/soma-k8s-lab-kubeconfig.yaml ~/.kube/config

### 확인하는 방법
$ echo $KUBECONFIG

### 쿠버네티스 연결 확인
$ kubectl get nodes

### 네임스페이스 제작
$ kubectl create namespace {네임스페이스 명}

### 생성된 네임스페이스 확인
$ kubectl get namespace

### 방금 생성한 네임스페이스를 기본적으로 사용할 NS로 설정하기
$ kubectl config set-context --current --namespace={네임스페이스 명}

### Kubernetes 설정 파일의 내용을 조회하여, 기본 네임스페이스 정상 업데이트 여부 확인하기
$ kubectl config view --minify | grep namespace:

 

 

---

 

지난 시간 Deployment 내용 복습

Q) Pod로도 컨테이너를 실행하고 운영할 수 있는데, Deployment가 필요한 이유는 무엇일까?

 

 

A)

Pod는 하나 이상의 컨테이너를 포함하는 쿠버네티스 오브젝트이며, 여러 컨테이너를 하나의 논리적인 단위로

묶어서 관리할 수 있습니다. 그러나 Pod 자체는 단일 노드에만 스케줄링될 수 있으며, 단일 노드 장애 시에는

Pod의 모든 컨테이너가 다운됩니다. 또한 Pod의 스케일링과 롤링 업데이트 등의 관리는 복잡할 수 있다고 합니다.

 

이에 반해, Deployment는

ReplicaSet을 기반으로 하여 원하는 수의 Pod 인스턴스를 생성하고 관리하는 Pod의 상위 개념이라고 볼 수 있습니다.

 

Deployment의 장점

• 롤링 업데이트
  • 새로운 버전의 애플리케이션 배포 시, 하나의 ReplicaSet에서 새로운 Pod 인스턴스를 추가하고, 동시에 이전 버전의 ReplicaSet에서 Pod 인스턴스를 제거하여 롤링 업데이트를 수행합니다. 이를 통해 애플리케이션의 가용성과 안정성을 유지할 수 있습니다.

 

•  스케일링
  • ReplicaSet을 쉽게 확장하거나, 축소하여 Pod 인스턴스 수를 조정할 수 있습니다.

 

• 롤백
  • 롤링 업데이트 중 문제가 발생할 경우, 이전 버전으로 롤백할 수 있습니다.

 

• 버전 관리
  • 새로운 버전의 애플리케이션을 배포할 때마다, 새로운 ReplicaSet을 생성하여 버전 관리를 할 수 있습니다. 

 

• 생명 주기 관리
  • ReplicaSet에 의해 선언된 Pod는 죽지 않고 부활합니다.

따라서 Pod는 단순컨테이너를 운영하기에 적합하지만,

Deployment를 사용하면 애플리케이션의 롤링 업데이트, 스케일링, 롤백 등을 더욱 효율적으로 관리할 수 있습니다.

 

 

Deployment를 생성하기 위한  yaml 파일 구조

nginx:1.11.1 이미지를 사용하여 app: nginx라는 레이블을 가진

Pod를 관리하는 Deployment yaml 파일 구조는 아래와 같습니다.

apiVersion: apps/v1           # 쿠버네티스 api 버전
kind: Deployment              # 생성할 오브젝트 종류
metadata:                
  name: nginx-deployment      # deployment의 이름
  labels:
    app: nginx                # label 지정
spec:                         # deployment의 스펙을 정의
  replicas: 3				  # replica수 설정
  selector:                   # deployment가 관리할 pod를 찾는 방법을 정의
    matchLabels:     
      app: nginx
  template:
    metadata:
      labels:                 # pod의 label
        app: nginx
    spec:
      containers:             # 컨테이너 설정
      - name: nginx          
        image: nginx:1.11.1
        ports:
        - containerPort: 80

 

 

---

 

롤링 업데이트 수행하기

애플리케이션 스케일링과 유사하게, deployment가 외부로 노출되면

서비스는 업데이트가 이루어지는 동안 오직 가용한 pod에게만 트래픽을 로드 밸런스 하게 됩니다.

여기서 가용한 pod는 애플리케이션의 사용자들에게 가용한 상태의 인스턴스를 말합니다.

 

롤링 업데이트는 아래 동작들을 허용해줍니다.

• 하나의 환경에서 또 다른 환경으로의 애플리케이션 프로모션 (컨테이너 이미지 업데이트를 통해)
• 이전 버전으로의 롤백
• 서비스 중단 없는 애플리케이션의 지속적인 통합과 지속적인 전달

 

위에서 nginx:1.11.1 이미지를 사용하여 yaml 파일을 통해 생성한 Deployment를 활용하여

nginx 버전을 1.14.2로 업데이트를 수행해보도록 하겠습니다.

 

1. set image 명령어

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.14.2

 

위 명령어로 업데이트를 진행할 수 있고,

아래 실행 사진을 통해서 3개의 기존 Pod가

하나씩 새 Pod로 교체되면서 모두 교체 되는 것을 확인할 수 있습니다.

 

 

2. edit 명령어 활용한 형상 변경

yaml 파일을 vim 에디터를 통해 수정해주고 아래 명령어를 실행해주면 됩니다.

그러면 spec.template.spec.containers[0].image 값을 업데이트할 버전으로 변경한다고 합니다!

 

 

$ kubectl edit deployment/nginx-deployment

 

 

3. yaml 수정 후, apply 적용

$ kubectl apply -f nginx-deployment.yaml

 

 

---

 

롤 아웃 상태 보기

롤 아웃은 새로운 배포(deployment) 또는 업데이트를 클러스터에 적용할 때 사용되는

kubernetes 기능 중 하나입니다.

롤 아웃을 통해 deployment가 실행 중인지, 어떤 pod가 사용되는지, 어떤 이미지를 사용하는 지와 같이

배포가 어떤 상태인지를 확인할 수 있습니다.

 

아래와 같은 명령어는 배포가 성공적으로 실행 중인지 확인하는 데 사용됩니다.

만약 배포가 실행 중이 아니라면, 어떤 문제가 있는지 알려주고 문제를 해결하기 위한 도움말을 제공한다고 합니다.

 

 

그리고

업데이트 완료 후, ReplicaSet을 다시보면 기존 버전이 남아있음을 알 수 있습니다.

즉 기존 버전이 바로 삭제되지않으며 필요시 롤백에 사용될 수 있습니다.

 

 

$ kubectl describe deployments

버전 업-다운을 하면서 발생한 이벤트를 볼 수 있습니다.

 

 

 

롤 아웃 기록 확인하기

히스토리를 조회하여 

이전 배포의 상태를 확인하고 문제가 발생한 경우에 롤백하는데 도움을 줍니다.

 

$ kubectl rollout history deployment/nginx-deployment

 

 

 

롤백 수행하기

업데이트하다가 맘에 안들거나 최근께 에러가 났을경우, 롤백을 수행해야 할 일이 생길 수 있습니다.

아래와 같이 undo 명령어에 --to-revision 값을 설정해주면

위에서 history로 조회하면서 나왔던 리비전(REVISION) 번호가 2인 배포 버전으로 롤백하게 됩니다.

$ kubectl rollout undo deployment/nginx-deployment --to-revision=2

 

 

---

 

Deployment를 외부와 연결하기

 

Deployment를 외부에 노출하기 위해서는 클라이언트와 Deployment 중간에 Load Balancer가 필요합니다.

 

여기서 서비스라는 개념이 나오는데,

쿠버네티스에서 서비스(Service)는 네트워크 추상화 계층을 제공하는 쿠버네티스 오브젝트 중 하나입니다.

즉, 애플리케이션의 노출, 로드 밸런싱, 서비스 디스커버리를 담당하는 역할을 합니다.

 

서비스는 Pod을 대상으로 작동합니다.

Pod은 일시적인 존재로서, 생성되면 언제든지 삭제될 수 있습니다.

이에 따라 Pod의 IP 주소는 동적으로 할당되므로,

서비스는 Pod이 다시 생성되어도 안정적으로 접근할 수 있는 IP 주소를 제공합니다.

 

서비스 -> Pod(x, 무조건 안되는건 아니지만 실무에서는 굳이 이렇게 안한다고 함)

서비스 -> Deployment -> 살아있는 Pod와 연결(o)

 

서비스 확인

아래와 같이 kubectl get svc 명령어를 입력하면

현재는 별다른 서비스가 없는 것을 확인할 수 있습니다.

 

80 포트로 서비스 노출하기

expose 명령어를 통해 서비스를 생성하여 80 포트로 서비스를 노출합니다.

외부 IP(EXTERNAL-IP)가 획득 되지 않았기 때문에

현재는 외부에서 접속이 불가능합니다.

$ kubectl expose deployment nginx-deployment --port=80

 

post-forward를 통해 머신과 쿠버네티스를 연결할 수 있습니다.

$ kubectl post-forward service/nginx-deployment 8080:80

 

또는 처음부터 expose 명령어에서 --type을 붙여 로드밸런서로 생성할 수 있습니다.

그러면 아래와 같이 Cluster IP와 함께 외부 공인 IP가 획득되었음을 알 수 있습니다.

$ kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer

브라우저를 통해 외부 IP로 접속하면...

 

nginx 웰컴 페이지가 잘 나오는 것을 확인할 수 있습니다!!

 

 

---

 

MIN/MAX 값으로 Replicas 설정하기

LoadBalancer 서비스는 클라우드 서비스 제공자에서 제공하는 로드 밸런서를 사용하여 서비스를 노출합니다.

클러스터 외부에서 접근 가능한 IP 주소와 포트를 제공하여 외부에서 애플리케이션에 접근할 수 있도록 하고

로드 밸런싱을 수행하여 클러스터 내부의 여러 Pod에 대한 요청을 분산합니다.

 

로드 밸런싱을 수행하더라도 트래픽이 갑자기 한꺼번에 몰리게 된다면, 서버가 다운될 수 있기 때문에

이때 MIN/MAX 값으로 Replicas를 설정하면,

기존 파드의 CPU 사용률을 기준으로 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있게 됩니다.

 

$ kubectl autoscale deployment/nginx-deployment --min=3 --max=5 --cpu-percent=80

 

 

위 명령어는

--min=3 옵션은 배포의 최소 파드 수를 3으로 지정하고, --max=5 옵션은 배포의 최대 파드 수를 5로 지정합니다.

이렇게 설정하면 Kubernetes 시스템은 배포 내부의 파드 수를 최소 3개에서 최대 5개까지 자동으로 조정하게 됩니다.

 

--cpu-percent=80 옵션은 CPU 사용률의 평균이 80%를 넘으면 

추가 파드를 생성하여 스케일 업을 수행하도록 지정하는 것입니다.

이 값을 초과하는 경우 Kubernetes 시스템은 자동으로 추가 파드를 생성하여 부하 분산을 수행하게 됩니다.

 

이렇게 자동 스케일링을 구성하면 시스템 부하가 증가할 때 자동으로 처리 능력을 늘리고,

부하가 감소할 때는 자동으로 처리 능력을 축소하여 클러스터 리소스를 효율적으로 관리할 수 있습니다.