이 시대의 진정한 야인.이되겠.어

네트워크 Bonding이란?

iapaalst — Tue, 1 Jul 2025 21:16:39 +0900

1. Bonding이란?

Bonding은 일반적으로 네트워크 인터페이스 카드(NIC)의 이중화를 의미합니다. 이는 하나이상의 물리적인 NIC를 논리적으로 묶어 하나의 단일 인터페이스처럼 작동하게 하는 기술입니다. 이는 네트워크 장애 발생 시 자동으로 다른 NIC로 트래픽을 전환하여, 연결이 끊기는 상황을 방지하기 위함입니다.

2. 왜 이중화를 해야 할까?

이중화는 특정 구성 요소의 장애 발생 시에도 전체 시스템이 중단 없이 정상적으로 작동하도록 여분의 구성 요소를 마련해 두는 전략입니다. 특히 네트워크 통신과 같이 서비스 연속성에 필수적인 부분에서는 이중화가 매우 중요합니다.

하드웨어 관점에서 서버를 생각해보면, CPU, 메모리, 디스크와 같은 핵심 요소들은 물론, 외부 네트워크와의 연결을 담당하는 NIC 또한 매우 중요합니다.

NIC 단일 구성의 문제점:

만약 서버에 NIC가 하나만 연결되어 있다고 가정해 봅시다.

    [서버]
  ┌─────────────┐
  │             │
  │   NIC 1     │──────┐
  └─────────────┘      │
                       ▼
                  [스위치]
                       │
                       ▼
              [외부 네트워크]

케이블 고장: NIC와 스위치 사이의 연결 케이블이 손상되거나 분리될 경우
스위치 고장: 서버가 연결된 스위치에 장애가 발생할 경우
NIC 고장: 서버 자체의 NIC에 하드웨어적인 결함이 발생할 경우

위와 같은 상황에서 서버가 네트워크와 완전히 단절되어 서비스가 중단되는 심각한 문제가 발생합니다. 이는 비즈니스 연속성에 치명적인 영향을 미칠 수 있습니다.

Bonding (NIC 이중화)의 해결책:

    [서버]
  ┌─────────────┐
  │             │
  │  NIC 1      │────┐
  │             │    │
  │  NIC 2      │────┼───┐
  └─────────────┘    │   │
                     ▼   ▼
               [스위치1] [스위치2]
                   │       │
                   ▼       ▼
                 [ 외부 네트워크 ]

NIC 1 / NIC 2: 각각 독립된 물리 네트워크 카드
Bonding 구성: 두 NIC를 하나의 논리적 인터페이스(Bond0 등)로 묶음
스위치도 이중화 가능: LACP 또는 Active-Backup 모드에 따라 구성 달라짐
장애 발생 시 자동으로 다른 NIC로 트래픽 전환

이러한 문제에 대한 해결책으로, 서버에 NIC를 하나 더 추가하고 이들을 Bonding으로 묶습니다. 이렇게 하면 다음과 같은 이점을 ㄹ얻을 수 있습니다.

장애 허용 (Fault Tolerance): 첫 번째 NIC, 연결 케이블, 또는 스위치 중 어느 하나에 장애가 발생하더라도, Bonding으로 묶인 다른 NIC가 자동으로 네트워크 통신을 인계받아 서비스가 끊기지 않고 계속 제공됩니다. (NIC는 여러 개를 구성할 수 있습니다.)
서비스 안정성 및 가용성 향상: 네트워크 연결이 항상 유지되므로, 서버의 안정성과 서비스 가용성이 크게 향상됩니다.

위와 같은 문제가 발생하면 서버의 전체 네트워크 통신이 중단될 수 있습니다. 이를 방지하기 위해 NIC를 2개 이상 구성하여 이중화하는 것이 필요합니다.

결론적으로,

이중화 = Bonding
Bonding = 이중화

즉, Bonding은 네트워크 통신의 핵심 구성 요소인 NIC에 대한 이중화를 구현하여 서버 안정성(가용성)을 확보하기 위한 필수적인 기술입니다.

[OpenStack]OpenStack 구조와 컴포넌트 정리

iapaalst — Sun, 15 Jun 2025 19:24:43 +0900

들어가며

사실 처음에는 “오픈스택(OpenStack)”이 하나의 큰 기업 이름인 줄 알았습니다.4 전공 수업과 부트캠프를 거쳤지만 오픈스택을 직접 다뤄볼 기회는 없었고, 곧 시작될 인턴 업무에서 OpenStack 기반 인스턴스 관리를 맡게 될 예정이라 미리 오픈스택을 공부하고 빠르게 이해하기 위해 정리한 글입니다.

오픈스택? 그게 뭐야?

OpenStack은 원래 NASA와 Rackspace가 공동으로 개발하던 클라우드 프로젝트를
오픈소스로 공개하면서 시작된 인프라 플랫폼입니다. 현재는 Red Hat, HP, Intel, VMware 등
수많은 글로벌 기업들이 기여하고 있는 오픈소스 프로젝트로 성장했죠.

오픈스택은 다음과 같은 특징을 지닙니다:

풀링된 가상 자원(컴퓨팅, 스토리지, 네트워크 등)을 기반으로
Private 또는 Public Cloud 환경을 구축하고 운영할 수 있게 해주는 오픈소스 플랫폼
여러 자원들을 통합해 제어 및 운영할 수 있도록 돕는 일종의 Cloud OS(클라우드 운영체제)

즉, 오픈스택은 서버, 스토리지, 네트워크 자원을 모두 가상화해서
필요한 사용자에게 적절히 할당하고, 대시보드나 API를 통해 조작할 수 있게 해주는 시스템입니다.

예를 들어,

서버 10대, 스토리지 5개, 라우터 몇 개가 있다고 하면,
OpenStack은 이 자원들을 가상화하고 통합해 필요한 사용자에게 자원을 자동으로 할당하고
웹 대시보드(Horizon)나 API를 통해 조작할 수 있도록 도와줍니다.

이처럼 오픈스택은 자원을 가상화하고 풀(Pool) 형태로 모아두고,
이를 기반으로 유연하고 확장성 있는 클라우드 환경을 구축할 수 있게 해줍니다.

오픈스택은 계속 진화 중

오픈스택은 6개월 주기로 새로운 버전이 릴리즈되며,
첫 릴리즈는 2010년의 Austin이었고, 이후 알파벳 순으로 이름이 정해졌습니다.
2022년에는 알파벳 Z까지 도달한 Zed 버전이 나오면서 한 사이클이 끝났고,
지금은 다시 A부터 시작해 현재는 Epoxy(E)까지 도달했습니다.
올해 10월에는 F로 시작하는 새로운 릴리즈가 예정되어 있습니다.

오픈스택 버전명을 보면 릴리즈 시기를 대략 추정할 수 있어서,
사용 중인 환경의 버전을 확인하는 데도 유용하죠. 이런 네이밍 방식도 흥미롭지 않나요?

OpenStack 구조

[출처] : https://www.openstack.org/software/

