Kubernetes-Masterclass | Kubernetes, Pod, ReplicaSet, Deployment

선언형 cli 설치

• aws cli

• kubectl
 
쿠버네티스는 다음을 제공한다: 쿠버네티스 API를 사용하여 쿠버네티스 클러스터의 컨트롤 플레인과 통신하기 위한 커맨드라인 툴
이 툴의 이름은 kubectl이다.

• eksctl
 
Amazon EKS에서 Kubernetes 클러스터를 생성 및 관리하기 위한 간단한 명령줄 유틸리티인 eksctl

EKS 핵심 4가지 개념

• EKS 컨트롤 플레인
• EKS는 AWS에서 관리하는 완전 관리형 서비스이므로, 마스터 노드를 직접 관리할 필요가 없습니다.
• EKS 컨트롤 플레인은 최소 2개의 API 서버와 3개의 외부 노드로 구성되며, 3개의 가용 영역에 배포됩니다.
• 이를 통해 고가용성과 내결함성을 제공합니다.

• 워커 노드 및 노드 그룹
• 워커 노드는 사용자가 프로비저닝하고 관리하는 EC2 인스턴스입니다.
• 워커 노드는 쿠버네티스 클러스터 API 서버 엔드포인트에 연결되어야 합니다.이를 위해 VPC 내부에서 워커 노드가 API 서버에 액세스할 수 있어야 합니다.
• 노드 그룹은 하나 이상의 EC2 인스턴스로 구성된 Auto Scaling 그룹입니다.eksctl을 사용하면 IAM 권한 관리가 쉽습니다.
• NAT 게이트웨이는 자동으로 생성되어 사용됩니다.
• 작업자 노드의 보안 그룹에는 클러스터 보안 그룹과 RemoteAccess 보안 그룹이 포함됩니다.
• RemoteAccess 보안 그룹은 포트 80을 모두 열어두는 것이 일반적입니다.

• Fargate 프로필
• Fargate를 사용하면 EC2 인스턴스를 프로비저닝할 필요 없이 서버리스로 워크로드를 실행할 수 있습니다.
• Fargate 프로필을 생성하려면 VPC의 프라이빗 서브넷이 필요합니다.

• VPC
• VPC는 EKS 클러스터의 핵심 구성 요소입니다.
• VPC 설계 시 보안이 가장 중요한 고려 사항입니다.
• Fargate 프로필을 생성하려면 VPC의 프라이빗 서브넷이 필요합니다.
• EKS를 사용하려면 VPC, 보안 그룹, 서브넷 등 네트워크 전반에 대한 이해가 필요합니다.

IAM OIDC Provider

• 쿠버네티스에서 Service Account에 IAM Role을 사용하기 위해서는 클러스터에 IAM OIDC (OpenID Connect) Provider가 존재해야 합니다.

• IAM OIDC Provider는 쿠버네티스 클러스터와 AWS IAM 간의 신뢰 관계를 설정하는 역할을 합니다. 이를 통해 Service Account에 IAM Role을 연결할 수 있습니다.

• 클러스터에 IAM OIDC Provider가 존재하지 않는다면, Service Account에 IAM Role을 사용할 수 없습니다. 클러스터 생성 시 또는 클러스터 생성 후 IAM OIDC Provider를 생성해야 합니다.

• 쿠버네티스를 생성하는 권한도 필요하지만, 클러스터 안에서 사용할 iam도 필요하다.

eksctl utils associate-iam-oidc-provider \
    --region ap-northeast-2 \
    --cluster eksdemo1 \
    --approve

• 파드가 도커 컨테이너인데, 내 부모가 가진 것을 상속받아 사용할 수 없다. OIDC는 쿠베 안의 객체에 서비스 어카운트라는 타입으로 OIDC 권한을 넣어주면 권한을 쓸 수 있도록 생긴다.

• IMDS랑은 무엇이 다른가?
• STS, Assume Role에러가 아닌 다른 에러가 발생한다. OIDC 관련 에러가 발생하면 파드가 IMDS 툴을 통해 권한을 얻을 수 없을 때 발생한다고 본다.
• 파드한테 특별한 권한을 더 주고 싶을 때 사용한다.

필수

eksctl delete cluster name # 클러스터 삭제

Kubernetes 개요

