0부터 시작하는 Kubernetes 공부 - Object & Deployment & Update

1. Object

기본 Object

• K8S 는 모든 기능을 Object 로 관리한다

1. Pod : 1 개 이상의 컨테이너로 이루어져 있으며, K8S 의 최소 단위이다. 주로 주 컨테이너와 보조 컨테이너 ( Side-Car ) 로 이루어진다. Side-Car 는 주 컨테이너에 대한 모니터링과 로그 수집과 같은 기능을 주로 한다

2. Namespace : 각 사용자별 작업 공간을 제공해준다

   

   • 우리가 아는 Pod 에 제공해주는 Namespace 와는 다르다. Pod 별 Namespace 는 Docker Contaienr 의 경우 containerd 의 shim 에서 제공해주는 것이다. Pod 별 Namespcae 의 경우 Container 단위로 Namespace 가 할당되는 Docker 와 다르게, K8S 에서는 Pod 단위로 Namespace 를 제공해준다. 해당 Pod 의 Container 들은 Namespace 를 공유한다
   • 공유되는 Namespace 도 있다. 예를 들어 PV 가 있다

Namespace Object 는 Pod 에 할당해주는 Namespace 가 아닌, User 별로 제공해주는 Namespace 이다. 이 User 는 다수의 Namespace 를 사용할 수 있는데, 이때 Namespace 의 이름이 달라야 한다

Namespace Object 는 Pod 에 할댕해주는 Namespace 와 다른 것이다!!! User 별 작업 공간이다!!! Pod 의 Namespace 는 Runtime 에서 할당해준다

3. Volume : Pod 에게 영구 Data 보관을 위한 Volume 을 제공한다

   

   • 미리 볼륨에 대한 다중 접속, RW 권한, 용량을 설정한 볼륨들을 Pool 에 넣고, 사용자가 요청하면, 해당 요청에 매칭되는 볼륨을 자동으로 찾아서 Binding 해줄 수도 있다. 사용자는 요청만 하면된다. 이런 방식을 PV / PVC ( 요청 ) 이라고 한다. 아래 그림과 같은 느낌이다
     
   • 혹은 사용자 요청을 받아 동적 프로비저닝이 가능한 도구에게 요청을 보내서, 동적 프로비저너에서 해당 요청에 맞는 볼륨을 만들어 제공해주는 방법도 있다. 이때, Storage Class 가 필요하다

4. Service : 이 서비스는 웹 서비스나 네트워크 서비스 같은 서비스 데몬같은 것이 아니라, 외부에서 클러스터 내의 Pod 로 접속할 수 있는 방법을 말한다

   • Cluster Ip : 클러스터 환경의 다른 Node 의 Pod 끼리 통신이 가능하게 한다. 다만, 외부에서 접근은 불가능하다
   • Node Port : 외부에서 Port 를 통해 접속
   • Load Balancer : 외부에서 LB 를 통해 접속

추가적인 Object

1. DaemonSet : 각 Node 에 무조건 일괄적으로 하나씩 배포한다. 주로 모니터링등에 활용하면 유용하다. 이 DaemonSet 은 무조건 하나가 배포되야 하기에, 강제로 지우지 않는 이상, 삭제되지 않는다

2. ConfigMap : 시스템 환경 변수, 일반적인 파일 등을 제공하기 위한 방법으로 보안성은 없다

3. Secret : ConfigMap 과 거의 동일하지만, 해당 Data 가 외부에 노출되지 않는다는 장점이 있어서, 주로 인증서, Username / Password, SSH 접속 등과 같은 보안성을 요구하는 곳에서 활용한다

   • 가령, 특정 사설 저장소로 접속하기 위한 Username, Password, Address 를 Secret 으로 작성하여 yml 파일에 적용할 경우, 특정 저장소에서 특정 파일을 다운로드할때 유용하다

2. Deployment

Pod 의 Name

• 일반적인 Pod 는 삭제가 자유로운 Pod 이며, Name 의 경우도 임의의 hash 값을 뒤에 붙이게 된다

  • 예를 들어, Deployment 를 배포할때 test-deploy 이름으로 배포했다. 이 하위의 ReplicaSet 의 이름은 test-deploy-1231 와 같은 형식이 되며, ReplocaSet 하위의 Pod 이름은 test-deploy-1231-s2as3k , test-deploy-1231-2sd5kd 와 같은 형식이 된다
  • 이러한 Pod 이름은 고정된 이름이 아닌, 임의의 hash 값을 이용한 이름이다. 이 일반적인 Pod 는 언제든지 삭제와 생성이 자유로운 형태로 제공된다
  • 이러한 Pod 는 목장의 소 느낌이라고 볼 수 있다