OpenStack은 Compute, Storage, Network 등의 핵심 기능들이 독립된 컴포넌트(프로젝트)로 구성되어 있으며,
6개월 주기로 새로운 릴리즈가 발표됩니다.
예전에는 Keystone, Cinder, Horizon 등의 새로운 기능이 지속적으로 추가되었지만,
Kilo 버전 이후부터는 안정성과 성능 개선에 주력하고 있습니다.

OpenStack 설치 방법

OpenStack은 두 가지 방식으로 설치할 수 있습니다.

주요 컴포넌트 소개

OpenStack은 기능별로 나뉜 여러 개의 컴포넌트들로 구성됩니다.
이들은 Core 컴포넌트(필수)와 Optional 컴포넌트(선택)로 구분됩니다.

Core 컴포넌트 요약

1. Compute : Nova

[출처] : https://docs.openstack.org/nova/latest/admin/architecture.html

Nova는 Nova-api, Nova-scheduler, Nova-compute, Nova-conductor 와 같은 다양한 컴포넌트들로 존재하고 있습니다.

Nova-scheduler

일반적인 시간 스케줄링이 아닌 VM을 만들 때 어떤 물리서버가 적절한지 결정을하고 공간적인 스케줄링을 해주는 요소입니다. 실제로 VM을 생성할 물리서버가 지정이 된다면 Nova-compute와 같은 요소를 사용해서 VM을 생성하게 됩니다.

Nova-computes

nova-compute는 하이퍼바이저를 제어하여 가상 머신 인스턴스를 생성하고 삭제하는 역할을 합니다. OpenStack은 nova-api를 통해 요청을 받고, 내부적으로 nova-compute가 libvirt (하이퍼바이저 드라이버)같은 Hypervisor API를 호출해 KVM/QEMU 등의 하이퍼바이저에 명령을 내립니다.

Nova-conductor

Nova는 VM 인스턴스의 생성, 상태 변경 등을 Nova-conductror라는 모듈이 DB에 기록하며 관리합니다.

그리고 OpenStack의 각 컴포넌트(Nova, Neutron, Cinder 등)는 내부적으로 Message Queue를 사용해서 서로 간의 작업 요청을 주고받는데, 이 방식은 여러 사용자가 동시에 요청하더라도 큐가 중간에서 처리 속도를 조절해주는 완충장치 역할을 합니다. 여러개의 동시작업을 하는데 최적화가 될 수 있죠.

2. Network : Neutron

가상 네트워킹 인프라와 물리 네트워킹 인프라 모두를 관리하며 OpenStack 서비스 간의 연결을 제공합니다.

1. 논리적인 네트워크 토폴로지를 제공합니다.
2. 서비스 네트워크 별 Tenant 분리 제공합니다.
3. 시큐리티 그룹 내에서 Stateless Firewall 제공합니다.

Neutron은 OpenStack에서 가상 네트워크와 물리 네트워크를 연결·관리해주는 컴포넌트입니다.

이를 통해 *테넌트마다 독립된 네트워크 환경을 구성할 수 있습니다.

Neutron의 구성요소는 서드파티 플러그인(외부 드라이버 및 기술)에 상당히 많이 의존합니다. 리눅스 브릿지나, OVS 같은 기술을 활용해 IP할당, NAT, 방화벽 기능 등을 제공합니다.

OpenStack에서 방화벽을 제공해주고는 있지만 일반적인 보안 방화벽과는 다른 개념이고 Stateless 방화벽(세션 추적 하지 않음)이라고 해서 간단한 접근 제어에 효과적입니다.

*테넌트

하나의 건물(= OpenStack 클라우드)에 여러 세입자(= 테넌트)가 있는데, 각 세입자마다 자기만의 와이파이, 출입문, 보안카드가 따로 있는 것과 같습니다.

→ 그래서 서로 인터넷 회선이나 내부 통신망이 분리되어 있어서 보안이 보장됩니다.

3. Storage : Manila, Swift, Cinder

1. File Storage – Manila

구조: 디렉토리/파일처럼 계층적으로 저장
접근: 일반 파일처럼 mount해서 접근
특징:
- 사용하기 쉬움 (운영체제가 파일처럼 다룸)
- 확장성 한계 있음 → 커질수록 성능 저하
용도:
- 여러 VM에서 공유 폴더처럼 접근해야 할 때
- 백업, 데이터 마이그레이션, NFS 환경

2. Block Storage – Cinder

구조: 데이터를 일정 블록 단위로 나눠서 저장
접근: VM에 디스크처럼 연결됨 (raw 디바이스)
특징:
- 성능 좋고 유연함
- 파일 시스템은 사용자가 직접 생성해야 함 (ext4 등)
- 개발자가 조작 필요 (운영체제 수준에서)
용도:
- VM OS 디스크, 추가 데이터 디스크
- DB 저장소 등 고성능 요구 작업

3. Object Storage – Swift

구조: 디렉토리 없음. Key-Value 형태로 파일 저장
특징:
- 확장성 최고 (수천~수만 노드 가능)
- 다양한 형식 저장 가능 (문서, 이미지, 영상 등)
- 복제/무결성 내장됨
접근: API 또는 URL로 직접 접근
용도:
- 정적 콘텐츠 저장 (이미지, 영상, 백업)
- 클라우드 스토리지 서비스처럼 사용

4. Image : Glance

Glance는 OpenStack에서 VM 생성 시 필요한 OS 이미지 파일을 저장하고 관리하는 서비스입니다.

사용자는 REST API를 통해 이미지를 업로드하거나 조회할 수 있고, Nova는 Glance에서 이미지를 가져와 해당 OS 기반으로 가상머신을 생성합니다. 다양한 이미지 포맷을 지원하며, 클라우드 확장을 위해 다른 컴포넌트에서도 Glance API를 호출해 사용할 수 있습니다.

5. Identity : Keystone

OpenStack에서 사용자 인증(Authentication)과 권한 부여(Authorization)를 담당하는 서비스

즉, 누가(OpenStack User)가 어떤 자원(Project)에, 어떤 권한(Role)으로, 얼마나(Token 유효시간 동안) 접근 가능한지를 판단하는 인증과 접근 제어의 중심입니다.

Keystone의 주요 구성 요소

구성 요소	설명
User	OpenStack을 사용하는 사용자 (사람 or 서비스)
Project	사용자들이 속하는 그룹 (예: 팀, 부서) — 리소스를 나누는 단위
Role	사용자가 수행할 수 있는 작업 권한 (예: admin, member 등)
Token	인증 성공 시 Keystone이 발급해주는 일회용 키→ 이걸 들고 다른 컴포넌트(Nova, Glance 등)에 접근
Endpoint	서비스가 동작 중인 API 주소 (ex: Nova의 API URL 등)
Policy	“이 역할을 가진 사용자는 어떤 작업이 가능한가” 정의한 정책
Catalog	어떤 서비스가 어디 주소에서 동작 중인지 정리한 목록

Keystone은 OpenStack 내 모든 리소스 접근에 대해 "누가, 언제, 어디까지 접근 가능한가"를 토큰 기반으로 통제하는 중앙 인증 서비스입니다.

6. Dashboard : Horizon

웹 기반 GUI 관리 도구이며, 사용자가 프로젝트, 인스턴스, 이미지 등을 직관적으로 조작 가능합니다.

