Kubernetes : Pod, Service, 클러스터 구조

도커를 어느 정도 공부하고서 드디어 쿠버네티스 공부를 시작했다! 저번에 기초 개념 없이 쿠버네티스에 뛰어들었다가 멸망한 적이 있어서 이번에야말로 성공해야겠다고 생각하고서 기초부터 공부를 시작하기로 했다!
그래서 이번 포스팅은 쿠버네티스를 공부하면서 중간중간 기록을 해보려 한다.
Q & A 형식으로 포스팅할 것이다! 말 그대로 내가 공부하면서 직접 마주한 궁금증들을 기록하려 한다!!

Q1. Pod는 무엇인가?

A. Pod는 도커 위의 컨테이너들을 묶어놓은 단위(?)이다. 쿠버네티스는 pod 단위로 관리한다.

Ex)

apiVersion: v1               # 쿠버네티스 API 버전
kind: Pod                    # 이 객체가 Pod임을 나타냄
metadata:
  name: my-webapp-pod        # Pod의 이름을 지정
  labels:
    app: my-webapp           # Pod에 대한 레이블을 정의, Service에서 이 레이블을 사용해 Pod을 선택함
spec:
  containers:
  - name: my-webapp-container  # 컨테이너의 이름을 지정
    image: nginx:latest        # 컨테이너에서 사용할 도커 이미지를 지정 (여기서는 Nginx 웹 서버)
    ports:
    - containerPort: 80        # 컨테이너가 외부와 통신할 때 사용할 포트를 지정 (Nginx 기본 포트 80)

Q2. 각각 다른 서버(A,B,C)끼리는 어떻게 통신하길래 한 서버의 pod가 되는 거지?

A. 각각 다른 서버들(A, B, C)은 Kubelet과 네트워크 플러그인을 사용해 하나의 클러스터로 묶인다. 이 클러스터 내에서는 모든 서버가 같은 네트워크에 있는 것처럼 서로 통신할 수 있으며, Pod들이 분산된 서버 간에서도 원활히 협력할 수 있다.

결론적으로, 쿠버네티스는 네트워크 플러그인과 Kubelet을 사용해 물리적으로 다른 서버들을 하나의 클러스터로 묶고, 이 클러스터 내에서 각 서버의 Pod들이 마치 같은 서버에 있는 것처럼 서로 통신하고 협력할 수 있게 만든다!

Q3. 쿠버네티스를 사용하기 위해 컨테이너 이미지를 도커 허브에 올리는 이유?

A. 특정 애플리케이션을 이미지로 만들어서 도커 허브에 올리면 쿠버네티스가 설치된 서버에서 그 이미지를 다운로드 받아서 그 애플리케이션의 컨테이너를 받고 컨테이너를 필요에 따라 Pod로 묶어서 관리하는 것이다.

Q4. Service는 무엇인가?

A. Service는 쿠버네티스에서 Pod들을 외부에 노출시키거나, Pod들 간의 통신을 안정적으로 관리하기 위해 사용되는 객체이다.

결론적으로, Pod는 컨테이너를 실행하고 관리하는 단위이고, Service는 이 Pod들을 네트워크 상에서 어떻게 접근할지 관리하는 역할을 한다. Pod를 구동시켜 컨테이너를 실행한 후, 필요에 따라 Service를 설정해 외부나 다른 Pod와의 통신을 관리할 수 있다.

Ex)

apiVersion: v1               # 쿠버네티스 API 버전
kind: Service                # 이 객체가 Service임을 나타냄
metadata:
  name: my-webapp-service    # Service의 이름을 지정
spec:
  selector:
    app: my-webapp           # 이 레이블을 가진 Pod을 선택 (Pod의 레이블과 매칭)
  ports:
    - protocol: TCP           # 사용할 네트워크 프로토콜을 지정 (기본값은 TCP)
      port: 80                # 서비스가 외부에 노출할 포트 (사용자들이 접속할 포트)
      targetPort: 80          # Pod 내에서 실제로 컨테이너가 사용 중인 포트 (Pod의 80번 포트로 트래픽 전달)
  type: LoadBalancer          # 클러스터 외부에 노출하는 서비스 타입 (외부 IP를 통해 접근 가능)

쿠버네티스 클러스터의 구조 (Object / Controller)

