[Kubernetes - 파드 실습] 셀렉터, 레이블 활용, 레플리케이션 컨트롤러 & 스케줄링 테스트

 

저는 이전에 쿠버네티스 클러스터를 생성하면서 대시보드를 구성해 놓았기에
해당 대시보드 환경에서 실습을 진행하겠습니다.
저와 같은 환경에서 실습 하실 분들은 해당 링크를 참고하시면 되겠습니다.
https://ddohyung.tistory.com/105

1. POD 생성

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
  - name: container1
    image: kubetm/p8000
    ports:
    - containerPort: 8000
  - name: container2
    image: kubetm/p8080
    ports:
    - containerPort: 8080

 

• apiVersion:
  • 쿠버네티스 API의 버전을 지정합니다. 이 경우 v1은 가장 기본적인 API 버전을 나타냅니다.
• kind:
  • 생성하려는 리소스의 종류를 나타냅니다. 여기서 Pod은 쿠버네티스에서 가장 기본적인 배포 단위입니다.
• metadata:
  • 파드에 대한 메타데이터를 제공합니다. 여기에는 파드의 이름(name: pod-1) 같은 정보가 포함됩니다.
• spec:
  • 파드의 사양(설정)을 정의합니다. 여기서는 파드가 포함할 컨테이너들에 대한 정보를 지정합니다.
    
    
  • containers:
    • 파드 내에서 실행될 컨테이너 목록입니다.
      
      
      
    • 첫 번째 컨테이너(container1):
      • name: 컨테이너의 이름을 지정합니다.
      • image: 컨테이너에서 사용할 이미지의 이름을 지정합니다. 
      • ports: 컨테이너가 사용할 네트워크 포트를 지정합니다.
        • containerPort: 컨테이너가 수신할 포트 번호를 지정합니다. 여기서는 8000번 포트를 사용합니다.
          
          
          
    • 두 번째 컨테이너(container2):
      • name: 두 번째 컨테이너의 이름을 지정합니다.
      • image: 두 번째 컨테이너에서 사용할 이미지의 이름을 지정합니다.
      • ports: 두 번째 컨테이너가 사용할 네트워크 포트를 지정합니다.
        • containerPort: 두 번째 컨테이너가 수신할 포트 번호를 지정합니다. 여기서는 8080번 포트를 사용합니다.
          
          

이 매니페스트는 파드 pod-1을 생성하고, 이 파드 내에 두 개의 컨테이너, container1과 container2를 실행하는데, 각각 8000번 포트와 8080번 포트에서 서비스를 제공하도록 구성합니다.

 

 

 

 

 

 

2. 파드 생성 확인

 

 

 

curl 명령어를 통한 연결 확인

 

 

 

 

 

3. 동일 포트 오류 예시(실습)

 

 

pod를 한 개 더 해보자
대신 하나의 파드 내에서 2개의 컨테이너 포트를 동일하게 8000으로 설정해보자

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
spec:
  containers:
  - name: container1
    image: kubetm/p8000
    ports:
    - containerPort: 8000
  - name: container2
    image: kubetm/p8000
    ports:
    - containerPort: 8000

 

 

 

 

컨테이너 2의 로그를 보니 해당 포트가 이미 사용되고 있어 에러가 발생하였다.

 

 

한 파드 내에서 서로 포트가 중복될 수 없는 것을 확인해 보았다.

 

 

---

4. 레플리케이션 컨트롤러 예제(실습)

 

apiVersion: v1
kind: ReplicationController
metadata:
  name: replication-1
spec:
  replicas: 1
  selector:
    app: rc
  template:
    metadata:
      name: pod-1
      labels:
        app: rc
    spec:
      containers:
      - name: container
        image: kubetm/init

쿠버네티스의 복제 컨트롤러(ReplicationController)를 정의하는 매니페스트 파일입니다. 복제 컨트롤러는 지정된 수의 파드 복제본이 항상 실행되도록 보장하는 오브젝트입니다. 

1. apiVersion:
   • 쿠버네티스 API의 버전을 명시합니다
   • v1은 사용 중인 API 버전입니다.
     
     
2. kind:
   • 생성하고자 하는 쿠버네티스 리소스의 종류를 명시합니다.
   • ReplicationController는 파드의 복제본을 관리합니다.
     
     
3. metadata:
   • 리소스에 대한 메타데이터를 제공합니다.
   • name: 복제 컨트롤러의 이름을 지정합니다 (replication-1).
     
     
4. spec:
   • 복제 컨트롤러의 사양(설정)을 정의합니다.
     
     
   • replicas:
     • 유지하고자 하는 파드의 복제본 수를 지정합니다. 여기서는 1개의 복제본을 유지하도록 설정되어 있습니다.
   • selector:
     • 복제 컨트롤러가 관리할 파드를 선택하는 데 사용되는 레이블 실렉터입니다.
       
       
     • app:
       • 이 복제 컨트롤러가 관리할 파드들의 애플리케이션 그룹을 rc로 지정합니다.
   • template:
     • 새로운 파드 복제본을 생성할 때 사용될 파드 템플릿을 정의합니다.
       
       
     • metadata:
       • 템플릿의 메타데이터를 정의합니다.
       • name:
         • 생성될 파드의 이름을 지정합니다 (pod-1).
       • labels:
         • 파드를 분류하기 위한 레이블을 지정합니다.
           
           
         • app:
           • 이 레이블은 복제 컨트롤러의 selector와 매치되어 관리 대상임을 나타냅니다 (rc).
             
             
     • spec:
       • 파드 사양을 정의합니다.
       • containers:
         • 파드 내에서 실행될 컨테이너 목록입니다.
         • name:
           • 컨테이너의 이름을 지정합니다 (container).
         • image:
           • 컨테이너에서 사용할 이미지의 이름을 지정합니다. 여기서는 kubetm/init이라는 이미지를 사용합니다.

 