Optional 컴포넌트 요약

컴포넌트	기능
Heat	리소스 자동 배포(오케스트레이션) - YAML 템플릿 사용
Ceilometer	자원 사용량 수집 (모니터링)
Aodh	알림/경고 처리 (Ceilometer 연동)
Trove	DBaaS – MariaDB, PostgreSQL 등의 DB 관리
Sahara	빅데이터 클러스터(Hadoop, Spark 등) 구성
Ironic	베어메탈 서버 관리 (물리 장비에 직접 OS 설치)
Zaqar	메시징 서비스 (REST API, WebSocket 지원)
Designate	DNS 관리 서비스
Murano	OpenStack 상의 앱 배포/관리

위 와 같이 Optional 컴포넌트들이 있습니다.

여러 가지 기능을 확장하기 위해서 각각의 모듈들을 설치해서 OpenStack에서 제공하는 기능을 확장할 수 있다는 것이

유연한 구조를 가진 아키텍처라고 볼 수 있습니다.

OpenStack 논리 아키텍처

OpenStack은 컴포넌트 기반 구조로 구성된 클라우드 플랫폼으로,

각 기능(Nova, Neutron, Cinder, Glance 등)이 모듈처럼 독립적 역할을 수행하고,
사용자는 Horizon이나 API를 통해 명령을 내리면,
Keystone이 인증을 처리하고 Heat가 자동화된 리소스를 구성하며,

필요한 컴포넌트들이 유기적으로 동작하여 하나의 VM을 완성하는 구조입니다.

참고

https://docs.openstack.org/nova/latest/admin/architecture.html

https://www.redhat.com/ko/topics/openstack

https://www.redhat.com/ko/topics/cloud-computing/cloud-vs-virtualization

https://www.youtube.com/watch?v=ozpWKFLI3V0

[CKA]#6 Namespace

iapaalst — Fri, 30 May 2025 15:48:34 +0900

1. Namespace란?

Kubernetes 클러스터 내에서 리소스를 논리적으로 분리하는 방법
하나의 클러스터 안에서 여러 개의 “작은 독립 공간”을 나눠서 쓰는 개념
예: 하나의 아파트(클러스터)에 여러 가정집(네임스페이스)이 있는 느낌

기본적으로 default, kube-system, kube-public이 생성된다.

1.1 네임스페이스로 자원/권한 나누기

또한, 리소스를 논리적으로 분리하는 것뿐 아니라 자원도 나눠 분리할 수 있다.

예를 들어,

팀	네임스페이스	사용 자원
팀 A	`dev-a`	CPU 5개, 메모리 10GiB, 최대 Pod 20개
팀 B	`dev-b`	CPU 10개, 메모리 20GiB, 최대 Pod 50개

→ 서로 자원을 침범하지 않게 구분됨!

(와우, 보통 리소스를 네임스페이스로 구분해서 사용만 했었는데 이런 것도 있구먼)

1.1.1 ResourceQuota

각 네임스페이스마다 CPU/메모리/Pod 개수 제한을 줄 수 있음

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-a-quota
  namespace: dev-a
spec:
  hard:
    requests.cpu: "5"
    limits.memory: 10Gi
    pods: "20"

1.1.2 LimitRange

Pod이나 Container 단위의 기본 CPU/메모리 설정값 제한

1.1.3 RBAC (권한 제어)

특정 네임스페이스에 누가 어떤 권한으로 접근 가능한지 제어

예: 팀 A가 `dev-a`에만 `admin` , `dev-b`에는 `view`

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-a-access
  namespace: dev-a
subjects:
  - kind: User
    name: team-a-user
roleRef:
  kind: Role
  name: admin
  #apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-b-access-for-team-a
  namespace: dev-b
subjects:
  - kind: User
    name: team-a-user     # team-a-user가
    #apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: view              # dev-b에서는 view 권한만 줌
  #apiGroup: rbac.authorization.k8s.io

→ 이렇게 하면 Cross-Namesoace 권한 부여

1.2 리소스 이름은 네임스페이스 내에서만 유일하면 된다.

즉, 같은 이름의 리소스를 서로 다른 네임스페이스에 만들어도 됨
```
# dev 네임스페이스에 있는 서비스
svc: web-service (dev)

# prod 네임스페이스에도 같은 이름의 서비스
svc: web-service (prod)
```
✔️ 둘 다 같은 이름을 써도 문제없음 — 왜? "주소 체계가 다르기 때문"
(마치 아파트 101호에도 철수가 있고, 201호에도 철수가 있는 것처럼)

1.3 Namespace 기반 스코핑은 Namespace 기반 리소스에만 적용된다

쿠버네티스에는 “네임스페이스에 속하는 리소스”와 “네임스페이스에 속하지 않는 리소스”가 있다.

즉, 네임스페이스에 소속될 수 있는 오브젝트만 격리 가능하다

예:

다음 리소스는 네임스페이스가 적용됨:

리소스	설명	예시
Pod	애플리케이션 단위	kubectl get pods -n dev
Service	네트워크 접근 제어	svc: web (in dev) vs svc: web (in prod)
Deployment	Pod 자동 관리	앱 배포를 네임스페이스별로 분리 가능
ConfigMap	설정 데이터
Secret	보안 설정

하지만 다음 리소스는 네임스페이스랑 상관없음 (클러스터 전체 대상):

리소스	설명	이유
Node	클러스터의 물리/가상 머신	물리/가상 머신 수준이라 네임스페이스랑 무관
PersistentVolume	물리적 디스크 같은 저장소 자원	실제 스토리지 자원이기 때문에 클러스터 전체에서 공유됨
StorageClass	볼륨의 클래스 정의	스토리지 정책 설정이기 때문에 전역에서 사용됨
Namespace	네임스페이스 자체도 네임스페이스에 속하지 않음
ClusterRole	클러스터 전체 권한

2. Namespace와 DNS

DNS 형식: `<서비스명>.svc.cluster.local`

보통 DNS형식으로 서비스에 접근한다. 기본으로 되어있는 네임스페이스에 접근하게 됨

하지만, 다른 네임스페이스 리소스 접근 시 FQDN을 사용해야 한다.

예를 들어,

`dev` 네임스페이스, `data` 서비스
`prod` 네임스페이스,`data`서비스

그래서 어떤 네임스페이스의 서비스를 연결해야 할지 정확하게 명시해야 하는 거임

→ `<서비스명>.<네임스페이스명>svc.cluster.local`

3. 그 외

동일한 소프트웨어의 다른 버전 구분에서는?

예를 들어,

`web-app:v1`
`web-app:v2`
→ 이런 버전 구분은 `namespace` 나누지 말고, `label`이나 `deployment` 이름으로 구분해라

4. 명령어 정리.

명령어	설명
`kubectl create namespcae [Namespace명]` or `kubectl create -f ./[파일명]`	Namespace 생성
	Namespace 생성	`kubectl apply -f [파일명] -n [Namespace명]`	리소스를 특정 Namespace에 배포