1. Service Discovery and Load Balancing (서비스 디스커버리 및 로드 밸런싱):
• 쿠버네티스는 클러스터 내의 컨테이너를 자동으로 네트워킹하고 서비스 디스커버리를 제공합니다. 각 Pod에 고유한 IP 주소를 부여하고, 서비스 내의 Pod들 간에 로드 밸런싱을 수행하여 트래픽을 분산시킵니다.
• 예: Service 객체를 통해 서비스 디스커버리와 로드 밸런싱을 구현합니다.

2. Storage Orchestration (스토리지 오케스트레이션):
• 쿠버네티스는 로컬 스토리지, 클라우드 스토리지, 네트워크 스토리지 등 다양한 스토리지 솔루션과 통합할 수 있습니다. 이를 통해 상태 저장 애플리케이션도 손쉽게 관리할 수 있습니다.
• 예: PersistentVolume(PV)와 PersistentVolumeClaim(PVC) 객체를 통해 스토리지를 동적으로 할당하고 관리합니다.

3. Automated Rollouts and Rollbacks (자동 롤아웃 및 롤백):
• 쿠버네티스는 애플리케이션의 업데이트를 자동으로 처리할 수 있으며, 문제가 발생할 경우 이전 버전으로 롤백할 수 있습니다. 이를 통해 무중단 배포를 실현합니다.
• 예: Deployment 객체를 통해 롤링 업데이트와 롤백을 설정합니다.
• Rollout은 새로운 애플리케이션 버전을 배포하는 과정을 의미합니다.

4. Automatic Bin Packing (자동 빈 패킹):
• 쿠버네티스는 각 컨테이너에 할당된 리소스(CPU, 메모리 등)를 기반으로 최적의 노드에 스케줄링하여 리소스를 효율적으로 사용합니다.
• 예: 스케줄러가 노드의 리소스 사용량을 고려하여 Pod를 배치합니다.

5. Self-Healing (자가 복구):
• 쿠버네티스는 장애가 발생한 컨테이너를 자동으로 재시작하거나, 노드 장애 시 다른 노드로 자동으로 이동시키는 등 자가 복구 기능을 제공합니다.
• 예: ReplicaSet과 DaemonSet 객체가 장애 발생 시 자동으로 Pod를 복구합니다.

6. Secrets and Configuration Management (시크릿 및 구성 관리):
• 쿠버네티스는 애플리케이션 설정 및 시크릿 데이터를 안전하게 관리할 수 있습니다. 이는 환경 변수나 파일로 컨테이너에 주입될 수 있습니다.
• 예: ConfigMap과 Secret 객체를 통해 환경 설정과 시크릿 데이터를 관리합니다.

EKS와 Kubernetes 사용의 차이

• Application Workloads에 초점을 맞출 수 있습니다.
• etcd, kube-scheduler, kube-apiserver 등 쿠버네티스 컨트롤 플레인 구성요소는 AWS에서 관리되므로 신경 쓸 필요가 없습니다.

• 쿠버네티스 자체에 대한 유지보수 걱정이 없습니다.
• 고가용성, 확장성, 업데이트 등 쿠버네티스 플랫폼 관리는 AWS에서 처리합니다.
 

• 애플리케이션 설계, 배포, 노드 그룹 관리에 집중할 수 있습니다.
• 애플리케이션 아키텍처 설계, 배포 전략 수립, AWS 리소스(노드 그룹) 관리 등에 초점을 맞출 수 있습니다.

EKS 구성요소

• Pod
• pod는 Application의 싱글 인스턴스이다. 쿠버네티스에서 만들 수 있는 가장 작은 단위의 객체다.

• ReplicaSet
• replicaSet은 지정된 수의 파드가 항상 작동하도록 가용성을 보장한다.
• 지정된 특정한 파드의 숫자를 계속해서 이용할 수 있도록 가용성을 보장하는 역할을 한다.

• Deployment
• Deployment 파트는 Application의 여러 Replica를 실행하며 실패하거나 응답하지 않는 인스턴스를 자동으로 교체한다.
• Deployement를 생성할 때 Application 변경 사항을 롤아웃하고 롤백하는 추가 기능도 제공 된다. Deployment는 Stateless application에 적합하다.