이 복제 컨트롤러 replication-1는 app=rc 레이블을 가진 파드의 단일 복제본을 유지하도록 구성되어 있으며, 이 복제본은 pod-1이라는 이름으로 생성될 것입니다. 해당 파드는 container라는 이름의 컨테이너를 포함하고, 이 컨테이너는 kubetm/init 이미지를 기반으로 실행됩니다.

 

 

 

이 파드를 한 번 삭제해 보겠습니다.

 

 

바로 새로운 ip로 pod를 다시 생성하는 것을 볼 수 있습니다.

 

 

---

 

 

5. 레이블 & 셀렉터 예제 (실습)

 

이번엔 레이블을 지정하고 셀렉터로 해당 하는 파드만 서비스에 연결되도록 실습을 하겠습니다.
위처럼 6개의 파드를 생성하였고, 각각의 레이블은 다음과 같이 주었습니다.

 

apiVersion: v1
kind: Service
metadata:
  name: svc-for-web
spec:
  selector:
    type: web
  ports:
  - port: 8080

 

위 서비스 svc-for-web는 type=web 레이블을 가진 파드로 네트워크 트래픽을 전달하도록 구성되어 있으며, 클러스터 내부 또는 외부에서 해당 서비스에 접근하려면 8080번 포트를 사용해야 합니다.

• apiVersion: 쿠버네티스 API의 버전을 명시합니다. 이 경우 v1은 기본 API 버전입니다.
• kind: 생성하고자 하는 쿠버네티스 리소스의 종류를 명시합니다. 여기서 Service는 파드 집합에 접근하기 위한 정의된 방법입니다.
• metadata: 서비스에 대한 메타데이터를 제공합니다.
  • name: 서비스의 이름을 지정합니다 (svc-for-web).
• spec: 서비스의 사양(설정)을 정의합니다.
  • selector: 서비스가 관리할 파드를 선택하는 데 사용되는 레이블 셀렉터입니다.
    • type: 서비스가 관리할 파드의 타입을 지정합니다 (web). 즉, type: web 레이블을 가진 모든 파드가 이 서비스에 의해 관리됩니다.
  • ports: 서비스가 수신할 포트 목록입니다.
    • port: 서비스에 도달하기 위해 사용될 포트 번호를 지정합니다. 여기서는 8080번 포트를 사용합니다.

 

 

웹에 해당하는 파드들만 셀렉터로 지정

 

이렇게 웹에 해당하는 두 개의 파드가 연결된 것을 볼 수 있다.

 

---

 

이번에는 프로덕션 레이블인 파드들만 서비스에 연결해 보겠습니다.

apiVersion: v1
kind: Service
metadata:
  name: svc-for-production
spec:
  selector:
    lo: production
  ports:
  - port: 8080

 

 

아래와 같이 production 레이블의 파드들만 연결이 되었습다.

 

 

---

6. 스케줄링 테스트 예제 (실습)

 

쿠버네티스의 스케줄링 메커니즘은 여러 요소를 고려하여 파드(Pod)를 적절한 노드(Node)에 할당합니다.
이 과정에서 각 노드에 점수를 매기는데,
이 점수는 노드의 자원 사용률, 네트워크 위치, 특정 요구 사항 충족 여부 등 여러 요인에 따라 결정됩니다.
여기서 중요한 요소 중 하나가 노드의 자원 사용률입니다.


여기서 해당 파드 3개를 생성하여 각각 어떤 노드에 스케줄링되는지 알아볼 것입니다.

 

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
spec:
  nodeSelector:
    kubernetes.io/hostname: k8s-node1
  containers:
  - name: container
    image: kubetm/init

 

 

위는 k8s-node1이라는 노드에 pod-3인 파드를 생성하고, 실행합니다.

 

 

 

똑같이 노드 2에 파드를 생성해줍니다.

 

 

이렇게 노드 1은 70%의 메모리 요청을 받고 있고,
 노드 2는 50%의 요청을 받고 있는 상태이다

이 상태에서 특정 노드를 지정하지 않고 파드를 생성하면,
해당 파드는 어디 노드에 스케줄링 될까?

apiVersion: v1
kind: Pod
metadata:
  name: pod-4
spec:
  containers:
  - name: container
    image: kubetm/init
    resources:
      requests:
        memory: 0.5Gi
      limits:
        memory: 0.5Gi

 

 

위와 같은 파드를 생성해보고 , 결과를 한 번 보자

 

 

 

쿠버네티스의 스케줄링 메커니즘은 여러 요소를 고려하여 파드(Pod)를 적절한 노드(Node)에 할당하는데,
이 과정에서 각 노드에 점수를 매깁니다.
이 점수는 노드의 자원 사용률, 네트워크 위치, 특정 요구 사항 충족 여부 등 여러 요인에 따라 결정되는데
여기서 중요한 요소 중 하나가 노드의 자원 사용률입니다.



일반적으로, 스케줄러는 더 많은 여유 자원을 가진 노드를 선호합니다.
위의 경우, 노드 2는 노드 1보다 낮은 메모리 요청률(50%)을 가지고 있으므로,
스케줄러는 노드 2에 파드를 할당하였습니다.