`kubectl describe namespace [Namespace명]`	특정 네임스페이스 정보보기
`kubectl delete namespaces [Namespace명]`	네임스페이스 삭제하기
`kubectl config set-context --current --namespace=dev`	현재 context의 default namespace 변경(기본 네임스페이스를 설정하는 것)
`kubectl get pods --all-namespaces` or `kubectl get namespace or ns`	전체 Namespace의 리소스 보기 or 네임스페이스 목록보기
	전체 Namespace의 리소스 보기 or 네임스페이스 목록보기	`kubectl get pods --namespace=dev` or `-n dev` `kubectl run nginx --image=nginx —-namespace=dev`	특정 네임스페이스를 명시해서 명령어 실행
`kubectl config view --minify`	grep namespace:`		특정 네임스페이스를 명시해서 명령어 실행
`kubectl api-resources --namespaced=true`	네임스페이스에 속하는 리소스
`kubectl api-resources --namespaced=false`	네임스페이스에 속하지 않는 리소스

[CKA]#5 Service

iapaalst — Thu, 29 May 2025 15:23:37 +0900

[참고]

[Kubernetes 공식문서] Service

[Kubernetes 공식문서] kube-proxy

[Kubernetes 공식문서] kube-proxy Configuration

[Udemy] cka

1. Service란?

Pod 간 또는 외부 ↔ 클러스터 내부 간 통신을 가능하게 해주는데

그렇게 하기 위해 다음을 가능하게 함:

여러 개의 Pod(백엔드)가 있다고 해도 하나의 서비스처럼 묶어주며, 외부/내부에 하나의 고정된 단일 엔드포인트(ClusterIP, NodePort 등)로 접근 가능하게 해준다.
- 즉, 사용자는 내부 구조를 몰라도 접속할 수 있음.(서버 IP가 뭔지 몰라도 하나의 고정된 엔드포인트가 있기 때문에)

DNS 이름으로 접근가능하니까 쿠버네티스가 로드밸런싱을 자동으로 처리할 수 있는 것.

즉, Pods는 죽거나 교체되면 IP가 바뀌며 고정되지 않음. DNS으로 통신이 되니 연결이 끊기는 것을 방지하고 파드가 변경되더라도 항상 최신 파드로 자동 라우팅해줌

그렇기 때문에 서비스 이름. DNS만 알면 됨

또한, 연결하고 싶은 서비스(백엔드 파드 등)의 위치(IP, 포트 등)를 자동으로 찾는 것은 외부/내부에 따라 다른데

내부에선 API 요청으로 알아내고,
외부에서 접근하려면 중간 수단을 제공해야 하는데 NodePort, LoadBalancer, Ingress를 이용하여 포워딩해야 한다.

1.1 Selector

그렇다면, 어떻게 서비스를 통신시켜 줄까?

`selector`를 통해 파드들을 하나의 서비스로 만들어서 연결해 준다.

(예: `app=front-end` 라벨을 가진 파드들만 묶어서 하나의 서비스로)

하지만 특정 상황에서는 `selector` 없이 수동으로 연결가능한데,

이런 경우에는 Service가 어떤 파드를 자동으로 선택하지 않고, 직접 IP와 포트를 수동으로 명시해야 함.

1.2 EndpointSlice(vs. Endpoint)

Service가 연결할 수 있는 파드들의 IP와 포트 정보를 담는 오브젝트(라우팅을 위해 사용)

예를 들어,

`my-service`라는 서비스가 있고,
여기에 300개의 파드가 연결되어 있다면,
쿠버네티스는 약 3개의 EndpointSlice를 만들어 각 100개씩 파드를 담는다.

my-service
 └── EndpointSlice 1 (100개 엔드포인트)
 └── EndpointSlice 2 (100개 엔드포인트)
 └── EndpointSlice 3 (100개 엔드포인트)

즉, EndpointSlice는 서비스의 연결 대상 파드들을 묶어서 분산 저장하는 역할

서비스에 연결된 파드(엔드포인트)가 많으면, 한 슬라이스(EndpointSlice)에 다 담지 않.음.
100개가 넘으면, 쿠버네티스는 새로운 EndpointSlice를 만들어 나눠 저장.

`Endpoints`도 있지만 `EndpointSlice` 사용이 좋은 것 같다. 모쪼록,,,

항목	Endpoints (기존)	EndpointSlice (권장)
구조	모든 정보 한 곳에	여러 개로 나눠 저장
최대 엔드포인트 수	1000개	100개 per 슬라이스 (자동 분산)
초과 시 처리	잘림(truncated)	슬라이스 추가 생성
업데이트	전체 갱신	부분 갱신 가능

그러면 EndpointSlice는 어떻게 생성되냐?

서비스 정의파일에 `selector`를 이용해서 파드들을 하나의 서비스로 묶어줬으면 자동으로 EndpointSlice를 생성하는데 수동으로도 만들 수 있음

예시 :

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: external-db-slice # 네임스페이스 내에서 고유해야함
  labels:
    kubernetes.io/service-name: external-db # ⭐️ 반드시 필요
    endpointslice.kubernetes.io/managed-by: staff # 누가 관리하는 지 #controller는 예약어라 사용못함
addressType: IPv4
ports:
  - protocol: TCP
    port: 5432
endpoints: # 금지된 IP주소 사용하면 안됨
  - addresses:
      - "10.20.30.40"

이렇게 하면 `external-db`라는 `service`가 수동으로 작성한 이 EndpointSlice를 통해 10.20.30.40:5432로 트래픽을 전달

수동으로 생성할 땐 규칙이 꽤 있는데 … 예..

1.3 서비스 정의

Pod 포트에 이름을 붙일 수가 있는데

이런 식으로 하면 Pod가 노출하는 포트 번호를 나중에 바꿔도, 포트 이름을 참조하므로 유지보수가 유연함.

1.3.1 appProtocol

단순 `protocol` 필드(전송계층 L4)만으로는 애플리케이션 수준의 프로토콜 구분이 되지 않음. 그래서 `appProtocol`필드(앱계층 L7)를 추가할 수 있음.

예시:

apiVersion: v1
kind: Service
metadata:
  name: my-http-service
spec:
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
      appProtocol: http

위 정의는 서버 코드가 HTTP(gRPC 등 7 계층 프로토콜)의 요청을 읽고 응답하는 로직이고 TCP 연결을 통해 전달된다는 것임.

근데 이제 이걸 왜 구분해놔야 하냐?

뭐 예를 들어, istio 같은 서비스 메시나 ingress controllere들이 트래픽 내부를 파악해서 정보를 가져올 수 있게 됨.

구체적인 예시로는:

모든 트래픽을 가로채서 80%는 v1으로, 20%는 v2로 알아서 라우팅
특정 사용자(예: `user=guest`)가 `POST /admin` 호출하는 것을 차단
- 이건 JWT 토큰에 담긴 클레임 정보 기반으로 트래픽 차단 → istio

이렇듯 여러 가지를 위해 구분한다고 함 ~

1.3.2 멀티-포트 서비스

하나의 Kubernetes Service가 여러 포트를 동시에 노출할 수 있도록 설정하는 기능

예를 들어 상황이 이렇다면:

Spring Boot 백엔드 앱
- `8080`: 일반 HTTP (API 서버)
- `9090`: `/metrics` (Prometheus용 엔드포인트)
이 백엔드 파드들을 하나의 Service로 묶음
이때 서비스 포트 정의에 두 포트를 역할별로 명시하고 싶음

apiVersion: v1
kind: Service
metadata:
  name: backend-app
spec:
  selector:
    app: backend
  ports:
    - name: http
      port: 8080
      targetPort: 8080
      protocol: TCP
      appProtocol: http         # ✅ 일반 API용 포트
    - name: metrics
      port: 9090
      targetPort: 9090
      protocol: TCP
      appProtocol: prometheus   # ✅ 메트릭 수집용 포트

이 예시 파일을 보면,

Spring Boot 백엔드 서버가 여러 포트를 열 때

8080 포트는 HTTP 요청용 (예: `/login`, `/api/data`)

9090 포트는 Prometheus가 scrape 할 `/metrics` 엔드포인트용

appProtocol로 포트의 의도와 사용처를 명확히 알 수 있음

실제 내가 작성한 코드로 확인해 보겠다.

argocd의 grpc(HTTP/2) 통신을 위해 작성한 grpc 서비스 매니페스트다. 아무래도 엉성한 부분이 많다.

#argocd-grpc.yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/backend-protocol-version: GRPC
  labels:
    app: argogrp
  name: argogrpc
  namespace: argocd
spec:
  ports:
    - name: "80"
      port: 80 
      protocol: TCP
      targetPort: 8080
      nodePort: 30081  # 클러스터 외부(ALB → EC2 노드)
  selector:
    app.kubernetes.io/name: argocd-server
  sessionAffinity: None
  type: NodePort

ports 필드를 보면 80 포트 하나만 정의되어 있다. 여기에 gRPC를 넣어 명확하게 표현할 수 있다.

수정된 코드:

pec:
  ports:
    - name: grpc
      port: 80 
      protocol: TCP
      targetPort: 8080
      nodePort: 30081
      appProtocol: grpc    # ⭐️

이렇게 수정한다면, 이제 이 포트를 정말 명확하게 grpc 프로토콜로 인식하게 되는 것이다.

1.4 서비스 디스커버리

쿠버네티스는 DNS기반의 서비스를 찾고 통신함.

그럴 때 DNS로 통신한다면?

`http://[서비스이름]` (같은 네임스페이스 내에서 접근)
`http://[서비스이름].[네임스페이스]` (다른 네임스페이스에서 접근)

