안녕하세요. 이번 포스팅에서는 쿠버네티스의 기본 용어와 명령어들을 한번 알아보겠습니다.
저는 3대의 가상 이미지를 띄워서 클러스터를 구성했습니다.
실습은 "한 권으로 배우는 도커&쿠버네티스" 책을 참고해서 진행했습니다.
1. 쿠버네티스 구성
쿠버네티스는 마스터노드와 워커노드로 구성되어 있습니다. 마스터노드는 클라이언트의 API 요청을 받고 워커 노드에 명령을 내리는 역할을 합니다. 명령을 받은 워커노드는 실제 컨테이너를 실행하는 역할을 하게 됩니다.
우선 설치된 쿠버네티스 클러스터의 정보부터 확인해보겠습니다.
> kubectl get nodes
NAME STATUS ROLES AGE VERSION
ubun20-01 Ready control-plane 154d v1.28.5
ubun20-02 Ready control-plane 154d v1.28.5
ubun20-03 Ready control-plane 154d v1.28.5
node들의 정보는 위와 같습니다. ansible로 설치한 클러스터로, 설치되면 3개의 노드가 control-plane인 것을 확인할 수 있습니다.
kubectl cluster-info라는 명령어를 통해 클러스터의 정보도 가져올 수 있습니다.
> kubectl cluster-info
Kubernetes control plane is running at https://192.168.64.11:6443
저는 마스터노드를 11번 서버에 설정했기 때문에 cluster-info 명령어를 통해 11번 서버에서 control plane이 running 중이라는 상태를 확인할 수 있습니다.
참고로 마스터노드를 설정하는 방법은 로컬호스트에 저장된 kube config의 내용을 설정해주면 됩니다.
vi ~/.kube/config
해당 파일의 clusters요소에 마스터노드의 같은 경로에 있는 파일의 내용을 넣어주면 됩니다. 서버의 ip는 마스터노드로 설정할 노드의 ip를 적어줍니다.
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: 생략
name: control-cluster
쿠버네티스 클러스터에서 실행중인 pod의 목록을 확인하려면, kubectl get pod 명령어를 실행합니다.
보다 자세한 결과를 확인하고 싶으면, -o wide 옵션을 사용합니다.
위에서 실행했던 get nodes 명령어에서도 -o wide 옵션을 사용하면 자세한 결과를 확인할 수 있습니다.
> kubectl get pod
NAME READY STATUS RESTARTS AGE
metallb-controller-665d96757f-dnnlz 1/1 Running 0 15s
metallb-speaker-l8spq 4/4 Running 54 (12m ago) 60d
metallb-speaker-p5gxk 4/4 Running 42 (12m ago) 60d
metallb-speaker-p5rgm 4/4 Running 40 (12m ago) 60d
nginx-hello-846f4bdb6d-2wl86 1/1 Running 1 (12m ago) 2d18h
nginx-hello-846f4bdb6d-b8x6l 1/1 Running 0 15s
nginx-hello-846f4bdb6d-fz5kg 1/1 Running 1 (12m ago) 2d18h
nginx-hello-846f4bdb6d-hl7wc 1/1 Running 1 (12m ago) 2d18h
nginx-hello-846f4bdb6d-jb6jq 1/1 Running 0 15s
nginx-hello-846f4bdb6d-tg44q 1/1 Terminating 2 (12m ago) 2d18h
nginx-hello-846f4bdb6d-wqjfp 1/1 Terminating 2 (12m ago) 2d18h
> kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
metallb-controller-665d96757f-dnnlz 1/1 Running 0 74s 10.233.109.152 ubun20-02 <none> <none>
metallb-speaker-l8spq 4/4 Running 54 (13m ago) 60d 192.168.64.12 ubun20-02 <none> <none>
metallb-speaker-p5gxk 4/4 Running 42 (13m ago) 60d 192.168.64.13 ubun20-03 <none> <none>
metallb-speaker-p5rgm 4/4 Running 40 (13m ago) 60d 192.168.64.11 ubun20-01 <none> <none>
nginx-hello-846f4bdb6d-2wl86 1/1 Running 1 (13m ago) 2d18h 10.233.104.210 ubun20-01 <none> <none>
nginx-hello-846f4bdb6d-b8x6l 1/1 Running 0 74s 10.233.109.153 ubun20-02 <none> <none>
nginx-hello-846f4bdb6d-fz5kg 1/1 Running 1 (13m ago) 2d18h 10.233.104.209 ubun20-01 <none> <none>
nginx-hello-846f4bdb6d-hl7wc 1/1 Running 1 (13m ago) 2d18h 10.233.104.213 ubun20-01 <none> <none>
nginx-hello-846f4bdb6d-jb6jq 1/1 Running 0 74s 10.233.109.157 ubun20-02 <none> <none>
nginx-hello-846f4bdb6d-tg44q 1/1 Terminating 2 (13m ago) 2d18h 10.233.70.34 ubun20-03 <none> <none>
nginx-hello-846f4bdb6d-wqjfp 1/1 Terminating 2 (13m ago) 2d18h 10.233.70.31 ubun20-03 <none> <none>
실행중인 pod를 삭제할때는 delete 명령을 실행합니다. kubectl delete {pod 이름}
pod를 실행하는 방법에는 명령어에는 run이 있습니다. run 명령어를 통해 hello-world라는 pod를 실행해보겠습니다.
> kubectl run hello-world --image=hello-world --restart=Always pod/hello-world created
pod/hello-world created
> kubectl get pod
NAME READY STATUS RESTARTS AGE
hello-world 0/1 CrashLoopBackOff 1 (4s ago) 11s
이렇게 run 명령어로 pod를 실행할 수 있습니다. 생성된 pod는 delete 명령어로 삭제합니다. 다음으로는 manifest(매니페스트)를 통한 pod를 생성하는 방법이 있습니다. manifest는 yaml 확장자 파일을 이용해 pod를 생성하는 방법입니다. 일반 run 명령어보다 설정할 수있는 옵션이 많고, 한눈에 직관적으로 알아볼 수 있다는 장점이 있습니다.
nginx application을 생성하는 pod를 yaml형식의 manifest파일을 통해 생성해보겠습니다.
참고로 vi로 터미널에서 직접 수정할 수 있지만, 저는 vscode의 익스텐션을 통해 조금 더 간단하게 매니페스트를 작성합니다.
extension에서 yaml를 검색하고 위와 같은 익스텐션을 설치합니다.
설치가 됐으면 톱니바퀴를 클릭하고, Extension Settings(확장 설정)을 클릭합니다.
스크롤을 밑으로 내리다보면 나오는 Edit in settings.json 버튼을 클릭해줍니다.
settings.json에 아래와 같이 kubernetes 관련 설정을 추가해줍니다.
{
"yaml.schemas": {
"kubernetes": "*.yaml"
}
}
만약 json파일 내에 다른 설정이 되어있다면 첫 depth에 위 구문을 넣어주면 됩니다.
설정이 완료됐다면 아래와 같은 자동완성 기능이 활성화되는 것을 볼 수 있습니다.
다시 돌아와서 매니페스트를 이용한 pod 생성에 대해 설명드리겠습니다.
apiVersion: v1
kind: Pod
metadata:
name: nginx01
spec:
containers:
- name: nginx-test01
image: nginx:latest
yaml파일을 통해 pod를 띄울때는 apply 명령어를 사용합니다.
> kubectl apply -f nginx-test.yml
pod/nginx01 created
> kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx01 1/1 Running 0 10s
yaml 파일을 통해 생성한 pod는 생성할 때와 마찬가지로 f 옵션을 준뒤 delete 명령어를 통해 삭제합니다.
> kubectl delete -f nginx-test.yml
pod "nginx01" deleted2. 디플로이먼트
디플로이먼트(deployment)는 파드의 개수를 관리합니다. 파드는 레플리카셋이라는 수치를 통하여 파드의 개수를 설정하고 유지합니다. 디플로이먼트는 이런 파드의 레플리카셋을 관리하고 스펙을 정의하는 기능을 합니다. 또한 생성되고 제거되는 pod의 이력을 관리하는 기능을 가지고 있어, 단순히 pod를 생성하고 레플리카셋을 설정하는 것보다 디플로이먼트를 통해 pod를 관리합니다.
디플로이먼트도 kubectl 명령어를 통해 생성할 수 있습니다. pod는 run 명령어를 통해 생성했다면, 디플로이먼트는 create 명령어를 통해 생성합니다.
> kubectl create deployment deploy-hello --image=hello-world
deployment.apps/deploy-hello created
생성된 디플로이먼트는 아래의 명령어들로 확인할 수 있습니다.
> kubectl get pod
NAME READY STATUS RESTARTS AGE
deploy-hello-7c478bcd59-fsc8p 0/1 Completed 3 (33s ago) 57s
> kubectl get replicaset
NAME DESIRED CURRENT READY AGE
deploy-hello-7c478bcd59 1 1 0 2m6s
> kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
deploy-hello 0/1 1 0 2m20s
생성된 디플로이먼트의 삭제는 pod와 마찬가지로 delete 명령어를 통해 수행합니다.
> kubectl delete deployment deploy-hello
deployment.apps "deploy-hello" deleted
다음으로 디플로이먼트를 실행할 때, 레플리카셋을 조정하는 방법을 알아보겠습니다.
레플리카셋이란, pod의 개수를 원하는 개수만큼 유지시켜 줄 때의 개수를 말합니다. 예를 들어 레플리카셋을 3개로 지정하면 쿠버네티스 클러스터는 해당 디플로이먼트를 통해 생성된 pod의 개수를 항상 3개로 유지시키려고 합니다.
nginx이미지를 통해 레플리카셋이 3인 pod를 생성해보겠습니다.
> kubectl create deployment deploy-nginx --image=nginx --replicas=3
deployment.apps/deploy-nginx created
생성된 pod를 확인해보면, READY 컬럼에 3개의 pod가 관리되고 있음을 알 수 있습니다.
> kubectl get pod
NAME READY STATUS RESTARTS AGE
deploy-nginx-7f979874cf-7qp6w 1/1 Running 0 51s
deploy-nginx-7f979874cf-s7lnt 1/1 Running 0 51s
deploy-nginx-7f979874cf-tdj7w 1/1 Running 0 51s
디플로이먼트와 레플리카셋도 확인해보면 3개의 pod를 관리하고 있음을 확인할 수 있습니다.
> kubectl get deployment,replicaset
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/deploy-nginx 3/3 3 3 99s
NAME DESIRED CURRENT READY AGE
replicaset.apps/deploy-nginx-7f979874cf 3 3 3 99s
레플리카셋이 3개로 설정된 pod를 자세히 살펴보겠습니다. -o wide 옵션을 통해 pod의 상태를 더 자세히 볼 수 있습니다.
> kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-7f979874cf-qwhs2 1/1 Running 0 30s 10.233.70.41 ubun20-03 <none> <none>
deploy-nginx-7f979874cf-skn2j 1/1 Running 0 30s 10.233.70.39 ubun20-03 <none> <none>
deploy-nginx-7f979874cf-vc4mv 1/1 Running 0 30s 10.233.104.225 ubun20-01 <none> <none>
3개의 pod는 각각 10.233.70.41, 10.233.70.39, 10.233.104.225의 IP로 실행됐으며, 위에 두개는 3번 노드에, 아래 한개는 1번 노드에 실행되고 있음을 확인할 수 있습니다. 해당 IP로 띄워진 pod는 클러스터 내부에서만 통신이 가능하고, 현재는 pod를 외부로 노출시키는 작업을 하지 않았기 때문에 로컬호스트에서 해당 IP주소로 접속해보면 접속이 되지 않는 것을 확인할 수 있습니다.
쿠버네티스 클러스터의 서버에 접속해서 nc 명령어를 통해 네트워크 통신을 확인해보면 정상적으로 통신이 되는 것을 확인할 수 있습니다.
> nc -zv 10.233.70.39 80
Connection to 10.233.70.39 80 port [tcp/http] succeeded!
여기서 생성된 pod 중 하나를 삭제해보겠습니다.
> kubectl delete pod deploy-nginx-7f979874cf-qwhs2
pod "deploy-nginx-7f979874cf-qwhs2" deleted
그다음 다시 pod를 확인해보면 아래와 같은 결과를 확인할 수 있습니다.
> kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-7f979874cf-jcdd5 1/1 Running 0 7s 10.233.70.42 ubun20-03 <none> <none>
deploy-nginx-7f979874cf-skn2j 1/1 Running 0 4m27s 10.233.70.39 ubun20-03 <none> <none>
deploy-nginx-7f979874cf-vc4mv 1/1 Running 0 4m27s 10.233.104.225 ubun20-01 <none> <none>
위에서 제거한 qwhs2의 id를 가진 pod가 사라지고 새로운 pod가 생겼습니다.(AGE가 7초) 이렇듯 replicaset이 설정된 deployment는 pod가 어떤 요인에 의해 삭제되면 다른 pod를 생성하여 개수를 유지하려는 성질이 있습니다.
이제 명령어를 통해 생성한 디플로이먼트를 삭제하고 매니페스트를 통해 새로운 디플로이먼트를 생성해보겠습니다.
> kubectl delete deployment deploy-nginx
deployment.apps "deploy-nginx" deleted
> kubectl get deployment
No resources found in default namespace.
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx
spec:
replicas: 3
selector:
matchLabels:
app.kubernetes.io/name: nginx-deploy
template:
metadata:
labels:
app.kubernetes.io/name: nginx-deploy
spec:
containers:
- name: nginx
image: nginx:latest
위 구문에서 처음 나오는 spec은 디플로이먼트에 대한 상태를 정의합니다. 그 안에 있는 또다른 spec은 pod의 상태를 정의하는 것으로 여기서 유의할 점은 디플로이먼트의 matchLabels와 pod의 labels의 이름을 같도록 지정해주어야 합니다.
이제 생성한 매니페스트를 통해 디플로이먼트를 실행시켜보겠습니다.
> kubectl apply -f nginx-deploy.yaml
deployment.apps/deploy-nginx created
생성된 디플로이먼트를 확인해보겠습니다.
> kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-5b6549999b-m2f69 1/1 Running 0 5s 10.233.109.166 ubun20-02 <none> <none>
deploy-nginx-5b6549999b-qmvhp 1/1 Running 0 5s 10.233.104.223 ubun20-01 <none> <none>
deploy-nginx-5b6549999b-zkpld 1/1 Running 0 5s 10.233.70.45 ubun20-03 <none> <none>
레플리카셋이 3개인 디플로이먼트가 잘 실행된 것을 확인할 수 있습니다. 위에서 생성한 yaml파일을 수정하면서 레플리카셋과 이미지의 버전 등을 변경해줄 수 있습니다. metadata의 이름을 같게 설정하면 기존에 생성된 디플로이먼트의 상태를 업데이트 해주는 용도로 사용할 수 있습니다.
3. 서비스
다음으로 서비스에 대해 알아보겠습니다. 서비스는 pod의 외부 접근을 위한 기능을 수행합니다. pod와 디플로이먼트 절에서 확인했듯이 IP주소는 pod가 재생성되면 재할당되는 특성이 있습니다. 이때, 클라이언트는 pod에 접속하기 위해 갖고 있던 IP주소가 변경되었기 때문에 pod로 요청이 정상적으로 이루어지지 않을 수 있습니다. 이런 문제를 해결하기 위해 서비스를 사용합니다. 서비스는 클라이언트의 요청을 받아서 pod로 포워딩해주는 역할을 합니다.
서비스는 이런 특성을 활용해서 외부 트래픽 노출, 로드밸런싱, 서비스에 대한 디스커버리 등의 기능을 수행합니다.
+-----------------------+
| Client |
+-----------+-----------+
|
v
+-----------+-----------+
| Service |
+-----------+-----------+
|
+-------------+--------------+
| | |
v v v
+---+---+ +---+---+ +---+---+
| Pod | | Pod | | Pod |
|(App 1)| |(App 2)| |(App 3)|
+---+---+ +---+---+ +---+---+
쿠버네티스 서비스의 종류에는 ClusterIP, NodePort, LoadBalancer, ExternalName이 있습니다. 서비스의 종류는 매니페스트에서 type으로 지정할 수 있습니다. 이제 서비스 종류 각각에 대해 알아보겠습니다.
(1) ClusterIp
cluster ip는 서비스의 default 값으로, 클러스터 내에서만 pod에 접근할 수 있도록 합니다.
cluster ip를 설정하면, 클러스터 내에서만 접근 가능한 IP를 할당하고, 외부에서는 접근할 수 없습니다.
cluster ip를 설정하는 매니페스트를 작성해보겠습니다.
서비스 실습은 위에서 작성했던 디플로이먼트의 web-deploy먼트를 활용해서 진행하겠습니다.
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app.kubernetes.io/name: nginx-deploy
type: ClusterIP
ports:
- protocol: TCP
port: 80
디플로이먼트의 매니페스트에서 지정한 web-deploy를 selector에 지정해주고, type에 ClusterIP를 넣습니다.
외부 포트는 80번으로 지정해줍니다.
서비스를 작성할 때는 연동할 디플로이먼트를 spec.selector.app.kubernetes.io/name을 통해 지정해주어야 합니다.
디플로이먼트와 같이 실행 명령어는 kubectl apply 입니다. 명령어를 통해서 서비스를 실행시켜 보겠습니다.
> kubectl apply -f service-clusterip.yaml
service/web-service created
서비스를 실행시켰으면 , 정상적으로 기동됐는지 확인해보겠습니다.
> kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 30h
web-service ClusterIP 10.233.34.110 <none> 80/TCP 2s
10.233.34.110의 IP로 cluster ip가 생성된 것을 확인할 수 있습니다.
하지만, cluster ip는 클러스터 내부에서만 통신이 되기 때문에, 제 로컬호스트에서는 접속이 되지 않습니다. 통신이 정상적으로 수행되는 지 확인하기 위해 임시 pod를 하나 생성해서 curl 명령어를 수행해보겠습니다.
> kubectl run test-cluster --image=nginx
kubectl run test-cluster --image=nginx
> kubectl exec -it test-cluster -- /bin/bash
root@test-cluster:/#
root@test-cluster:/# curl "10.233.34.110:80"
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
curl을 통해 명령어를 전송하면, 위와 같이 정상적으로 nginx페이지가 반환되는 것을 확인할 수 있습니다.
계속해서 다른 서비스들을 실습하기 위해 띄워놓은 서비스와 디플로이먼트를 종료하겠습니다.
> kubectl delete pod test-cluser
pod "test-cluster" deleted
> kubectl delete -f service-clusterip.yaml
service "web-service" deleted
> kubectl delete -f nginx-deploy.yaml
deployment.apps "deploy-nginx" deleted
(2) NodePort
NodePort는 각 노드의 특정 포트를 통해 외부 접근을 제공합니다. NodeIp:NodePort를 통해 클러스터 외부에서 클러스터 내부의 pod에 접근할 수 있도록 해줍니다. NAT와 유사한 서비스를 제공합니다.
요청
|
v
+-------------------+
| Node |
| +-------------+ |
| | NodePort | | <- 클러스터의 모든 노드에서 특정 포트가 열림
| +-------------+ |
| | |
| v |
| +-------------+ |
| | Pod | | <- 서비스가 포드로 트래픽을 라우팅
| | (Container)| |
| +-------------+ |
+-------------------+
이제 NodePort를 위한 매니페스트를 작성해보겠습니다.
apiVersion: v1
kind: Service
metadata:
name: web-service-nodeport
spec:
selector:
app.kubernetes.io/name: nginx-deploy
type: NodePort
ports:
- protocol: TCP
nodePort: 31001
port: 80
targetPort: 80
ClusterIp와 마찬가지로 selector에는 생성된 디플로이먼트의 name을 작성해줍니다.
type은 NodePort로 작성하고, NodePort에서는 ports 요소에 nodePort라는 아이템을 작성해줍니다. nodePort는 외부에서 접근하는 아이피를 의미합니다. 외부에서 31001이라는 IP로 접근하면 서비스의 80포트로 접속되고, 서비스의 80포트가 pod의 타겟 포트인 80 포트로 다시 전달한다는 의미입니다.
다시 디플로이먼트를 실행시키고 이번에 생성한 NodePort의 매니페스트를 실행시켜 접속이 가능한 지 확인해보겠습니다.
> kubectl apply -f nginx-deploy.yaml
deployment.apps/deploy-nginx created
> kubectl apply -f service-nodeport.yaml
service/web-service-nodeport created
> kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 31h
web-service-nodeport NodePort 10.233.42.69 <none> 80:31001/TCP 35s
서비스를 확인하면 80:31001과 같이 외부로 노출된 포트가 뒤쪽에 나오는 것을 확인할 수 있습니다.
제 클러스터의 pod를 확인해보면
> kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deploy-nginx-5b6549999b-7mqbs 1/1 Running 0 106s 10.233.70.51 ubun20-03 <none> <none>
deploy-nginx-5b6549999b-gqgcv 1/1 Running 0 106s 10.233.70.48 ubun20-03 <none> <none>
deploy-nginx-5b6549999b-th7bk 1/1 Running 0 106s 10.233.104.234 ubun20-01 <none> <none>
3번 노드에 두개의 pod가 실행되고 있음을 확인할 수 있고, 3번 노드의 IP에 31001 포트로 접근해보면
이렇게 nginx로 접속이 되는 것을 확인할 수 있습니다.
(3) LoadBalancer
다음으로는 로드밸런서에 대해 알아보겠습니다.
로드밸런서는 서비스에서 NodePort의 상위호환이라고 생각하면 됩니다. 외부 IP와 포트를 지정해놓으면 이 IP와 포트를 따라 NodePort로 들어오고 NodePort에서 Pod로 분배되는 순으로 접속하게 됩니다.
다시 매니페스트를 통해서 로드밸런서가 지정된 서비스를 실행시켜보겠습니다.
apiVersion: v1
kind: Service
metadata:
name: web-service-loadbalancer
spec:
selector:
app.kubernetes.io/name: nginx-deploy
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 80
externalIPs:
- 192.168.64.30
매니페스트를 통해 서비스를 생성했습니다. port는 서비스가 사용할 포트, targetPort는 pod가 사용할 포트입니다. 서비스의 80포트로 접속하면 pod의 80번 포트를 통해 디플로이먼트에 접속이 되는 구조입니다.
실행된 서비스의 정보를 확인해보겠습니다.
> kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 3d5h
web-service-loadbalancer LoadBalancer 10.233.44.171 192.168.64.30 80:30825/TCP 81s
서비스가 위에서 설정한 192.168.64.30이라는 IP와 80라는 외부 포트를 통해 네트워크가 오픈된 것을 볼 수 있습니다. 80포트로 접속하면 nodeport로 설정된 30825 포트로 접속되는 구조입니다. 접속해보기 전에, 새로 생긴 EXTERNAL-IP는 제 로컬호스트에서 통신이 되고 있지 않은 상황이니, 포트포워딩을 따로 설정해주겠습니다. 8080 포트를 30번 서버의 80포트에 매핑시켜주겠습니다.
> kubectl port-forward svc/web-service-loadbalancer 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
8080포트로 접속하면 nginx까지 접속이 되는 것을 확인할 수 있습니다. 이렇게 LoadBalance를 사용하면 하나의 IP를 통해 쿠버네티스 클러스터의 pod에 접속할 수 있습니다.
4. 스토리지
'프로그래밍' 카테고리의 다른 글
| [kubernetes] ubuntu 20.04에 python3.11 버전 설치 및 kubespray로 쿠버네티스 설치하기 (2) | 2024.06.11 |
|---|---|
| [kubernetes] 쿠버네티스 환경 구축 (0) | 2024.06.11 |
| [docker] 도커를 통한 flask 실행 (0) | 2024.05.31 |
| [docker] 도커 컨테이너 연결을 통한 프로젝트 구성(feat. nginx, django, postgresql) (0) | 2024.05.25 |
| [docker] 도커 기초 명령어 (0) | 2024.05.19 |