• Service
• 서비스는 각 파드들을 위한 추상화된 요소들을 제공한다.
• 네트워크 주소를 제공하며, 파드 앞에 위치하여 로드 밸런서를 통해 접근할 수 있게 하고 트래픽을 로드밸런싱 한다.
• Service에서 Cluster IP와 NodePort를 통해 Deployment를 열고 사용자들에게 노출시킬 필요가 있을 때만 Ingress를 쓴다.
• port를 Export하는 것은 서비스로하고 로드밸런싱은 Ingress로 한다.

접근 방식

• 선언형(Declarative)
• 선언형에서는 yaml과 kubectl을 통해 pod / replicaSet / Deployment / Service를 생성한다.
• yaml을 사용하여 manifest를 작성하고, kubectl을 사용하여 원하는 모든 명령어를 실행할 수 있으며 yaml을 사용하여 작성된 manifest로 이를 통해 직접 구현할 수 있다.
• 그냥 yaml을 사용해 key-value로 정의된 파일로 쿠버네티스 리소스를 생성하는 방식이다.

• 명령형(Imperative)
• kubectl을 사용하여 pod / replicaSet / Deployment / Service를 생성한다.
• 커맨드로 쿠버네티스 리소스를 생성하는 방식이다.

파드 개요

• Kubernetes에서 주요 목표는 컨테이너 형태의 Application을 쿠버네티스 클러스터내의 워커 노드에 배포하는 것이다.

• Kubernetes는 이런 컨테이너를 워커 노드에 직접 배포하지 않는다. 컨테이너는 파드라는 Kubernetes 객체로 캡슐화된다. 파드는 단일 인스턴스, 즉 Application의 단일 인스턴스다.

• 파드는 일반적으로 컨테이너와 1:1 관계를 가진다.

• 단일 파드에 여러 컨테이너를 가질 수 있게 만들 수 있지만 매우 특수한 케이스에 한정되며, 단일 파드에 여러 컨테이너를 만들지 말아야 한다.

• 다중 컨테이너 파드를 사용할 때 장점은 두 컨테이너가 하나의 컨테이너 네트워크를 공유하기 때문에 서로 쉽게 통신하고 지원이 가능하다는 점이다.

• 이닛 컨테이너를 통해 코드를 고치기 싫을 때 테스트를 위해서 사용할 수 있다.

• 워커노드 상태 확인

kubectl get nodes

• pod 생성

kubectl run my-first-pod --image stacksimplify/kubenginx:1.0.0

• pod 상세정보 확인

kubectl describe pod 

# To get list of pod names
kubectl get pods

# Describe the Pod
kubectl describe pod <Pod-Name>
kubectl describe pod my-first-pod 

• pod 삭제

kubectl get pods # 명령어로 먼저 확인 후
 
kubectl delete pod my-first-pod # 지우고 싶은 특정 파드 삭제

• pod 로그 출력

# Get Pod Name
kubectl get po

# Dump Pod logs
kubectl logs <pod-name>
kubectl logs my-first-pod

# Stream pod logs with -f option and access application to see logs
kubectl logs <pod-name>
kubectl logs -f my-first-pod

kubectl logs -f my-first-pod, -f 플래그를 사용하면 로그를 실시간으로 확인할 수 있다.
• f : 로그를 실시간으로 스트리밍합니다.
• c : 여러 컨테이너가 있는 경우, 특정 컨테이너의 로그를 확인할 수 있습니다.

• 파드에서 내부 컨테이너에 연결하는 방법

# Connect to Nginx Container in a POD
kubectl exec -it <pod-name> -- /bin/bash
kubectl exec -it my-first-pod -- /bin/bash

# Execute some commands in Nginx container
ls
cd /usr/share/nginx/html
cat index.html
exit

• delete pod

# pod delete
kubectl delete pod my-first-pod

# service delete
kubectl delete svc <service-name>

Application Access 개요

• 현재 생성된 파드에 kubectl 명령어를 통해 접근할 수 있지만, 인터넷을 통해 접근하기 위해서는 Service가 필요하다.

• Pod만 생성하면 pod service

• ReplicaSet만 생성하면 ReplicaSet service

• Deployment만 생성하면 Deployment service

NodePort 개요

• Cluster IP:클러스터 내부에서만 접근할 수 있는 서비스입니다.
• 클러스터 내부의 다른 Pod나 서비스에서만 포트를 통해 접근할 수 있습니다.