즉, IP가 아니라 서비스 이름으로 통신 ~

2. 종류

타입	설명
ClusterIP	(기본값) 클러스터 내부 통신용 가상 IP 생성
NodePort	노드의 고정 포트를 열어 외부에서 접근 가능
LoadBalancer	클라우드 환경에서 외부 LoadBalancer를 생성해 접근 허용

2.1 ClusterIP

ClusterIP는 클러스터 내에서만 접근 가능한 기본 서비스 타입

Pod IP 대신 고정한 IP 또는 DNS로 Pod 그룹을 접근 가능하게 해 줌.

예를 들어,

같은 클러스터 내 다른 Pod는 다음과 같이 접근 가능:

`http://backend` (서비스 이름이 DNS처럼 동작)
또는 `http://<ClusterIP>` (서비스가 부여한 IP)

또한,

다른 Pod에서 이 서비스에 접속하면, 로드밸런싱을 통해 one of Pods로 트래픽 전달함

그러나, 외부에선 접근할 수 없음 말 그대로, 내부. 에서. 만 가, 능

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP   # 생략하면 기본값으로 ClusterIP
  #clusterIP: 10.0.0.150  # 직접 지정(service IP 범위(CIDR) 내)
  selector:
    app: backend    # backend Pod의 레이블과 일치해야 함
  ports:
    - port: 80             # 서비스가 노출할 포트
      targetPort: 80       # 실제 Pod에서 노출된 포트

2.1.1 Headless 서비스

위 코드에서 봤던 ClusterIP를 직접 지정하지 않고 None으로 지정할 경우 Headless Service가 됨

Headless Service는 ClusterIP 없이 파드의 실제 IP 목록만 DNS로 반환하는 서비스임.

spec:
  clusterIP: None

그럼 이걸 언제 쓰냐?

로드밸런싱 필요 없을 때
파드별로 직접 접근하고 싶을 때

… 그렇다네요

2.2 NodePort

NodePort는 ClusterIP와는 다르게 클러스터 외부에서 특정 노드 IP와 포트를 통해 서비스에 접근할 수 있게 해 주는데, 포트로 들어오는 요청을 내부의 해당 Pod로 프락시 해줌.

요청 흐름:
<외부 사용자> ──▶ <NodeIP>:<NodePort> ──▶ <Service> ──▶ <Pod>

단일 Pod 연결 구조

NodePort 구조는 위와 같다.

Pod 내부 웹 서버 포트인 targetPort,
Service가 가진 가상 IP포트인 port,
Node에서 외부로 노출되는 포트인 NodePort.
- NodePort의 포트 번호는 기본적으로 30000~32767 사이만 가능(다른 NodePort와 충돌하면 안 됨)
자동으로 ClusterIP도 같이 생성

접속:

`http://[NodeIP:NodePort]`

2.2.1 --nodeport-addresses

그런데, 내부망/외부망 관계없이 모든 노드의 IP에서 열리게 되면 외부에 노출하면 안 되는 서비스는 어쩌냐.

이걸 해결하기 위해선 `--nodeport-addresses` 옵션을 추가함.

kube-proxy에 아래 옵션 추가:

containers:
  - name: kube-proxy
    command:
      - /usr/local/bin/kube-proxy
      - --nodeport-addresses=192.168.0.0/24
				# NodePort로 열리는 포트는 192.168.0.X IP로 들어오는 요청만 받음

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
...
nodePortAddresses:
  - 192.168.0.0/24

클라우드 환경(AWS 등) 보안그룹 너낌이라 온프레미스에서 설정하면 되는 것 같음.

2.3 LoadBalancer

클라우드 환경(AWS, GCP, Azure 등)에서만 외부 로드밸런서를 생성하여 서비스에 외부 IP를 부여하고 연결해 줌. 그렇게 되면, 노드의 포트로 트래픽을 자동 전달함.

즉,

type: LoadBalancer

명시 후
클라우드에서 외부 로드밸런서 + 외부 IP 생성됨
서비스 상태 `.status.loadBalancer.ingress` 에 IP가 표시됨 이 IP로 외부에서 접근 가능!
(AWS에서 로드밸런서 IP 확인하는 방법: EC2 → 네트워크 인터페이스 → 해당 LB의 IPv4 주소 확인)

2.3.1 MixedProtocolLBService

(Kubernetes v1.24부터 기본 활성화된 베타 기능)

하나의 서비스 리소스 안에서 여러 프로토콜을 동시에 정의를 할 수 있다고 하는데 AWS기준 ALB가 아니라 NLB만 가능한 것 같다.

NLB는 그러면 service 타입을 loadbalancer 로만 하면 된다..?

