목차

1. Blue/Green
2. canary
3. rolling update

Blue/Green 배포

블루-그린 배포는 로드 밸런서, Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼 또는 자동화된 배포 파이프라인을 비롯한 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 모든 문제에 대해 애플리케이션을 모니터링하면서 이전 버전에서 새 버전으로 트래픽을 점진적으로 전환하는 방법을 갖는 것입니다.

이 방식은 새 버전의 소프트웨어 애플리케이션을 릴리스하는 데 사용되는 배포 전략입니다. 이 접근 방식에서는 애플리케이션의 새 버전이 이전 버전과 함께 배포되지만 처음에는 트래픽이 이전 버전으로만 전달됩니다. 새 버전이 테스트되고 안정적인 것으로 확인되면 트래픽을 완전히 제공하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 점차 새 버전으로 이동됩니다.

"블루-그린 배포"라는 이름은 응용 프로그램의 이전 버전을 "블루" 버전이라고 하고 새 버전을 "그린" 버전이라고 한다는 사실에서 유래되었습니다. 이 접근 방식은 기존 배포 방법에 비해 다음과 같은 몇 가지 이점을 제공합니다.

• 장점
  
  1. 가동 중지 시간 최소화
     블루-그린 업데이트를 사용하면 트래픽이 전환되기 전에 새 버전이 이전 버전과 함께 배포되므로 가동 중지 시간이 최소화됩니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 위험 감소
     애플리케이션의 두 버전이 동시에 실행되기 때문에 사용자에게 영향을 미치는 문제나 오류의 위험이 줄어듭니다.
• 단점
  
  1. 비용
     두 버전의 애플리케이션을 동시에 배포하고 실행해야 하므로 블루-그린 업데이트에는 더 높은 인프라 비용이 필요합니다.
     
     
  2. 복잡성
     두 개의 별도 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.

작동 방식예시

1. 웹 애플리케이션 시나리오에서 애플리케이션의 프런트 엔드 코드를 업데이트한다고 가정합니다. 블루-그린 배포를 사용하면 프런트 엔드 코드의 새 버전("녹색" 버전)을 만들고 기존 버전("청색" 버전)과 함께 배포합니다. 트래픽은 처음에 녹색 버전이 테스트되는 동안 파란색 버전으로 전달됩니다. 그린 버전이 철저히 테스트되면 트래픽이 완전히 처리되고 블루 버전이 해제될 수 있을 때까지 트래픽이 점차 그린 버전으로 전환됩니다.
   
   
2. 마이크로서비스 아키텍처에는 애플리케이션을 제공하기 위해 함께 작동하는 여러 서비스가 있을 수 있습니다. 블루-그린 배포를 사용하면 이전 버전("블루" 버전)을 계속 실행하면서 각 서비스를 한 번에 하나씩 새 버전("그린" 버전)으로 업데이트합니다. 모든 서비스가 업데이트되면 트래픽을 완전히 처리하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 새 버전으로 전환됩니다.
   
   
3. 클라우드 인프라 환경에서는 고가용성을 보장하기 위해 실행 중인 애플리케이션의 여러 인스턴스가 있을 수 있습니다. 블루-그린 배포를 사용하면 기존 인스턴스("파란색" 인스턴스)와 함께 새 버전의 애플리케이션("녹색" 인스턴스)으로 새 인스턴스 세트를 생성합니다. 트래픽은 처음에 녹색 인스턴스가 테스트되는 동안 파란색 인스턴스로 전달됩니다. 녹색 인스턴스가 철저히 테스트되면 트래픽을 완전히 처리하고 파란색 인스턴스를 폐기할 수 있을 때까지 트래픽이 점차 녹색 인스턴스로 전환됩니다.

블루-그린 배포를 통해 다운타임이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Blue/Green 배포 방식을 사용하는 기업

• Netflix
  Netflix는 블루-그린 배포를 사용하여 새 버전의 소프트웨어를 배포하는 것으로 유명합니다. 예를 들어 스트리밍 서비스를 업데이트할 때 이전 버전("파란색" 서버)과 함께 새로운 서버 집합("녹색" 서버)에 새 버전을 배포합니다. 그린 서버가 완전히 테스트되고 작동되면 트래픽을 완전히 처리할 때까지 트래픽이 점진적으로 이동되며 블루 서버는 해제될 수 있습니다.
  
  
• AWS
  AWS Elastic Beanstalk는 블루-그린 배포 접근 방식을 사용하여 애플리케이션에 업데이트를 배포합니다. 업데이트된 버전의 애플리케이션을 위한 새 환경을 생성하고 트래픽을 완전히 제공할 때까지 점진적으로 트래픽을 라우팅하며 문제가 발생할 경우 이전 환경이 계속 실행됩니다.

Canary(카나리/카나리아) 배포

카나리 배포는 사용자 또는 서버의 작은 하위 집합이 나머지 사용자 또는 서버보다 먼저 새 버전의 애플리케이션으로 업데이트되는 배포 기술입니다. 이를 통해 더 많은 청중에게 배포하기 전에 라이브 환경에서 새 버전을 테스트할 수 있습니다.

"카나리"라는 이름은 유독 가스에 대한 조기 경보 시스템으로 탄광에서 카나리를 사용하는 관행에서 유래되었습니다. 마찬가지로 소프트웨어 개발에서 카나리 배포는 애플리케이션의 새 버전과 관련된 문제나 오류에 대한 조기 경고 시스템 역할을 합니다.

카나리 배포는 사용자 또는 서버의 하위 집합에 새 릴리스를 점진적으로 롤아웃하고 나머지 사용자 또는 서버에 대해 기존 버전을 계속 실행하여 통제된 방식으로 새 소프트웨어 릴리스를 테스트하는 데 사용되는 기술입니다.

• 장점
  
  1. 위험 감소
     카나리 업데이트를 사용하면 모든 사용자에게 배포하기 전에 더 작은 사용자 또는 서버 하위 집합에서 새로운 기능이나 업데이트를 테스트할 수 있으므로 모든 사용자에게 영향을 미치는 문제나 오류의 위험을 줄일 수 있습니다.
     
     
  2. 초기 피드백
     사용자 또는 서버의 더 작은 하위 집합에서 새 업데이트를 테스트함으로써 조직은 모든 ​​사람에게 배포되기 전에 새 버전에 대한 초기 피드백을 받을 수 있습니다.
     
     
  3. 손쉬운 롤백
     새 버전에서 문제가 감지되면 일부 사용자 또는 서버만 영향을 받았기 때문에 이전 버전으로 쉽게 롤백할 수 있습니다.
• 단점
  
  1. 복잡성
     여러 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.
     
     지연된 롤아웃
     새 버전은 일부 사용자 또는 서버에만 롤아웃되므로 모든 사용자 또는 서버에 대한 롤아웃이 지연될 수 있습니다.

카나리 배포는 트래픽 분할, 기능 플래그 또는 점진적 롤아웃과 같은 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 애플리케이션의 성능을 모니터링하면서 애플리케이션을 점진적으로 업데이트하고 필요한 경우 신속하게 롤백하는 방법을 갖추는 것입니다.