• 만약 StatefulSet 오브젝트를 이용하면, 상태 저장이 가능하다. 이 StatefulSet 오브젝트를 통해 Pod 의 이름을 hash 값이 아닌 고정되는 이름을 지정할 수 있다. 해당 Pod 를 유지할 수 있다

  • 이러한 Pod 는 애완견 같은 느낌이라고 볼 수 있다

Deployment & ReplicaSet & Pod

p. 138

• run을 이용한 배포 방식은 Pod 하나만 배포 가능하다
• ReplicaSet 을 통해 다수의 Pod 를 한 번에 배포할 수 있다. ReplicaSet 은 Pod 의 label 을 보고 개수 유지를 해준다
• Deployment 는 버전 관리를 해준다

Deployment 배포 및 확인

• 위와 같이 Deployment 를 배포할 yml 파일을 작성하자
  
• 배포하고, 확인해주자

  • Deployment 정보에 나오는 숫자는 Pod 가 아닌, Container 의 수이다
  • Pod 의 이름을 확인하면, 앞에 test 는 Deployment 이름, 6~b 는 ReplicaSet 이름, 마지막 hash 부분이 Pod 별 이름이다

• -o wide 옵션을 통해 추가 정보를 확인하자

REVISION 확인

Revision 은 ReplicaSet 의 상태 정보로 Revision 과 ReplicatSet 은 1 대 1 대응 관계라고 볼 수 있다

• 배포한 Deployment 의 버전을 확인해보자
  
• Deployment test 의 버전을 확인하자
  
• 삭제하고, --record 옵션을 사용하여 다시 배포해보자

  • record 는 배포했을 때의 상태를 기록해준다
  • record 옵션은 곧 삭제될 옵션이다

3. Rolling Update & Recreate

Update

• Image 만 httpd 로 변경하여 Update 해보자
  
• 1 버전을 배포하고 확인후, 2 버전으로 Update 하고 확인해보자. 새 버전의 컨테이너가 생성된다
  
• 새 버전의 컨테이너가 생성되면, 기존 컨테이너가 내려간다

이러한 Update 는 두 가지 방법을 사용할 수 있다

1. Rolling Update : 새로 만든 컨테이너 수 만큼, 기존 컨테이너 삭제. 이 방법은 너무 오래 걸린다. 따라서 전략이 필요하다

   예를 들어, 한 번에 삭제할 컨테이너 수를 지정하여, 해당 수만큼 컨테이너를 생성하게 할 수 있다. 즉, 삭제 개수와 추가 생성 개수를 지정해서 사용할 수 있다

2. 기존 Pod 를 모두 종료 ( terminate ) 시킨 다음, 새로운 Pod 로 전환시키는 방법

다른 yml 파일로 배포해도 Update 가 되는 이유는 Deployment 이름이 같기 때문이다

Update - Recreate

• 위와 같이 Strategy 의 type 을 Recreate 로 해주자
  
• 이미지를 바꿔서 다시 배포하면, Pod 를 전부 종료하고, 새로 생성하는 것을 확인할 수 있다

  • 허나, 이 방법은 종료되는 중간에는 해당 애플리케이션으로의 외부 접속이 불가능해지는 문제가 발생한다

• 새 버전이 생겼다. 기존 버전은 종료되었다

Update - Rolling Update & Strategy

• 위와 같이 작성하자. unavailable 은 한 번에 중지시키는 Pod 개수이고, surge 는 한 번에 생성하는 Pod 개수이다
  
• 배포 후 확인하고, 업데이트 후 확인하자. 한 번에 2 개씩 삭제하고, 2 개씩 생성하여 작업이 더 빨라졌다

Rolling Update 를 적용하게 되면, 기존 서비스의 중단 없이, 새로운 Pod 의 생성을 미리 산정하고, 계획할 수 있게 된다. 만약 서비스 중에 처리 속도가 늦어진다면 maxsurge 와 maxunavailable 을 조정하여 안정적으로 서비스를 유지시킬 수 있게 된다

Roll Back

Revision 을 지정하여 해당 버전으로 돌아갈 수 있다. 마치, 스냅샷을 이용하는 방법과 비슷하다

4. Deployment 확인

ReplicaSet 확인

Revision 은 ReplicaSet 의 상태 정보로 Revision 과 ReplicatSet 은 1 대 1 대응 관계라고 볼 수 있다

• Deployment 는 추가 label 을 생성하여, label 을 통해 버전 관리를 해준다. 이를 통해 Scale 조정시 작동중인 버전의 Pod 만 늘릴 수 있다

  • 현재 우리는 Revision 2 번에 있다

Deployment 상세 정보

• describe 를 통해 Deployment 의 상세 정보를 확인하자

  • 현재 Namespace 는 default 이다
  • Selector 에는 확인하는 pod 의 label 이 있다
  • Rolling Update 설정도 확인 가능하다
  • Pod 의 지정된 label 도 확인 가능하다