ALB는 ALB Controller를 권장해서 ingress와 같이 사용했는데 ingress 리소스 자체가 L7 기반…(?) 이라는데 이거이거,,, NLB,, 를.. 이건 좀 더 ingress까지 공부를 해야 이해할 수 있을 것 같다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080
    - name: dns
      protocol: UDP
      port: 53
      targetPort: 53

클라우드 환경에서는 외부에 노출되는 공용 IP 주소가 자동 할당되고, DNS 연결만 하면 된다.

2.3.2 spec.loadBalancerClass

로드밸런서를 다른 특정한 로드밸런서로 선택하고 싶을 때 사용함

한 번 지정하면 변경 불가

예를 들어,

`metallb.io/l2` → MetalLB
`mycompany.com/custom-lb` → 사내 자체 구현 로드밸런서

apiVersion: v1
kind: Service
metadata:
  name: my-metallb-service
  namespace: default
spec:
  type: LoadBalancer
  loadBalancerClass: metallb.io/l2
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

한 번 지정하면 변경 불가

2.3.3 AWS ELB 접근 로그 설정

metadata:
  name: my-service
  annotations:
    # 1. 접근 로그 기능 활성화 여부
    service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"

    # 2. 로그를 S3에 몇 분 간격으로 저장할지 (5 또는 60만 가능)
    service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"

    # 3. 로그를 저장할 S3 버킷 이름
    service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"

    # 4. S3 버킷 내 저장 위치 (예: logs/prod)
    service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "logs/prod"

이렇게 설정하면 S3에 로그가 쌓인다고 함 ~ (더 좋은 방법이 있지 않을까?)

2.3.4 AWS ELB Connection Draining

로드 밸런서에서 인스턴스(파드 등)를 제거할 때, 기존에 연결된 사용자들의 세션이 끊기지 않도록 일정 시간 동안 요청을 마무리하고 난 후 제거하는 기능

예시:

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60" # 초 단위 (최대 3600)

`"true"`: 연결 드레이닝 기능 활성화
`"60"`: 최대 60초까지 기존 연결을 유지함

예를 들어,

사용자가 ELB를 통해 서비스 접속 중 (예: 파일 업로드 중)
배포나 노드 종료로 인해 해당 파드를 제거하려고 함
드레이닝이 설정되어 있으면:
- 해당 파드로의 새 연결은 차단
- 기존 연결은 60초간 유지되어 요청 완료 가능
60초 내에 종료되면 gracefully 제거됨

3. 그 외

서비스는 API 오프젝트이기 때문에

`kubectl get service my-service -o yaml` 로 YAML 확인 가능
`kubectl proxy` 또는 직접 API 호출로 `/api/v1/namespaces/default/services` 로 접근 가능
프로그램적으로 쿠버네티스 클러스터 내부에서 서비스 목록을 조회하거나 생성 가능

[CKA]#4 Deployment

iapaalst — Thu, 29 May 2025 14:37:03 +0900

참고

[Kubernetes 공식문서] Deployment

1. Deployment란?

예를 들어, 사용자가 replicas: 5, image: nginx:1.21이라고 선언하면,

Kubernetes는 현재 상태와 비교해서,
- 파드가 3개밖에 없으면 2개를 추가하고,
- 이미지가 nginx:1.20이면 1.21로 순차적으로 업데이트하며
- "의도한 상태"로 만들어줍니다.

즉, 원하는 상태를 YAML로 선언만 하면, 알아서 조정해 주는 것임

Deployment는 단순한 파드 관리 이상의 기능(롤링 업데이트, 롤백, 확장, 일시정지 등)을 제공하는 상위 관리 오브젝트

대신,

Deployment가 생성한 ReplicaSet이나 Pod를 직접 수정하면 안 됨.

수정하고 싶다면 Deployment를 수정해야 함

1.1 유스케이스

Deployment는 배포/업데이트/복구/확장 등 운영에 필요한 기능을 자동화해주는데, 어떻게 사용이 되냐?

새로운 ReplicaSet을 생성해서 애플리케이션을 롤아웃(배포)
- Deployment를 만들면, 그에 맞는 ReplicaSet이 생성되고 → ReplicaSet이 파드를 자동으로 생성함
- 배포가 정상적으로 완료됐는지 상태(롤아웃 상태)를 확인할 수 있음

애플리케이션을 새 버전으로 업데이트 (rolling update)
- Deployment의 .spec.template을 바꾸면 (예: image 버전 변경),→ 새로운 ReplicaSet이 생성되고,
- → 기존 파드를 조금씩 줄이고 새로운 파드를 조금씩 늘리는 롤링 업데이트가 자동으로 일어남

문제가 생기면 이전 버전으로 롤백
- 문제가 발생한 경우, 이전에 잘 동작하던 상태로 되돌릴 수 있음
- 이때도 버전 번호가 올라감 (수정 버전이 자동 관리됨)

애플리케이션 수평 확장 (scale up/down)
- replicas 수치를 변경하면 → 자동으로 파드 수 증가 또는 감소

배포 일시 중지 후, 여러 수정 후 재개
- rollout을 pause하고 여러 설정을 수정
- 다 수정하고 나서 resume하면 그때 적용됨

배포가 막혀 있는 상태를 알 수 있음
- 예: readiness probe 실패로 새 파드가 준비되지 않으면 롤아웃이 멈춰 있음
- Deployment 상태로 이런 문제를 파악할 수 있음

이전 버전의 ReplicaSet 정리
- 오래된 ReplicaSet은 자동으로 정리됨 (디플로이먼트가 관리함)

1.2 YAML

#controllers/nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3              # 없으면 기본적으로 1개의 파드만 생성
  selector:
    matchLabels:
      app: nginx            # ★ 이게 .spec.selector
  template:                 # ★ 이게 .spec.template (실제 pod 정의)
    metadata:
      labels:
        app: nginx          # selector와 꼭 일치해야 함!
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

파일 구성은 ReplicaSet과 다를게 없다.

.spec.selector는 필수

.spec.selector는 한 번 생성하면 수정할 수 없다 (immutable)

.spec.selector와 .spec.template.metadata.labels는 꼭 일치

HPA를 사용할 거면 .spec.replicas는 절대 설정하지 말 것!

대신, 출력을 잘보자.

클러스터에서 디플로이먼트, 레플리카셋, 파드를 점검할 때, 다음 필드가 표시된다.

1.2.1 Deployment

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           18s

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

READY: 준비된 파드 수 / 원하는 파드 수

UP-TO-DATE: 최신 템플릿 기준으로 생성된 파드 수

AVAILABLE: 사용자 요청 처리 가능한 파드 수

AGE: 생성된 지 얼마나 되었는지

1.2.2 ReplicaSet

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       18s

이름은 보통 디플로이먼트이름-HASH

.pod-template-hash 라벨과 일치

DESIRED, CURRENT, READY 필드로 상태 확인

1.2.3 Pod

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453

이름도 보통 디플로이먼트이름-HASH-랜덤문자

app=nginx, pod-template-hash=... 라벨이 자동 부여됨

1.2.4 파드 템플릿 라벨

여기서, pod-template-hash 라벨이 자꾸 튀어나오는데 무엇이냐면?

ReplicaSet의 문제점이 selector의 라벨이 겹치지 않아야 함.