작동 방식 예시

1. 많은 사용자에게 서비스를 제공하는 웹 애플리케이션이 있고 새 기능을 릴리스하려고 합니다. 한 번에 모든 사용자에게 기능을 릴리스하는 대신 카나리 배포를 사용하여 사용자 하위 집합에서 새 기능을 테스트하기로 결정합니다.
   
   
2. 소수의 사용자(예: 5%)를 카나리 그룹의 일부로 식별하고 나머지 사용자는 애플리케이션의 기존 버전을 계속 사용합니다.
   
   
3. 새 버전의 애플리케이션을 서버의 하위 집합에 배포하고 사용자 비율에 따라 애플리케이션의 이전 버전과 새 버전 모두에 트래픽을 전달하도록 로드 밸런서를 구성합니다.
   
   
4. 사용자가 사이트를 방문함에 따라 로드 밸런서는 애플리케이션의 새 버전으로 이동하는 사용자 비율을 점진적으로 늘립니다.
   
   
5. 새 버전의 애플리케이션을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인합니다.
   
   
6. 문제가 감지되면 신속하게 배포를 롤백하고 모든 사용자를 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
7. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 새 버전으로 이동하는 사용자 비율을 늘려 모든 사용자에게 점진적으로 새 기능을 출시할 수 있습니다.

카나리 배포를 통해 모든 사용자에게 한 번에 영향을 주지 않고 통제된 환경에서 새로운 기능을 테스트할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Canary 배포 방식을 사용하는 기업

• Facebook
  Facebook은 카나리 배포를 사용하여 소프트웨어의 새 버전을 모든 사용자에게 배포하기 전에 소수의 사용자에게 테스트합니다. 예를 들어 모바일 앱을 업데이트할 때 소규모 사용자 하위 집합에 새 버전을 출시하고 더 많은 사용자에게 점진적으로 출시하기 전에 피드백을 모니터링할 수 있습니다.
  
  
• LinkedIn
  LinkedIn은 카나리 배포를 사용하여 웹 사이트의 새 버전을 테스트합니다. 새 버전을 서버의 하위 집합에 배포하고 점진적으로 트래픽을 해당 서버로 라우팅하면서 나머지 서버에서 이전 버전을 계속 실행합니다. 이를 통해 모든 사용자에게 릴리스하기 전에 실제 환경에서 새 버전을 테스트할 수 있습니다.

Rolling Update 배포

롤링 업데이트 배포는 배포 프로세스 중에 응용 프로그램을 실행하고 사용자가 사용할 수 있도록 유지하면서 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있는 소프트웨어 응용 프로그램을 업데이트하기 위한 전략입니다.

롤링 업데이트 배포는 애플리케이션에 대한 트래픽을 관리하기 위해 로드 밸런서 또는 기타 기술과 함께 자주 사용됩니다. 롤링 업데이트 배포의 주요 이점은 새 버전이 완전히 배포되어 작동할 때까지 애플리케이션의 이전 버전을 계속 사용할 수 있기 때문에 사용자의 중단 및 중단 시간을 최소화한다는 것입니다.

롤링 업데이트를 사용하면 업데이트 프로세스 중에 애플리케이션을 실행하고 사용자가 사용할 수 있도록 유지하면서 애플리케이션의 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있습니다. 새 버전을 한 번에 서버 하위 집합에 배포하고 성능을 면밀히 모니터링함으로써 조직은 모든 ​​사용자 또는 서버에 한 번에 영향을 미치는 문제나 오류의 위험을 최소화할 수 있습니다.

• 장점
  
  1. 가동 중지 시간 최소화
     롤링 업데이트를 통해 상당한 가동 중지 시간이나 사용자 중단 없이 점진적으로 업데이트를 배포할 수 있습니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전의 애플리케이션이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 비용 효율적
     한 번에 한 버전의 애플리케이션만 실행되므로 롤링 업데이트는 인프라 비용이 적게 듭니다.
     
     
• 단점:
  
  1. 더 긴 배포 시간
     새 버전이 모든 서버에 롤아웃되기 전에 서버 하위 집합에 점진적으로 배포되므로 롤링 업데이트를 배포하는 데 시간이 더 오래 걸릴 수 있습니다.
     
     
  2. 문제 위험
     새버전이 점진적으로 배포되기 때문에 배포 과정에서 사용자에게 영향을 미치는 문제 또는 오류의 위험이 있습니다.

작동 방식 예시

1. 애플리케이션의 새 버전을 준비하여 시작합니다. 여기에는 코드 변경, 새 기능 추가 또는 라이브러리 또는 종속성 업데이트가 포함될 수 있습니다.
   
   
2. 나머지 서버에서 실행 중인 이전 버전을 유지하면서 서버의 하위 집합에 새 버전을 배포합니다. 로드 밸런서를 사용하여 애플리케이션의 이전 버전과 새 버전 간에 트래픽을 라우팅할 수 있습니다.
   
   
3. 새 버전의 애플리케이션으로 전달되는 트래픽 비율을 점진적으로 늘립니다. 예를 들어 트래픽의 10%를 새 버전으로 보낸 다음 20%, 50% 등으로 늘릴 수 있습니다.
   
   
4. 애플리케이션의 새 버전을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인하십시오. 문제가 감지되면 신속하게 배포를 롤백하고 트래픽을 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
5. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 트래픽을 새 버전으로 리디렉션하고 이전 버전을 폐기할 수 있습니다.

롤링 업데이트를 사용하면 중단 시간이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Rolling Update 배포를 사용하는 기업

Google
Google은 롤링 업데이트를 자주 사용하여 새 버전의 서비스를 배포합니다. 예를 들어 검색 엔진 알고리즘을 업데이트할 때 서버의 하위 집합에 새 버전을 점진적으로 롤아웃하고 나머지 서버에서는 이전 버전을 계속 실행합니다. 이를 통해 Google은 새 버전을 면밀히 모니터링하고 문제나 버그를 식별하며 필요한 경우 신속하게 배포를 롤백할 수 있습니다. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 서버에 출시됩니다.

이 글을 읽고 배포 방법을 결정할 때 유의할 점은 "Google이 쓰니까 이게 더 좋은거야"라는 생각은 금물이라는 것 입니다. 각자가 맡은 프로젝트가 어떤 것인지 잘 파악하고, 어떤 방식으로 진행하는것이 더 효율적이고 비용절감이 가능할지 생각하는게 먼저가 되야합니다.

쿠버네티스의 거의 모든 명령어에서 (아마 전부일 가능할 듯 합니다.) yaml 형식으로 볼 수 있는데, 이를 리다이렉션 기호(>)를 사용해 파일로 만들 수 있습니다. 그 중 생성 및 실행을 한번에 하는 kubectl run을 이용해 알아보도록 하겠습니다.

먼저 yaml 형식으로 보는 옵션은 -o yaml 입니다. 이를 명령어에 끼워주면 해당 내용을 볼 수 있습니다.

이 yaml 디스크립터에서 사용한 API 버전

• apiVersion: v1 (API 버전)

쿠버네티스 오브젝트/리소스 유형