이 사진은 내가 보기엔 중요한 것 같아서 설명해보겠다!!
쿠버네티스 클러스터는 크게 Object와 Controller로 나눌 수 있다.
Object는 쿠버네티스에서 관리되는 리소스들을 말한다.
Controller는 리소스들을 자동으로 관리하고 유지하는 다양한 컨트롤러이다.

Object

• Namespace: 개발, 운영 환경을 분리하고 여러 팀에서 같은 클러스터를 사용할 때 구분 짓기 위한 논리적 단위라고 생각하면 될 것 같다.
• Service: Pod에 대한 네트워크 접근을 관리하고, 외부에서 Pod로의 접근을 가능하게 한다. 예를 들어, 로드 밸런싱을 통해 트래픽을 분배하거나, 외부 IP를 통해 Pod에 접근할 수 있게 한다.
• Pod: 컨테이너가 실행되는 최소 단위이다. 보통 하나의 Pod에는 하나의 컨테이너가 있지만, 여러 컨테이너가 함께 실행될 수도 있다.
• Container: Pod 내부에서 실행되는 애플리케이션이다. 모든 애플리케이션 코드, 라이브러리, 설정 파일 등을 포함하고 있다.
• Volume: Pod 내의 컨테이너들이 데이터를 저장하고 공유할 수 있는 스토리지 공간이다. Pod가 삭제되어도 데이터는 유지된다.
• ResourceQuota: Namespace 내에서 사용할 수 있는 자원의 총량을 제한한다.
• LimitRange: 특정 Pod나 컨테이너가 사용할 수 있는 자원의 상한선을 설정한다.
• ConfigMap: 애플리케이션이 사용하는 설정 데이터를 외부에서 관리할 수 있게 해주는 도구이다. 쉽게 설명해 환경변수 정도로 생각하면 될 것 같다.
• Secret: 비밀번호, API 키 등 민감한 데이터를 안전하게 저장한다.
• Controller: Pod를 생성하고 관리하는 쿠버네티스의 주요 컴포넌트이다. 클러스터의 상태를 지속적으로 모니터링하고, 정의된 상태로 유지되도록 자동으로 조정한다.

Controller

• Replication Controller, ReplicaSet: 동일한 Pod의 여러 복제본을 유지하고 관리한다. Pod가 실패하면 자동으로 대체 Pod를 생성한다.
• Deployment: 애플리케이션의 버전을 관리하고, 무중단 롤링 업데이트나 롤백을 통해 애플리케이션을 배포할 수 있다.
• DaemonSet: 클러스터 내의 모든 노드에서 단 하나의 Pod가 실행되도록 보장한다. 보통 시스템 수준의 애플리케이션을 배포하는 데 사용된다.
• CronJob: 주기적으로 실행되는 작업을 정의한다. 예를 들어, 백업이나 데이터 처리 작업 등을 예약할 수 있다.

클러스터 구조

• Master: 클러스터의 중앙 관리 노드로, 클러스터 전체의 상태를 관리하고, 각 노드에 작업을 할당하는 역할을 한다.
• Node1, Node2, Node3: 워커 노드로, 실제로 애플리케이션의 컨테이너(Pod)가 실행되는 서버들이다. 마스터 노드의 명령에 따라 Pod를 실행하고 관리한다.

Q5. 여기서 말하는 리소스란 무엇인가?

A. 리소스는 애플리케이션이 실행되기 위해 사용하는 모든 자원을 의미한다. 여기에는 CPU, 메모리, 스토리지, 네트워크 대역폭 등이 포함된다. 쿠버네티스에서는 이러한 리소스를 관리하고 분배하여 애플리케이션이 원활하게 실행되도록 한다.

Q6. Deployment를 통해 무중단 배포가 가능한 거야..?

A. 무중단 배포는 쿠버네티스의 주요 기능 중 하나이다. 이를 통해 애플리케이션을 업데이트하면서도 서비스 중단 없이 사용자가 계속 애플리케이션을 사용할 수 있도록 보장한다!!!!! 쿠버네티스 대단하다.
쿠버네티스는 롤링 업데이트, 자동 롤백, 로드 밸런싱, 헬스 체크와 같은 기능을 통해 무중단 배포를 실현한다.