만약 겹친 경우 여러 ReplicaSet이 관리가 ..해당 파드를 소유하게 될 수 있음.

이와 비슷한 맥락으로 Deployment도 단순한 파드 관리 이상의 기능을 하기 때문에 여러 ReplicaSet을 가짐.

예를 들어 여러 버전의 ReplicaSet을 동시에 가지게 되는데 이때 서로 겹치는 파드를 관리하지 않도록 하기 위해 pod-template-hash 값이 다르게 설정되어 각 ReplicaSet이 자신만의 파드만 관리하도록 하는 것.

즉, Deployment가 ReplicaSet을 유일하게 구분하고 충돌 없이 관리하기 위해 파드 템플릿 내용을 해시한 값입니다. 이 값은 Deployment 컨트롤러가 자동으로 생성하며, 사용자가 직접 수정하면 시스템 동작이 꼬일 수 있기 때문에 변경하면 안 됩니다.

apps/v1에서는 selector가 생성 후에 변경이 아예 불가능;

2. 업데이트

디플로이먼트는 파드를 업데이트할 때 롤링 업데이트 방식으로 점진적으로 업데이트를 수행합니다. 롤링 업데이트는 한 번에 모든 파드를 업데이트하지 않고, 몇 개씩 순차적으로 업데이트하여 서비스의 다운타임을 최소화합니다.

예를 들어, nginx:1.14.2 이미지를 nginx:1.16.1로 업데이트할 때:

디플로이먼트는 새 파드를 생성하고 (새로운 레플리카셋으로),

기존 파드를 삭제하는 방식으로 업데이트합니다.

이 과정을 통해 서비스가 중단되지 않고 점진적으로 새로운 버전으로 변경됩니다.

2.1 파드 수의 제한

디플로이먼트는 항상 최소 75% 이상의 파드가 동작하도록 보장함.

기본적으로 디플로이먼트는 롤링 업데이트 중에 최대 25%의 파드만 동시에 다운되도록 설정되어 있음.

즉, 디플로이먼트가 업데이트 중일 때, 적어도 75%의 파드는 계속 실행됩니다. 이 설정은 서비스의 가용성을 유지하기 위해 매우 중요함.

maxUnavailable: 롤링 업데이트 중 동시에 다운될 수 있는 파드의 최대 개수입니다. 기본적으로 최대 25%까지 설정됩니다.

maxSurge: 롤링 업데이트 중 동시에 실행되는 파드의 최대 수입니다. 기본적으로 25%까지 설정되어 있으며, 디플로이먼트가 새 파드를 추가할 때 이를 제어합니다.

예시:

디플로이먼트의 레플리카 수가 4일 경우, 최소 3개의 파드는 항상 실행되어야 합니다. maxSurge와 maxUnavailable 설정에 따라, 최대 5개의 파드가 동시에 실행될 수 있으며, 최소 3개는 항상 실행됩니다.

availableReplicas: 종료 중인(terminating) 파드는 포함되지 않으며, 현재 실행 중인 사용 가능한 파드만 계산됩니다. 롤링 업데이트 중에는 새로 생성된 파드가 완료되기 전까지 이전 파드가 삭제되지 않기 때문에, availableReplicas는 예기치 않게 더 많은 수치를 보일 수 있습니다.

2.3 롤오버(일명 인-플라이트 다중 업데이트)

= 기존 디플로이먼트 업데이트(롤링 중) 도중에 또 다른 업데이트가 발생했을 때의 처리 방식

디플로이먼트는 이전 요청이 완전히 끝나지 않았더라도 최신 요청 기준으로 동작함. 기존 버전(nginx:1.14.2)의 나머지 파드는 더 이상 만들지 않고 중단함 대신 새 버전(nginx:1.16.1)으로 파드를 만들기 시작함 이전 레플리카셋은 스케일 다운되어 사라지고, 새로운 레플리카셋이 스케일 업됨

즉, 롤링 업데이트 중에 또 업데이트가 들어오면, 새로운 버전으로 바로 전환함

3. 롤백

만약 새로운 버전으로 업데이트한 후 오류가 발생하면, 자동으로 중단하거나, 수동으로 롤백함.

. spec.template이 바뀌면 수정 버전(Revision)이 생기는데, 이걸 기준으로 롤백. 대신 수정 버전은 `.spec.template`이 바뀌었을 때만 생성됨.

예를 들어서,