•  kind: Pod (파드 오브젝트를 정의)

파드 메타데이터

•  metadata (해당 파드의 메타데이터를 정의)
•  creationTimestamp (파드가 생성된 시간)
•  labels (해당 파드에 적용된 라벨을 정의)
•  name (파드의 이름을 나타냅니다.)
•  namespace (파드가 생성될 네임스페이스를 나타냅니다.)
•  resourceVersion (해당 오브젝트의 버전을 나타냅니다.)
•  uid (해당 오브젝트의 고유 식별자를 나타냅니다.)

파드 정의와 내용

•  spec (파드의 구성을 정의합니다.)
•  containers (파드에 포함될 컨테이너를 정의합니다.)
•  image (사용될 이미지를 정의합니다.)
•  imagePullPolicy (이미지를 가져올 방법을 정의합니다.)
•  name (컨테이너의 이름을 나타냅니다.)
•  resources (컨테이너에 할당할 리소스를 정의합니다.)
•  terminationMessagePath (컨테이너 종료 시 출력할 메시지를 저장할 경로를 나타냅니다.)
•  terminationMessagePolicy (종료 시 출력할 메시지의 저장 방법을 나타냅니다.)
•  volumeMounts (컨테이너에 마운트할 볼륨을 정의합니다.)
•  mountPath (볼륨을 마운트할 경로를 정의합니다.)
•  readOnly (볼륨을 읽기 전용으로 마운트할지 여부를 정의합니다.)
•  dnsPolicy (DNS 정책을 나타냅니다.)
•  enableServiceLinks (서비스 링크 사용 여부를 정의합니다.)
•  preemptionPolicy (선점 정책을 나타냅니다.)
•  priority (우선순위를 정의합니다.)
•  restartPolicy (컨테이너 재시작 정책을 나타냅니다.)
•  schedulerName (사용할 스케줄러의 이름을 정의합니다.)
•  securityContext (보안 컨텍스트를 정의합니다.)
•  serviceAccount (파드에서 사용할 서비스 계정의 이름을 나타냅니다.)
•  serviceAccountName (파드에서 사용할 서비스 계정의 이름을 나타냅니다.)
•  terminationGracePeriodSeconds (컨테이너를 종료하기 위해 기다리는 시간을 정의합니다.)
•  tolerations (허용 정책을 나타냅니다)
•  effect (정책의 영향을 정의합니다.)
•  key (정책에서 사용될 키를 나타냅니다.)
•  operator (정책에서 사용될 연산자를 나타냅니다.)
•  tolerationSeconds (정책을 허용하는 시간을 정의합니다.)
•  volumes (파드에서 사용될 볼륨을 정의합니다.)
•  projected (여러 볼륨 소스를 하나의 볼륨으로 집합하는 프로젝션을 정의합니다.)
•  defaultMode (볼륨에서 파일 권한을 설정하는 데 사용됩니다.)
•  sources (프로젝션에서 사용할 볼륨 소스를 정의합니다.)
•  serviceAccountToken (서비스 계정 토큰을 사용할 수 있도록 합니다.)
•  expirationSeconds (토큰의 만료 시간을 정의합니다.)
•  path (토큰을 사용할 경로를 나타냅니다.)
•  configMap (구성 맵에서 데이터를 사용합니다.)
•  items (구성 맵에서 사용할 데이터를 정의합니다.)
•  downwardAPI (다운워드 API를 사용합니다.)
•  fieldRef (다운워드 API에서 사용할 필드의 참조를 정의합니다.)
•  apiVersion (API 버전을 나타냅니다.)
•  fieldPath (필드의 경로를 나타냅니다.)
•  metadata (메타데이터를 사용합니다.)
• namespace (네임스페이스를 사용합니다.)

파드와 그 안의 여러 컨테이너의 상세한 상태

•  status (파드의 상태를 정의합니다.)
•  phase (파드의 현재 상태를 나타냅니다.)
•  qosClass (파드의 QoS 클래스를 나타냅니다.)

각 줄마다의 내용을 정리하였고, 이 내용들을 암기하는 것 보다는 어떤 내용이 필요하고 어떤 내용은 필요 없는지 살펴볼 수 있는 눈을 기르는 것이 중요합니다. 이후에 이 구성이 어떻게 사용되는지 어떤 것이 필요한지 포스팅해보도록 하겠습니다. 혹시 궁금한 것이 있다면 댓글을 남겨주세요. 그 내용에 대해 먼저 조사해보도록 하겠습니다. :)

목차

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
2. 문제점 예시
3. 개별 확장이 가능하도록 파드를 분할하자.
4. 파드에서 여러 컨테이너를 사용하는 경우

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
   
   파드를 각각 별도의 머신으로 생각할 수도 있을 것 같습니다. 하지만, 파드는 특정한 애플리케이션만을 호스팅합니다. 즉, 한 호스트에 모든 유형의 애플리케이션을 넣었던 이전과 달리, 파드는 그렇게 사용하지 않는다는 뜻입니다. 파드는 상대적으로 가볍기 때문에 오버헤드 없이 필요한 만큼 파드들을 가질 수 있습니다. 모든 것을 파드 하나에 넣는 대신 애플리케이션을 여러 파드로 구성하고, 각 파드에는 밀접하게 관련있는 구성 요소나 프로세스만 포함해야 합니다.
   
   그렇다면 프론트엔드 애플리케이션 서버와 백엔드 데이터베이스로 구성된 다중 레이어 애플리케이션을 구성할 때 단일 파드 또는 두개의 파드로 구성해야만 할까요?
   
   이전에 다루었던 것과 마찬가지로 하나의 파드에는 하나의 컨테이너를 동작시키는 것을 권장했었는데요. 일반적으로 프런트엔드 애플리케이션 서버와 백엔드 데이터베이스도 마찬가지로 두 개의 별도 포드로 분리하는 것이 좋은데, 리소스 요구 사항과 확장 요구 사항이 다르기 때문입니다.
   
   프런트엔드 애플리케이션 서버는 사용자 요청을 처리하고 애플리케이션 로직을 실행하기 위해 더 많은 CPU 및 메모리 리소스가 필요할 수 있는 반면, 백엔드 데이터베이스는 데이터를 관리하기 위해 더 많은 스토리지 및 디스크 I/O 리소스가 필요할 수 있습니다. 또한 증가된 트래픽을 처리하기 위해 프런트엔드 애플리케이션 서버를 수평으로 확장해야 할 수 있는 반면 백엔드 데이터베이스는 증가한 데이터 볼륨을 처리하기 위해 수직으로 확장해야 할 수 있습니다.
   
   프런트엔드와 백엔드를 두 개의 별도 포드로 분리하면 내결함성과 안정성이 향상됩니다. Pod 중 하나에 오류가 발생하면 다른 포드가 중단 없이 계속 작동하여 전체 애플리케이션에 대한 오류의 영향을 줄일 수 있습니다.
   
   