• NodePort:워커 노드의 포트를 통해 외부에서 앱에 접근할 수 있도록 해주는 서비스입니다.
• 각 워커 노드의 IP와 특정 포트(30,000 - 32,767 범위)에서 서비스를 노출합니다.
• 클러스터 외부에서 워커 노드의 IP와 포트를 사용하여 서비스에 접근할 수 있습니다.

• LoadBalancer:클라우드 공급자와 통합되어 자동으로 로드밸런서를 생성하는 서비스입니다.
• 클라우드 공급자가 제공하는 로드밸런서 기능을 활용하여 외부에 서비스를 노출합니다.

1. Cluster IP 서비스:'my-first-pod' 파드는 Cluster IP 서비스를 통해 클러스터 내부에서 접근할 수 있습니다.
1. Cluster IP 서비스의 포트는 일반적으로 80번 포트입니다.

2. NodePort 서비스:NodePort 서비스는 워커 노드의 포트(30,000 ~ 32,767 범위)를 통해 클러스터 외부에서 접근할 수 있도록 합니다.
1. kubectl을 통해 NodePort 서비스를 생성할 때 포트 번호는 자동으로 할당되며, YAML 파일을 사용하여 선언적으로 포트 번호를 지정할 수 있습니다.
2. 클러스터 외부에서 요청이 워커 노드의 NodePort로 들어오면, NodePort 서비스는 이를 Cluster IP:80으로 전달합니다.Cluster IP 서비스는 다시 'my-first-pod' 파드의 컨테이너 포트(예: 8080)로 접근하여 애플리케이션에 접근할 수 있도록 합니다.

Port

• Port: Kubernetes 클러스터 내부에서 NodePort 서비스가 수신 대기하는 포트

• targetPort: 애플리케이션이 실행되고 있는 컨테이너 포트를 정의하는 곳

• NodePort: 애플리케이션에 접근할 수 있는 워커 노드의 포트

ReplicaSet 개요

ReplicaSet의 목적

• 고가용성 : ReplicaSet은 지정된 수의 파드가 항상 실행되도록 보장한다. 앱이 실패하여 파드가 죽으면 ReplicaSet은 즉시 새로운 파드를 실행시켜 지정된 수의 파드가 실행되도록 한다.

• 부하 분산(Scaling) : ReplicaSet과 함께 서비스를 사용하면 트래픽을 효과적으로 분산시킬 수 있다.
• 쿠버네티스는 ReplicaSet의 요소 중 하나인 서비스를 통해 파드의 로드밸런싱 부하 분산을 수행한다.

• 확장성 : 트래픽이 급격히 증가하면 ReplicaSet을 통해 파드를 줄이고 늘리면서 확장성을 가질 수 있다.

• 라벨 & 셀렉터 : Labels & Selectors과 Pod / ReplicaSet & Service까지 3가지 요소로 묶이며 yaml manifests를 작성할 때 알 수 있다.

Labels & Selectors

• Labels : 파드 / ReplicaSet / Service 등의 k8s 객체에 메타데이터를 추가하는 키-값 쌍이다. 레이블을 통해 객체를 식별하고 그룹화할 수 있다.

• Selectors : 레이블을 기반으로 특정 객체를 선택하는 기준이다.

Scale

kubectl scale
kubectl scale --replicas=5 rs/my-replicaset

ReplicaSet 생성

• apiVersion: apps/v1는 ReplicaSet의 API 버전을 지정합니다.

• kind: 객체의 종류를 정의합니다. 여기서는 ReplicaSet입니다.

• metadata: ReplicaSet의 이름을 지정합니다.

• spec: ReplicaSet의 사양을 정의합니다.

• replicas: 생성할 파드의 수를 설정합니다. 여기서는 3으로 설정했습니다.

• selector: ReplicaSet이 관리할 파드를 식별하기 위한 레이블 셀렉터를 정의합니다.

• template: ReplicaSet이 생성할 파드의 템플릿을 정의합니다.

• metadata: 파드에 적용할 레이블을 지정합니다.

• spec: 파드의 컨테이너 사양을 정의합니다.

• ReplicaSet 생성 및 확인

• ReplicaSet 생성: 아래 명령어로 ReplicaSet을 생성합니다.

ReplicaSet의 고가용성