오타로 잘못된 이미지 입력
```
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
- 실제로 존재하지 않는 이미지라서 ImagePullBackOff 상태로 고착됨

롤아웃 상태 확인
```
kubectl rollout status deployment/nginx-deployment
```
- 출력: 1 out of 3 new replicas have been updated... (계속 대기)

kubectl get rs
- 새 레플리카셋이 1개 생성되었지만, 파드가 문제로 제대로 실행되지 않음
- 이전 정상 상태의 레플리카셋도 아직 남아있음

문제 원인
- 오타로 인해 이미지를 불러올 수 없고
- 쿠버네티스는 기본적으로 25%만 비정상 파드를 허용하므로 롤아웃이 멈춤

해결 방법: 롤백
```
kubectl rollout undo deployment/nginx-deployment
```
- 가장 최근의 정상 상태로 롤백함

3.1 롤아웃 기록

즉, 디플로이먼트가. spec.template이 바뀔 때마다 수정 버전을 하나씩 남기는데 각 버전의 변경 내역을 볼 수 있고, 원하면 특정 버전으로 롤백할 수도 있음.

3.1.1 롤아웃 기록 확인

kubectl rollout history deployment/nginx-deployment

예시 출력:

REVISION    CHANGE-CAUSE
1           kubectl apply --filename=...
2           kubectl set image ... nginx=nginx:1.16.1
3           kubectl set image ... nginx=nginx:1.161

REVISION: 디플로이먼트 버전 번호

CHANGE-CAUSE: 무엇 때문에 수정되었는지 나타냄
- kubectl set image나 kubectl apply 등의 명령이 표시됨

3.1.2 특정 수정 버전 상세 보기

kubectl rollout history deployment/nginx-deployment --revision=2

4. 스케일링

디플로이먼트도 rs처럼 수동 또는 자동으로 스케일링한다.

4.1 비례적 스케일링

즉, 롤링 업데이트 도중에 기존 파드와 새 파드에 파드 개수를 비율로 잘 분산하는 방식

예를 들어,

롤링 업데이트 중이어서 기존 파드가 10개고 5개를 늘린다고 하면, 새 버전 이미지로 업데이트가 시작됨. 이때 오토스케일러가 개입해서 파드 수 15개로 늘리라고 요청함

기존 RS: 8개 중 3개 추가 → 총 11개

새 RS: 5개 중 2개 추가 → 총 7개

현재 활성 레플리카셋(New + Old)에 비율에 따라 새 파드를 골고루 배분

→ 즉, 업데이트가 아직 완료되지 않았을 때는 분산해서 안전하게 늘림

새 파드가 모두 정상 상태가 되면, 기존 구 버전 파드를 점점 줄이고 최종적으로 모든 파드가 신버전으로 전환됨

5. 일시정지 및 재개(기본값 = false)

.spec.template 안의 내용이 변경되면 롤아웃되는데 파일에서 한 번에 여러 항목을 변경하면 한 번의 롤아웃이 트리거가 됨

근데? 왜 pause/resume을 쓰냐?

CLI 명령어로 여러 번 나눠서 수정하는 경우, 수정할 때마다 롤아웃이 발생함. 그렇기 때문에 일시정지하고 재개하는 것임. 배포 제어하려고

대신, 일시 중지된 디플로이먼트를 재개할 때까지 롤백할 수 없음 ~

spec:
  paused: true

위와 같이 설정하면, 이후 .spec.template의 이미지나 리소스 등을 바꿔도 롤아웃되지 않음

나중에 다음 명령으로 롤아웃 재개:

kubectl rollout resume deployment/nginx-deployment

6. 상태

6.1 진행 중 = 디플로이먼트가 무언가를 바꾸고 있는 중일 때

디플로이먼트 오브젝트의 .status.conditions 항목에 다음과 같은 정보가 들어갑니다:

type: Progressing
status: "True"
reason: NewReplicaSetCreated | FoundNewReplicaSet | ReplicaSetUpdated

kubectl rollout status deployment/nginx
# 출력 예시:
# Waiting for deployment "nginx" rollout to finish: 1 out of 3 new replicas have been updated...

6.2 완료 = 모든 파드가 최신 상태 + 사용 가능 + 이전 버전 없음

.status.conditions :

type: Progressing
status: "True"
reason: NewReplicaSetAvailable

출력 예시:

Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

echo $? # 종료 코드 0

6.3 실패

가능한 실패 원인

이미지가 존재하지 않거나 Pull 오류 발생

readiness probe 실패

리소스 부족 (예: CPU, 메모리)

권한 부족 (RBAC 등)

할당량(quota) 초과

잘못된 애플리케이션 설정 등

6.3.1 progressDeadlineSeconds

만약 위 실패 원인으로 롤아웃이 실패가 되기까지 기본값이 600(10분)을 기다려야 함. 그렇기 때문에 문제가 발생했을 때 적절한 조치를 취하기 위해 설정하는 것.

예를 들어서 잘못된 이미지(nginx:typo)로 인해 파드가 ImagePullBackOff 상태인데, 롤아웃 실패로 간주되기까지 10분이나 기다려야 함.

→ progressDeadlineSeconds: 60으로 줄이면, 1분 안에 롤아웃 실패 감지 가능.

예: 60(1분) 동안 롤아웃이 완료되지 않으면 실패 처리

kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":60}}'

즉, 설정하면 더 빠르게 실패로 간주해서 운영 자동화 및 디버깅에 유리하게 된다 ~

디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 상태와 이유를 업데이트함.

.status.conditions :

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded #설정했을 경우
  ReplicaFailure  True    FailedCreate

출력 예시:

kubectl rollout status deployment/nginx-deployment
# 출력:
# error: deployment "nginx-deployment" exceeded its progress deadline

echo $?  # 종료 코드 1

progressDeadlineSeconds는 선택 필드

만약 설정한다면, minReadySeconds보다 커야 함(파드가 준비됐다고 간주되기까지 기다리는 시간보다 길어야 한다는 뜻)
```
spec:
  progressDeadlineSeconds: 300  # 5분 안에 롤아웃 완료 안 되면 실패로 간주
  minReadySeconds: 60
```

7. 그 외

7.1 `.spec.revisionHistoryLimit`(기본값=10)

디플로이먼트가 새로운 롤아웃(업데이트)을 할 때마다 이전 버전의 ReplicaSet을 하나씩 남기는데 몇 개까지 남길 것인지 결정하는 것. 대신 롤아웃을 성공했을 때만 정리함 → 즉, revisionHistoryLimit보다 오래된 이전 버전들이 자동으로 정리됨

근데?

진행 중이거나 실패 중이면 제한보다 더 많은 이전 버전이 남아 있을 수 있음

근데?

0이면 롤백 못함. 이전 버전 없어서

revisionHistoryLimit: 3 → 가장 최근의 3개 버전까지만 롤백 가능

왜 중요한가?

너무 많은 ReplicaSet을 남기면:

etcd 저장소 낭비

kubectl get rs 목록 복잡해짐

너무 적게 설정하면:

이전 상태가 없어서 롤백이 어려움

7.2 카나리아 배포

"전체를 한 번에 바꾸지 말고, 조금씩 나눠서 새 버전을 테스트하자"라는 개념

예를 들어:

기존 버전 (v1)을 가진 Deployment가 전체 100개 파드를 운영하고 있음.

새 버전(v2)을 일부만 롤아웃하고 싶을 때:
- v2 전용 Deployment를 따로 만들어 10개만 배포
- v1은 90개 그대로 유지

v2의 동작이 안정적임을 확인한 뒤 → 점진적으로 수를 늘려나감
- v2 30개 / v1 70개 …
- 최종적으로 v2 100개 → v1 완전 제거

7.3 `.spec.strategy`

기존 파드를 새로운 파드로 어떻게 교체할지를 결정하는 전략 필드

7.3.1 RollingUpdate(기본값)

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 3 # or 30%, 전체 파드 중 최대 3개까지 동시 중단될 수 있음
    maxSurge: 3 # or 30%, 전체 파드 10개면 최대 3개를 추가 생성할 수 있음

maxUnavailable: 새 파드가 준비되기 전에 내려도 되는 기존 파드 수 (기본 25%)

maxSurge: 의도한 파드 수보다 더 많이 생성해도 되는 새 파드 수 (기본 25%)

7.3.2 Recreate

strategy:
  type: Recreate

먼저 기존 파드를 모두 종료하고

그 다음에 새 파드를 생성함

즉, 자원 충돌없이 새 버전만 동작(DB나 단일 인스턴스만 떠야하는 서비스에 적합)

8. 명령어 정리

명령어	설명
`kubectl create -f [파일명]` or `kubectl apply -f [파일]`	리소스 생성
`kubectl get deployment` or `kubectl descibe deployment`	디플로이먼트 상태 확인
`kubectl rollout status deployment/[이름]`	디플로이먼트 진행 상태 확인
`kubectl rollout status deployment/[deployment name]`	롤아웃 상태 확인
`kubectl get pods —show-labels`	생성된 파드 라벨 확인
`kubectl get replicaset` or `kubectl get rs`	ReplicaSet 목록 조회
`kubectl rollout undo deployment/[deployment name]`	가장 최근의 이전 버전으로 롤백
`kubectl rollout undo deployment/[deployment name] --to-revision=2`	특정 수정 버전(예: 2번)으로 롤백
`kubectl delete rs [이름]` or `kubectl delete rs [이름] [이름]`	삭제 및 여러개 삭제
`kubectl replace -f [파일명]`	리소스 전체 교체 → 이거 뭔말임
`kubectl edit rs [이름]` 후 `kubectl delete pod [이름]`	수정 및 반영(수정해도 자동으로 갱신 안됨)
`kubectl scale deployment/[이름] --replicas=N`	확장/축소
`kubectl autoscale deploymenet/[이름] --min=10 --max=15 --cpu-percent=80`	HPA