2. 문제점 예시
   
   실제로 프론트엔드 서버와 데이터베이스 컨테이너 두 개로 구성된 단일 파드를 실행하지 못하는 것은 아닙니다. 하지만 프론트엔드와 백엔드가 같은 파드에 있다면, 둘은 항상 같은 노드에서 실행될 것 입니다. 만약에 두 노드를 가진 쿠버네티스 클러스터가 있고 이 파드 하나만 있다면, 워커 노드 하나만 사용하고 두 번째 노드에서 이용할 수 있는 컴퓨팅 소스(GPU, 메모리)를 활용하지 않고 그냥 버리게 됩니다. 파드를 두 개로 분리한다면 쿠버네티스가 프론트엔드를 한 노드로 그리고 백엔드는 다른 노드에 스케줄링해 인프라스트럭처의 활용도를 향상시킬 수 있습니다.
   
   
3. 개별 확장이 가능하도록 파드를 분할하자.
   
   두 컨테이너를 하나의 파드에 넣지 말아야 하는 또 다른 이유는 스케일링 때문입니다. 파드는 스케일링의 기본 단위인데, 쿠버네티스는 개별 컨테이너를 수평으로 확장할 수 없습니다. 대신 전체 파드를 수평으로 확장합니다. 만약 프론트엔드와 백엔드 컨테이너로 구성된 파드를 두 개로 늘리면, 결국 프론트엔드 컨테이너 두 개와 백엔드 컨테이너 두 개를 갖습니다.
   
   위에서 설명한 것 처럼 일반적으로 프론트엔드 구성 요소는 백엔드와 완전히 다른 스케일링 요구 사항을 갖고 있어 개별적으로 확장하는 경향이 있습니다. 데이터 베이스와 같은 벡엔드는 (상태를 갖지 않는) 프론트엔드 웹 서버에 비해 확장하기가 훨씬 어렵습니다. 컨테이너를 개별적으로 스케일링하는 것이 필요하다면, 별도 파드에 배포해야 합니다.
   
   
4. 파드에서 여러 컨테이너를 사용하는 경우
   
   보통 하나의 파드에 여러 컨테이너가 들어간다면 그것은 밀접하게 관련되어 있으며, 일반적으로 주 컨테이너와 보조 컨테이너로 이루어 집니다. 이러한 방법은 다양한 시나리오에서 유용할 수 있지만 각 컨테이너의 책임과 리소스 요구 사항을 신중하게 고려해야 합니다.
   
   
   1. 사이드카 패턴
      Pod 내의 여러 컨테이너에 대한 일반적인 사용 사례는 기본 컨테이너가 기본 애플리케이션 로직을 실행하고 사이드카로 알려진 보조 컨테이너가 지원 서비스를 실행하는 사이드카 패턴입니다. 예를 들어 캐싱 및 연결 관리를 처리하는 사이드카 컨테이너를 통해 Redis 데이터베이스와 통신하는 웹 애플리케이션 컨테이너가 있을 수 있습니다.
      
      
   2. 다중 컨테이너 애플리케이션
      Pod 내 다중 컨테이너의 또 다른 사용 사례는 함께 실행해야 하는 여러 구성 요소로 구성된 복잡한 애플리케이션이 있는 경우입니다. 예를 들어 각 마이크로서비스가 단일 Pod 내의 자체 컨테이너에서 실행되는 마이크로서비스 기반 애플리케이션이 있을 수 있습니다.
      
      
   3. 로깅 및 모니터링
      Pod 내의 여러 컨테이너에 대한 또 다른 일반적인 사용 사례는 로깅 및 모니터링입니다. 기본 애플리케이션 논리를 실행하는 기본 컨테이너와 로그 및 메트릭을 수집하여 중앙 모니터링 시스템으로 보내는 보조 컨테이너가 있을 수 있습니다.
      
      
   4. 도우미 컨테이너
      데이터 백업, 구성 관리 또는 주기적인 데이터 처리와 같은 도우미 작업을 위해 Pod 내에서 여러 컨테이너를 사용할 수도 있습니다.
      
      
   5. 주요 컨테이너에 보완 프로세스 추가
      파드 안에 주 컨테이너는 특정 디렉터리에서 파일을 제공하는 웹 서버일 수 있으며, 추가 컨테이너는 외부 소스에서 주기적으로 콘텐츠를 받아 웹 서버의 디렉터리에 저장합니다. 두 컨테이너를 모두에 마운트하는 방법이 있는데, 이에 대해서는 차후에 다뤄보도록 하겠습니다.
      
      * 사이드카 컨테이너가 실제 사용 되는 예를 들어보자면, 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등이 있습니다.
      
      
5. 파드에서 여러 컨테이너를 사용하는 경우 고려해볼 사항
   
   컨테이너를 파드로 묶어 그룹으로 만들 떄는, 즉 두 개의 컨테이너를 단일 파드로 넣을지 아니면 두 개의 별도 파드에 넣을지를 결정하기 위해서는 다음과 같은 질문에 대해 생각해봐야 할 필요가 있습니다.
   
   
   1. 컨테이너를 함께 실행해야 하는가, 혹은 서로 다른 호스트에서 실행할 수 있는가?
   2. 여러 컨테이너가 모여 하나의 구성 요소를 나타내는가, 혹은 개별적인 구성 요소인가?
   3. 컨테이너가 함께, 혹은 개별적으로 스케일링돼야 하는가?

기본적으로 특정한 이유 때문에 컨테이너를 단일 파드로 구성하는 것을 요구하지 않는다면, 분리된 파드에서 컨테이너를 실행하는 것이 좋습니다.

이번 포스팅은 구분선이 존재하지 않아 글을 읽는데 어려움을 느끼셨을지도 모르겠습니다. 아직 시작한지 얼마 되지 않아 다양한 시도를하고 있고, 해당 내용은 한 가지 내용에 대해 여러 측면을 설명하다 보니 이런 형식을 띄게 되었습니다. 피드백, 욕설, 칭찬 모두 환영합니다. 어떤 의견이든 댓글로 남겨주시면 그에 대해 조사하거나, 조취를 취해보겠습니다. 오늘도 읽어주셔서 감사합니다!

목차

1. kubeadm init 
2. kubeadm token
3. kubeadm join
4. kubeadm list
5. kubeadm reset

kubeadm init

kubeadm init 명령어는 Kubernetes 클러스터를 초기화하여 새로운 마스터 노드를 생성하는 명령어입니다. 이 명령어는 Kubernetes 클러스터를 처음 만들 때 실행하며, 필요한 구성 요소를 설치하고 초기화 파일을 생성합니다.

1. 기본 구조
   kubeadm init [옵션]
   
   예시: kubeadm init --pod-network-cidr=10.244.0.0/16
   10.244.0.0/16 CIDR 범위의 Pod 네트워크를 생성하면서 Kubernetes 클러스터를 초기화합니다.
   
   