my-helloworld-rs-hzp7m   1/1     Running   0          11m
my-helloworld-rs-t9wlc   1/1     Running   0          11m
my-helloworld-rs-tp5td   1/1     Running   0          11m
kubectl delete pod my-helloworld-rs-tp5td
pod "my-helloworld-rs-tp5td" deleted

# 지운 이후
my-helloworld-rs-6jlzq   1/1     Running   0          30s
my-helloworld-rs-hzp7m   1/1     Running   0          12m
my-helloworld-rs-t9wlc   1/1     Running   0          12m

spec:
  replicas: 3
  
#

spec:
  replicas: 6
  
kubectl replace -f replicaset-demo.yml

my-helloworld-rs-6jlzq   1/1     Running   0          3m38s
my-helloworld-rs-hzp7m   1/1     Running   0          15m
my-helloworld-rs-t9wlc   1/1     Running   0          15m
my-helloworld-rs-vg7nk   1/1     Running   0          19s
my-helloworld-rs-xmzsm   1/1     Running   0          19s
my-helloworld-rs-zdmsx   1/1     Running   0          19s=

ReplicaSet Delete

kubectl delete rs <name>
kubectl delete rs my-helloworld-rs
kubectl delete svc my-helloworld-rs-service

Deployment

Deployment Features

• ReplicaSet 롤아웃: 배포를 생성하면 기본적으로 ReplicaSet이 롤아웃됩니다.

• 배포 업데이트: 애플리케이션 버전을 업데이트할 수 있습니다. 업데이트된 버전은 기록되므로, 필요 시 이전 버전으로 쉽게 롤백할 수 있습니다.

• 확장성: ReplicaSet에서와 마찬가지로 배포에서도 복제 수를 조정할 수 있습니다.

• 일시 중지 및 재개: 여러 변경 사항을 즉시 Pod에 적용하지 않고 배포를 일시 중지한 후 변경 사항을 모두 적용할 수 있습니다.

• 상태 확인: 배포의 롤아웃 상태를 모니터링할 수 있습니다.

• 정리 정책: 배포의 버전 역사를 관리하고 기본적으로 마지막 10개 버전을 유지합니다.

• 카나리 배포: 새로운 애플리케이션 버전을 라이브 트래픽에 점진적으로 롤아웃할 수 있습니다.

Deployment Update

• set image

kubectl get deployment my-first-deployment -o yaml

# Update Deployment - SHOULD WORK NOW
kubectl set image deployment/<Deployment-Name> <Container-Name>=<Container-Image> --record=true
kubectl set image deployment/my-first-deployment kubenginx=stacksimplify/kubenginx:2.0.0 --record=true

# 이전

- image: stacksimplify/kubenginx:1.0.0

# 이후

- image: stacksimplify/kubenginx:2.0.0

• edit deployment
kubectl edit deployment 옵션을 사용하여 애플리케이션을 V2에서 V3로 업데이트할 것이다. kubectl edit deployment my-first-deployment 명령어를 입력하면, 배포 사양(Spec)파일이 열린다. 여기서 버전을 3으로 업데이트 한다.

# Edit Deployment
kubectl edit deployment/<Deployment-Name> --record=true
kubectl edit deployment/my-first-deployment --record=true

# Change From 2.0.0
    spec:
      containers:
      - image: stacksimplify/kubenginx:2.0.0

# Change To 3.0.0
    spec:
      containers:
      - image: stacksimplify/kubenginx:3.0.0

 
 

# Verify Rollout Status 
kubectl rollout status deployment/my-first-deployment

# Verify Deployment
kubectl get deploy

kubectl describe deployment my-first-deployment

# StrategyType:           RollingUpdate

• Rolling Update: 대부분의 애플리케이션에서 사용. 예를 들어, 웹 애플리케이션, 마이크로서비스 등 무중단 배포가 필요한 경우.

• Recreate: 상태 비저장 애플리케이션, 초기 개발 단계, 또는 특정 애플리케이션이 모든 인스턴스를 동시에 업데이트해야 하는 경우.

Deployment Rollback

• 첫째, 바로 이전 버전으로 롤백하거나

• 둘째, 특정 버전으로 롤백할 수 있다.

# List Deployment History with revision information
kubectl rollout history deployment/my-first-deployment --revision=1
kubectl rollout history deployment/my-first-deployment --revision=2
kubectl rollout history deployment/my-first-deployment --revision=3