2. 옵션
   
   • --config: 초기화에 사용할 구성 파일을 지정합니다.
     
     예시: kubeadm init --config=my-config.yaml
      (my-config.yaml 파일에 지정된 구성 파일을 사용하여 Kubernetes 클러스터를 초기화합니다.)
     
     
   • --token: 클러스터에 대한 액세스를 허용하는 토큰을 생성합니다.
     
     예시: kubeadm init --token abcdef.1234567890abcdef 
     (액세스를 허용하는 토큰이 abcdef.1234567890abcdef인 Kubernetes 클러스터를 초기화합니다.)
     
     
   • --pod-network-cidr: 클러스터에 대한 Pod 네트워크 CIDR 범위를 지정합니다.
     
     예시: kubeadm init --pod-network-cidr=10.244.0.0/16 
     (10.244.0.0/16 CIDR 범위의 Pod 네트워크를 생성하면서 Kubernetes 클러스터를 초기화합니다.)
     
     
   • --apiserver-cert-extra-sans: 마스터 노드 인증서에 추가할 DNS 이름을 지정합니다.
     
     예시: kubeadm init --apiserver-cert-extra-sans=www.example.com 
     (마스터 노드 인증서에 www.example.com DNS 이름을 추가하면서 Kubernetes 클러스터를 초기화합니다.)
     
     
   • --skip-phases: 특정 초기화 단계를 건너뜁니다.
     
     예시: kubeadm init --skip-phases=addon/kube-proxy
     (kube-proxy 애드온 초기화를 건너뜁니다.)

kubeadm token

kubeadm token 명령어는 Kubernetes 클러스터에서 토큰을 생성하고 관리하는 명령어입니다. 토큰은 클러스터에 대한 액세스를 제어하고, 클러스터 노드 간의 인증을 관리하는 데 사용됩니다.

1. 기본 구조
   
   
   1. 토큰 생성
      kubeadm token create
      
      kubeadm token create 명령어를 사용하여 새로운 토큰을 생성합니다. 이 명령어는 kubeadm join 명령어를 사용하여 워커 노드를 클러스터에 추가할 때 사용됩니다.
      
      
   2. 토큰 조회
      kubeadm token list
      
      kubeadm token list 명령어를 사용하여 현재 사용 가능한 토큰 목록을 조회합니다.
      
      
   3. 토큰 삭제
      kubeadm token delete [토큰]
      
      kubeadm token delete 명령어를 사용하여 특정 토큰을 삭제합니다.
      
      
2. 옵션
   
   • create: 새로운 토큰을 생성합니다.
     
     예시: kubeadm token create --ttl 24h --print-join-command
      (24시간 동안 유효한 토큰을 생성하고, kubeadm join 명령어를 출력합니다.)
     
     
   • delete: 토큰을 삭제합니다.
     
     예시: kubeadm token delete abcdef.1234567890abcdef 
     (abcdef.1234567890abcdef 토큰을 삭제합니다.)
     
     
   • list: 사용 가능한 토큰 목록을 조회합니다.
     
     예시: kubeadm token list
     (사용 가능한 토큰 목록을 조회합니다.)

kubeadm join

kubeadm join 명령어는 Kubernetes 클러스터에 새로운 워커 노드를 추가하는 명령어입니다. 이 명령어를 사용하여 워커 노드를 클러스터에 추가하려면, kubeadm init 명령어로 생성한 마스터 노드에서 생성된 토큰과 디스커버리 토큰 CA 인증서 해시를 사용하여 인증해야 합니다.

1. 기본 구조
   kubeadm join [마스터 노드 IP]:[포트] --token [토큰] --discovery-token-ca-cert-hash [디스커버리 토큰 CA 인증서 해시]
   
   예시: kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
   
   마스터 노드 IP가 192.168.0.1이고, 토큰이 abcdef.1234567890abcdef이며, 디스커버리 토큰 CA 인증서 해시가 sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef인 워커 노드를 추가할 수 있습니다.
   
   
2. 옵션
   
   • --token: 클러스터에 대한 액세스를 허용하는 토큰을 지정합니다.
     
     예시: kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef
      (액세스를 허용하는 토큰이 abcdef.1234567890abcdef인 워커 노드를 추가합니다.)
     
     
   • --discovery-token-ca-cert-hash: 디스커버리 토큰 CA 인증서 해시를 지정합니다.
     
     예시: kubeadm join 192.168.0.1:6443 --discovery-token-ca-certhash\ sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
     (디스커버리 토큰 CA 인증서 해시가 sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef인 워커 노드를 추가합니다.)
     
     * \ 는 아랫줄까지 한줄로 쓰겠다는 의미입니다.
     
     
   • --control-plane: 마스터 노드에서 실행되는 Kubernetes 컨트롤 플레인 구성 요소를 설치합니다.
     
     예시: `kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890
     
     
   • --certificate-key: 마스터 노드에서 생성된 인증서 키를 지정합니다.
     
     예시: kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef --certificate-key abcdef1234567890
      (인증서 키가 abcdef1234567890인 워커 노드를 추가합니다.)
     
     
   • --cri-socket: 사용할 CRI 소켓 경로를 지정합니다.
     
     예시: kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef --cri-socket /var/run/dockershim.sock 
     (Docker CRI를 사용하고, /var/run/dockershim.sock CRI 소켓을 사용하는 워커 노드를 추가합니다.)
     
     
   • --discovery-file: 디스커버리 토큰 파일의 경로를 지정합니다.
     
     예시: kubeadm join 192.168.0.1:6443 --discovery-file=/etc/kubernetes/discovery-token-ca-cert-hash.txt
     (/etc/kubernetes/discovery-token-ca-cert-hash.txt 파일에서 디스커버리 토큰 CA 인증서 해시를 읽어들여 워커 노드를 추가합니다.)
     
     
   • --skip-preflight-checks: 사전 검사를 건너뜁니다.
     
     예시: kubeadm join 192.168.0.1:6443 --token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef --skip-preflight-checks
     (사전 검사를 건너뛰고 워커 노드를 추가합니다.)

kubeadm list

kubeadm list 명령어는 Kubernetes 클러스터의 상태를 확인하는 명령어입니다. 이 명령어를 사용하여, 현재 클러스터의 노드, 구성 요소 및 버전을 확인할 수 있습니다.

1. 기본 구조
   kubeadm list [component]
   
   component는 확인하려는 구성 요소를 지정합니다. 지정하지 않으면, 모든 구성 요소를 확인합니다. 구성 요소는 다음과 같습니다.
   
   
   1. kube-apiserver
   2. kube-controller-manager
   3. kube-scheduler
   4. etcd
   5. kube-proxy
   6. kubelet
      
      예: sudo kubeadm list kubelet 명령어를 실행하여 현재 클러스터의 모든 kubelet 구성 요소를 확인할 수 있습니다.
2. 다음은 kubeadm list 명령어에서 자주 사용되는 옵션들입니다.
   
   • --kubeconfig: kubeconfig 파일을 지정합니다.
     
     예시: sudo kubeadm list --kubeconfig=/path/to/kubeconfig
     
     
   • --output: 출력 형식을 지정합니다.
     
     예시: sudo kubeadm list --output=json
      (JSON 형식으로 출력합니다.)
     
     

kubeadm list --help 명령어를 통해 자세한 정보를 확인할 수 있습니다.kubeadm reset 명령어는 Kubernetes 클러스터에서 kubeadm init 명령어로 생성한 초기화 구성을 삭제하여 클러스터를 초기 상태로 되돌리는 명령어입니다. 이 명령어를 사용하면 클러스터의 모든 구성 요소와 설정이 삭제됩니다.

kubeadm reset

kubeadm reset 명령어는 Kubernetes 클러스터에서 현재 노드를 초기화하는 명령어입니다. 이 명령어를 사용하여, 노드에서 Kubernetes 클러스터를 제거하고, 모든 설정 파일과 데이터를 삭제할 수 있습니다.

1. 기본적인 사용 방법은 다음과 같습니다.
   kubeadm reset
   
   이 명령어를 실행하면, 다음과 같은 작업이 수행됩니다.
   
   1. 모든 Kubernetes 구성 요소와 컨테이너를 제거합니다.
   2. 모든 네트워크 설정을 제거합니다.
   3. 모든 Kubernetes 설정 파일을 삭제합니다.
   4. 모든 데이터를 삭제합니다.
2. 옵션들에 대해 알아보겠습니다.
   
   • --cri-socket: CRI 소켓 경로를 지정합니다. 이 옵션을 사용하여 kubelet이나 kubeadm에 등록된 CRI 구현체의 소켓을 사용합니다.
     
     예시: sudo kubeadm reset --cri-socket=/var/run/dockershim.sock 
     (dockershim을 사용하여 초기화합니다.)
     
     
   • --force: 초기화 작업을 강제로 수행합니다.
     
     예시: sudo kubeadm reset --force
      (강제 초기화를 수행합니다.)
     
     
   • --skip-phases: 특정 초기화 단계를 건너뜁니다.
     
     예시: sudo kubeadm reset --skip-phases=all 
     (모든 초기화 단계를 건너뜁니다.)
     
     --dry-run: 실제로 초기화 작업을 수행하지 않고, 초기화 작업을 출력합니다.
     
     예시: sudo kubeadm reset --dry-run 
     (초기화 작업을 수행하지 않고, 초기화 작업을 출력합니다.)

드디어 쿠버네티스 명령어 시리즈가 마무리되었습니다. kubectl과 kubeadm은 둘 다 쿠버네티스에서 많이 사용된다고 합니다. 바로 이전에 설명했듯이 꼭 다 암기해야 하는 것은 아니고, 이런게 있구나 생각하시고 나중에 이런게 필요하다 할 때 찾아보시면 될 것 같습니다. 

혹시나 이외에 더 알고 싶은 명령어나 옵션이 있다면 댓글 남겨주시면 조사해보도록 하겠습니다. 감사합니다.                                                                                                           

목차

1. kubectl port-forward
2. kubectl auth reconcile
3. kubectl attach
4. kubectl certificate
5. kubectl proxy

kubectl port-forward

kubectl port-forward 명령어는 로컬 시스템과 Kubernetes 클러스터 내부의 서비스 또는 파드를 연결하는 명령어입니다. 이 명령어를 사용하면, 로컬 시스템에서 Kubernetes 클러스터 내부의 서비스나 파드에 접근할 수 있습니다.

1. 기본 구조
   kubectl port-forward [리소스 이름] [로컬 포트]:[원격 포트]
   
   예시: kubectl port-forward my-pod 8080:80
   my-pod 이름의 파드 내부의 80번 포트를 로컬 시스템의 8080번 포트와 연결할 수 있습니다.
   
   
2. 옵션
   
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다
     .
     예시: kubectl port-forward my-service --namespace my-namespace 8080:80
      (my-namespace 네임스페이스에 속한 my-service 이름의 서비스 내부의 80번 포트를 로컬 시스템의 8080번 포트와 연결합니다.)
     
     
   • --address: 로컬 주소를 지정합니다.
     
     예시: kubectl port-forward my-pod 127.0.0.1:8080:80 
     (my-pod 이름의 파드 내부의 80번 포트를 로컬 시스템의 127.0.0.1 주소의 8080번 포트와 연결합니다.)

kubectl auth reconcile

kubectl auth reconcile 명령어는 Kubernetes 클러스터의 사용자 인증 정보를 재조정하는 명령어입니다. 이 명령어를 사용하면, 사용자 인증 정보를 갱신하여 권한 부여를 업데이트할 수 있습니다.

1. 기본 구조
   kubectl auth reconcile -f [파일 경로]
   
   예시: kubectl auth reconcile -f ./rbac.yaml
   현재 클러스터에 적용된 ./rbac.yaml 파일의 권한 부여를 재조정할 수 있습니다.
   
   
2. 옵션
   
   • -f, --filename: 대상 파일을 지정합니다.
     
     예시: kubectl auth reconcile -f ./rbac.yaml 
     (./rbac.yaml 파일의 권한 부여를 재조정합니다.)
     
     
   • --dry-run: 실제 작업을 수행하지 않고 결과만 확인합니다.
     
     예시: kubectl auth reconcile -f ./rbac.yaml --dry-run 
     (실제 작업을 수행하지 않고 ./rbac.yaml 파일의 재조정 결과만 확인합니다.)

kubectl attach

kubectl attach 명령어는 실행 중인 파드에 연결하여 해당 파드의 터미널 세션에 접속하는 명령어입니다. 이 명령어를 사용하면, 파드의 로그를 보거나 디버깅을 위한 목적으로 파드 내부로 들어갈 수 있습니다.

1. 기본 구조
   kubectl attach [파드 이름] -c [컨테이너 이름]
   
   예시: kubectl attach my-pod -c my-container
   my-pod 파드의 my-container 컨테이너 내부의 터미널 세션에 접속할 수 있습니다.
   
   
2. 옵션
   
   • -c, --container: 컨테이너 이름을 지정합니다.
     
     예시: kubectl attach my-pod -c my-container
      (my-pod 파드의 my-container 컨테이너 내부의 터미널 세션에 접속합니다.)
     
     
   • --stdin, --tty: 터미널 입력/출력을 가능하게 합니다.
     
     예시: kubectl attach my-pod -c my-container --stdin --tty
      (my-pod 파드의 my-container 컨테이너 내부의 터미널 세션에 접속하면서 터미널 입력/출력을 가능하게 합니다.)

kubectl certificate

kubectl certificate 명령어는 Kubernetes 클러스터 내에서 인증서와 관련된 작업을 수행하는 명령어입니다. 이 명령어를 사용하면, 인증서를 생성하거나 관리할 수 있습니다.

현재 Kubernetes v1.21에서는 kubectl certificate 명령어가 deprecated 되었으며, 대신 kubectl create certificate 명령어를 사용할 것을 권장합니다.

1. 기본 구조
   kubectl create certificate [이름] --cert [인증서 파일 경로] --key [개인 키 파일 경로]
   
   예시: kubectl create certificate my-cert --cert=./my-cert.crt --key=./my-cert.key
   my-cert.crt 파일과 my-cert.key 파일을 사용하여 my-cert 인증서를 생성할 수 있습니다.
   
   
2. 옵션
   
   • --cert: 인증서 파일 경로를 지정합니다.
     
     예시: kubectl create certificate my-cert --cert=./my-cert.crt --key=./my-cert.key 
     (my-cert.crt 파일을 사용하여 인증서를 생성합니다.)
     
     
   • --key: 개인 키 파일 경로를 지정합니다.
     
     예시: kubectl create certificate my-cert --cert=./my-cert.crt --key=./my-cert.key 
     (my-cert.key 파일을 사용하여 인증서를 생성합니다.)
     
     
   • --namespace: 네임스페이스를 지정합니다.
     
     예시: kubectl create certificate my-cert --cert=./my-cert.crt --key=./my-cert.key --namespace=my-namespace
     (my-namespace 네임스페이스에 my-cert 인증서를 생성합니다.)

kubectl proxy

kubectl proxy 명령어는 Kubernetes API 서버를 로컬에서 실행하여, API 서버와 통신할 수 있는 프록시를 제공하는 명령어입니다. 이 명령어를 사용하면, 로컬에서 실행 중인 클라이언트에서 API 서버에 직접 접속하지 않고도 API 서버와 통신할 수 있습니다.

1. 기본 구조
   kubectl proxy
   http://localhost:8001/ URL을 통해 API 서버와 통신할 수 있습니다.
   
   
2. 옵션
   
   1. --port: 프록시 서버가 사용할 포트 번호를 지정합니다.
      
      예시: kubectl proxy --port=8080
       (프록시 서버를 8080 포트에서 실행합니다.)
      
      
   2. --address: 프록시 서버가 사용할 IP 주소를 지정합니다.
      
      예시: kubectl proxy --address=0.0.0.0
       (프록시 서버를 모든 IP 주소에서 실행합니다.)

드디어 kubectl은 마무리가 되었습니다. 생각보다 종류가 많기도 하고, 옵션도 다양해서 어제부터 정리했는데 이제야 끝이 보이네요. 하지만 이 모든 명령어를 암기할 필요는 없습니다. 자주 사용하는 명령어는 자연스래 익숙해질 것이고, 그게 아니라면 찾아보면 되니까요. 쿠버네티스 시험에서도 쿠버네티스 홈페이지에서 명령어를 검색해 볼 수 있다고 하니 말 다했죠.

목차

1. Kubectl rollout
   1. Kubectl rollout status
   2. Kubectl rollout undo
   3. Kubectl rollout history
   4. Kubectl rollout pause
   5. Kubectl rollout resume
2. Kubectl apply

kubectl rollout

kubectl rollout 명령어는 Kubernetes 클러스터에서 롤아웃 작업을 관리하는 명령어입니다. 이 명령어를 사용하면, 디플로이먼트, 데몬셋, 상태풀셋 등의 리소스에 대한 롤아웃 작업을 수행할 수 있습니다.

1. kubectl rollout 명령어에는 다양한 하위 명령어가 있으며, 주요 명령어들은 다음과 같습니다.
   
   • kubectl rollout status: 롤아웃 작업의 상태를 확인합니다.
   • kubectl rollout history: 롤아웃 작업의 이력을 확인합니다.
   • kubectl rollout undo: 롤아웃 작업을 취소하고 이전 버전으로 롤백합니다.
   • kubectl rollout restart: 롤아웃 작업을 재시작합니다.
   • kubectl rollout pause/resume: 롤링 업데이트를 일시 중지하거나 다시 시작합니다.
2. 기본 구조
   kubectl rollout [하위 명령어] [리소스 종류]/[리소스 이름]
   
   예시: kubectl rollout status deployment/my-deployment
   my-deployment 디플로이먼트의 롤아웃 상태를 확인할 수 있습니다.
   
   
3. 옵션
   
   • --revision: 롤아웃 작업에서 사용할 리비전 번호를 지정합니다.
     
     예시: kubectl rollout undo deployment/my-deployment --to-revision=2
     (my-deployment 디플로이먼트를 2번 리비전으로 롤백합니다.)
     
     
   • --dry-run: 실제로 명령어를 실행하지 않고, 실행 결과만 미리 확인합니다.
     
     예시: kubectl rollout restart deployment/my-deployment --dry-run
     (my-deployment 디플로이먼트를 재시작할 때, 실제로는 실행하지 않고 결과만 미리 확인합니다.)

kubectl rollout status

kubectl rollout status 명령어는 Kubernetes 클러스터에서 롤아웃 작업의 상태를 확인하는 명령어입니다. 이 명령어를 사용하면, 롤아웃 작업이 완료될 때까지 대기하거나, 롤아웃 작업이 중단되었는지 확인할 수 있습니다.

1. 기본 구조
   kubectl rollout status [리소스 종류]/[리소스 이름]
   
   예시: kubectl rollout status deployment/my-deployment
   my-deployment 디플로이먼트의 롤아웃 상태를 확인할 수 있습니다.
   
   
2. 옵션
   
   • --watch: 롤아웃 상태를 실시간으로 확인합니다.
     
     예시: kubectl rollout status deployment/my-deployment --watch
     (my-deployment 디플로이먼트의 롤아웃 상태를 실시간으로 확인합니다.)
     
     
   • --timeout: 대기 시간을 지정합니다. 이 시간을 초과하면 명령어가 종료됩니다.
     
     예시: kubectl rollout status deployment/my-deployment --timeout=60s 
     (my-deployment 디플로이먼트의 롤아웃이 60초 이내에 완료되지 않으면 명령어가 종료됩니다.)

kubectl rollout undo

kubectl rollout undo 명령어는 Kubernetes 배포를 이전 버전으로 롤백하는 명령어입니다. 이 명령어를 사용하면, 배포를 이전 버전으로 복원할 수 있습니다.

1. 기본 구조
   kubectl rollout undo [리소스 종류] [리소스 이름]
   
   예시: kubectl rollout undo deployment/my-deployment
   my-deployment 이름의 배포를 이전 버전으로 롤백할 수 있습니다.
   
   
2. 옵션
   
   • --to-revision: 롤백할 배포의 리비전 번호를 지정합니다.
     
     예시: kubectl rollout undo deployment/my-deployment --to-revision=2
      (my-deployment 이름의 배포를 2번 리비전으로 롤백합니다.)
     
     
   • --dry-run: 실제로 롤백하지 않고 실행 결과만 확인합니다.
     
     예시: kubectl rollout undo deployment/my-deployment --dry-run 
     (my-deployment 이름의 배포를 실제로 롤백하지 않고 실행 결과만 확인합니다.)

kubectl rollout history

kubectl rollout history 명령어는 Kubernetes 배포의 이전 롤아웃 기록을 확인하는 명령어입니다. 이 명령어를 사용하면, 배포의 이전 버전들과 그 버전들의 상태를 확인할 수 있습니다.

1. 기본 구조
   kubectl rollout history [리소스 종류] [리소스 이름]
   
   예시: kubectl rollout history deployment/my-deployment
   명령어를 실행하여 my-deployment 이름의 배포의 이전 롤아웃 기록을 확인할 수 있습니다.
   
   
2. 옵션
   
   1. --revision: 특정 리비전의 상세 정보를 확인합니다.
      
      예시: kubectl rollout history deployment/my-deployment --revision=2 
      (my-deployment 이름의 배포의 2번 리비전의 상세 정보를 확인합니다.)
      
      
   2. --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
      
      예시: kubectl rollout history deployment/my-deployment --namespace my-namespace 
      (my-namespace 네임스페이스에 속한 my-deployment 이름의 배포의 이전 롤아웃 기록을 확인합니다.)

kubectl rollout restart

kubectl rollout restart 명령어는 Kubernetes 클러스터에서 디플로이먼트, 데몬셋, 상태풀셋 등의 리소스를 다시 시작하는 롤아웃 작업을 수행하는 명령어입니다. 이 명령어를 사용하면, 롤아웃 작업을 수행하지 않고도 리소스를 새로 시작할 수 있습니다.

1. 기본 구조
   kubectl rollout restart [리소스 종류]/[리소스 이름]
   
   예시: kubectl rollout restart deployment/my-deployment
   my-deployment 디플로이먼트를 다시 시작할 수 있습니다.
   
   
2. 옵션
   
   • --selector: 라벨 셀렉터를 사용하여 리소스를 선택합니다.
     
     예시: kubectl rollout restart deployment --selector=app=nginx
      (app=nginx 라벨을 가진 모든 디플로이먼트를 다시 시작합니다.)

kubectl rollout pause

kubectl rollout pause 명령어는 Kubernetes 클러스터에서 디플로이먼트, 데몬셋, 상태풀셋 등의 롤아웃 작업을 일시 중지하는 명령어입니다. 이 명령어를 사용하면, 롤아웃 작업을 일시 중지하여 문제를 진단하고 해결할 수 있습니다.

1. 기본 구조
   kubectl rollout pause [리소스 종류]/[리소스 이름]
   
   예시: kubectl rollout pause deployment/my-deployment
   my-deployment 디플로이먼트의 롤아웃 작업을 일시 중지할 수 있습니다.
   
   
2. 옵션
   
   • --selector: 라벨 셀렉터를 사용하여 리소스를 선택합니다.
     
     예시: kubectl rollout pause deployment --selector=app=nginx 
     (app=nginx 라벨을 가진 모든 디플로이먼트의 롤아웃 작업을 일시 중지합니다.)
     
     * 일시 중지된 롤아웃 작업은 kubectl rollout resume 명령어를 사용하여 다시 시작할 수 있습니다. 이 명령어를 사용하면, 롤아웃 작업이 이전 상태에서 재개됩니다.

kubectl rollout resume

kubectl rollout resume 명령어는 Kubernetes 클러스터에서 디플로이먼트, 데몬셋, 상태풀셋 등의 롤아웃 작업을 다시 시작하는 명령어입니다. 이 명령어를 사용하면, 일시 중지된 롤아웃 작업을 다시 시작할 수 있습니다.

1. 기본 구조
   kubectl rollout resume [리소스 종류]/[리소스 이름]
   
   예시: kubectl rollout resume deployment/my-deployment
   my-deployment 디플로이먼트의 롤아웃 작업을 다시 시작할 수 있습니다.
   
   
2. 옵션
   
   • --selector: 라벨 셀렉터를 사용하여 리소스를 선택합니다.
     
     예시: kubectl rollout resume deployment --selector=app=nginx
      (app=nginx 라벨을 가진 모든 디플로이먼트의 롤아웃 작업을 다시 시작합니다.)

kubectl apply

kubectl apply 명령어는 Kubernetes에서 YAML 또는 JSON 파일로 정의된 리소스를 클러스터에 배포하거나 업데이트할 때 사용되는 명령어입니다. 이 명령어를 사용하면 새로운 리소스를 생성하거나 기존 리소스를 수정할 수 있습니다.

1. 기본 구조
   kubectl apply -f [파일 경로]
   
   예시: kubectl apply -f deployment.yaml
   deployment.yaml 파일에 정의된 디플로이먼트 리소스를 클러스터에 배포합니다.
   
   
2. 옵션
   
   • -f, --filename: 배포할 YAML 또는 JSON 파일의 경로를 지정합니다. 파일 이름이나 디렉토리 이름을 지정할 수 있습니다.
     
     예시: kubectl apply -f deployment.yaml 
     (deployment.yaml 파일에 정의된 리소스를 배포합니다.)
     
     
   • --prune: 새로운 YAML 또는 JSON 파일에 정의되지 않은 기존 리소스를 삭제합니다.
     
     예시: kubectl apply --prune -f deployment.yaml 
     (deployment.yaml 파일에 정의된 리소스를 배포하면서, 새로운 파일에 정의되지 않은 기존 리소스를 삭제합니다.)
     
     
   • --selector: 리소스를 선택하는 레이블 셀렉터를 지정합니다.
     
     예시: kubectl apply --selector app=nginx -f deployment.yaml 
     (deployment.yaml 파일에 정의된 리소스를 배포하면서, app=nginx 레이블을 가진 기존 리소스를 선택합니다.)
     
     
   • -R, --recursive: 디렉토리 내부의 모든 YAML 또는 JSON 파일을 배포합니다.
     
     예시: kubectl apply -R -f ./deployments 
     (deployments 디렉토리 내부의 모든 YAML 또는 JSON 파일을 배포합니다.)
     
     
   • --validate: 배포하기 전 YAML 또는 JSON 파일을 검증합니다.
     
     예시: kubectl apply --validate=false -f deployment.yaml 
     (YAML 또는 JSON 파일을 검증하지 않고 배포합니다.)
     
     
   • --overwrite: 기존 리소스를 덮어쓰기 합니다. --force와 유사하지만, 롤링 업데이트 중에 리소스를 강제로 교체할 때 사용됩니다.
     
     예시: kubectl apply --overwrite -f nginx-deployment.yaml
     (위 명령어는 nginx-deployment.yaml 파일을 사용하여 Deployment 오브젝트를 생성하거나 수정하되, 이미 존재하는 경우 덮어쓰기(overwrite)를 하라는 옵션을 주는 것입니다.)
     
     
   • --force: 기존 리소스를 덮어쓰기 합니다.
     
     예시: kubectl apply --force -f deployment.yaml
      (deployment.yaml 파일에 정의된 리소스를 클러스터에 배포하면서, 기존 리소스를 덮어씁니다.)
     
     
   • --force-conflicts: 리소스 간의 충돌을 해결하기 위해 강제로 덮어쓰기 합니다.
     
     예시: kubectl apply --force-conflicts -f deployment.yaml
      (deployment.yaml 파일에 정의된 리소스를 클러스터에 배포하면서, 리소스 간의 충돌이 발생하면 강제로 덮어씁니다.)
     
     
   • --prune-whitelist: --prune 옵션과 함께 사용되며, 삭제하지 않을 리소스를 지정합니다.
     
     예시: kubectl apply --prune --prune-whitelist=configmap -f deployment.yaml 
     (deployment.yaml 파일에 정의된 리소스를 배포하면서, configmap 리소스는 삭제하지 않도록 지정합니다.)
     
     
   • --dry-run: 배포하지 않고 배포 결과만 미리 확인합니다.
     
     예시: kubectl apply --dry-run -f deployment.yaml
      (deployment.yaml 파일에 정의된 리소스를 배포하지 않고, 배포 결과만 미리 확인합니다.)