# Undo Deployment
kubectl rollout undo deployment/my-first-deployment

# List Deployment Rollout History
kubectl rollout history deployment/my-first-deployment  

1         <none>
3         kubectl set image deployment/my-first-deployment kubenginx=stacksimplify/kubenginx:2.0.0 --record=true
4         kubectl set image deployment/my-first-deployment kubenginx=stacksimplify/kubenginx:2.0.0 --record=true

kubectl get deploy
kubectl get rs
kubectl get po
kubectl describe deploy my-first-deployment

# Rolling Restarts
kubectl rollout restart deployment/<Deployment-Name>
kubectl rollout restart deployment/my-first-deployment

# Get list of Pods
kubectl get po

kubectl get pods
NAME                                  READY   STATUS    RESTARTS   AGE
my-first-deployment-c4bf784bc-m4f7g   1/1     Running   0          2m26s
my-first-deployment-c4bf784bc-mwnjr   1/1     Running   0          2m27s

kubectl rollout restart deployment/my-first-deployment

deployment.apps/my-first-deployment restarted
kubectl get pods                                      
NAME                                   READY   STATUS    RESTARTS   AGE
my-first-deployment-6bc678c7bb-frk8r   1/1     Running   0          3s
my-first-deployment-6bc678c7bb-s4cct   1/1     Running   0          2s

Deployment Pause

# Pause the Deployment
kubectl rollout pause deployment/<Deployment-Name>
kubectl rollout pause deployment/my-first-deployment

# Update Deployment - Application Version from V3 to V4
kubectl set image deployment/my-first-deployment kubenginx=stacksimplify/kubenginx:4.0.0 --record=true

# Check the Rollout History of a Deployment
kubectl rollout history deployment/my-first-deployment  
Observation: No new rollout should start, we should see same number of versions as we check earlier with last version number matches which we have noted earlier.

# Get list of ReplicaSets
kubectl get rs
Observation: No new replicaSet created. We should have same number of replicaSets as earlier when we took note. 

# Make one more change: set limits to our container
kubectl set resources deployment/my-first-deployment -c=kubenginx --limits=cpu=20m,memory=30Mi

# Resume the Deployment
kubectl rollout resume deployment/my-first-deployment

# Check the Rollout History of a Deployment
kubectl rollout history deployment/my-first-deployment  
Observation: You should see a new version got created

# Get list of ReplicaSets
kubectl get rs
Observation: You should see new ReplicaSet.

8         kubectl set image deployment/my-first-deployment kubenginx=stacksimplify/kubenginx:4.0.0 --record=true

Kubernetes Service

1. Cluster IP
• Cluster IP는 Kubernetes 클러스터 내부에서 애플리케이션 간의 통신을 위해 사용됩니다.
• 예를 들어, 프론트엔드 애플리케이션과 백엔드 애플리케이션이 서로 통신해야 할 때 Cluster IP를 사용합니다.
• Cluster IP는 클러스터 내의 네트워크 범위에서만 유효합니다.

2. Node Port
• Node Port는 Kubernetes 클러스터 외부에서 애플리케이션에 접근할 수 있도록 합니다.
• 워커 노드의 포트를 통해 외부에서 접근할 수 있게 해주며, 브라우저를 통해 애플리케이션에 접근할 수 있게 합니다.

3. Load Balancer
• Load Balancer 서비스는 주로 클라우드 제공업체의 로드 밸런서 서비스와 통합하기 위해 사용됩니다.
• 예를 들어, AWS에서는 Elastic Load Balancer를 사용하여 Kubernetes 매니페스트를 통해 자동으로 로드 밸런서를 프로비저닝할 수 있습니다.

4. Ingress
• Ingress는 고급 로드 밸런서로, 컨텍스트 경로 기반 라우팅, SSL 활성화 및 SSL 리다이렉트 등 다양한 기능을 제공합니다.
• AWS의 Application Load Balancer와 유사한 개념으로, HTTP 기반 기능을 모두 지원합니다.

5. External Name
• External Name 서비스는 클러스터 외부에서 호스팅된 애플리케이션이나 데이터베이스에 접근할 때 사용됩니다.
• 예를 들어, AWS RDS와 같은 클라우드 제공업체 데이터베이스를 Kubernetes 클러스터 내에서 접근할 수 있게 해줍니다.