4. 쿠버네티스 네트워크 이해
이번 장은 실습을 통하여 쿠버네티스 네트워크의 기본 개념을 알아보겠습니다.
1. 기존 VM 환경과 쿠버네티스의 네트워크 차이점
기존 VM 환경의 네트워크와 비교하여 쿠버네티스 환경의 네트워크는 몇가지 차이점이 있습니다.
쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로, 네트워크 추상화 수준이 높습니다. 쿠버네티스를 사용하면 서비스, 인그레스, 네트워크 폴리시 등 네트워크와 관련된 리소스를 사용하는데 쿠버네티스가 복잡한 작업이나 세부 사항들을 단순화하여 사용자에게 보이지 않게 합니다. 사용자는 네트워크 관련 작업을 수행할 때, 그 작업이 어떻게 이루어지는지 모르더라도 간단한 명령이나 인터페이스를 통해 원하는 결과를 얻을 수 있습니다. 고수준의 객체를 사용하여 복잡한 네트워크 구성을 단순화합니다.
이에 비하여 VM 환경은 일반적으로 물리적 하드웨어와 밀접하게 연결되어 상대적으로 수동적인 설정과 관리가 필요합니다. 쿠버네티스 네트워크는 동적이고 자동화된 환경을 제공하는 반면, VM 환경의 네트워크는 종종 더 세밀한 제어와 최적화된 성능을 제공할 수 있습니다.
예를 들어 기존 VM 환경에서 웹 서버와 DB 서버 연결 시 NGINX 웹서버 설정에 DB 서버인 MySQL의 IP를 직접 입력해야 합니다. IP는 고정된(Static) 정보라 만약 DB 서버 IP가 변경되거나 추가되어 IP 변동이 있으면 NGINX 서버에서 일일이 설정을 변경해야 합니다. 그에 비하여 쿠버네티스는 기본 설계 디자인이 항상 고가용성을 고려하므로 파드가 재시작되어 IP가 변경되거나 리소스가 증가하여 IP가 증가하여도 자동으로 이를 인식합니다. 쿠버네티스는 이러한 기능을 서비스(Service)라는 리소스를 이용하여 도메인 기반으로 처리하여 자동 설정이 가능합니다.
쿠버네티스는 동적 환경을 지원하며, 서비스 디스커버리, 로드 밸런싱, 네트워크 격리 등을 자동화합니다. VM 환경에서는 이러한 기능을 수동으로 구성하거나 추가 도구를 사용해야 할 수 있으며, 변경 사항을 적용하기 위해 더 많은 작업이 필요할 수 있습니다.
그리고 쿠버네티스는 플랫 네트워크 모델을 사용하여 모든 파드가 서로 직접 통신할 수 있도록 합니다. 이를 위해 다양한 CNI(Container Network Interface) 플러그인을 사용할 수 있습니다. VM 환경에서는 종종 별도의 VLAN, 서브넷 등을 구성해야 하며, 라우팅과 방화벽 규칙을 수동으로 관리합니다. 물론, 쿠버네티스는 추상화와 자동화의 수준이 높아 관리가 용이하나, 이로 인해 VM 환경에 비해 약간의 오버헤드가 발생할 수 있습니다.
개인적으로 처음에 쿠버네티스의 새로운 네트워크 리소스인 서비스, 인그레스 등을 이해하기 어려웠지만 실제 사용을 해보니 VM 환경보다 추상화, 자동화가 잘되어있어 운영하기가 훨씬 용이하였습니다. 대부분의 환경에서 별도의 네트워크 담당자 없이 쿠버네티스 서비스를 운영하기에 큰 무리가 없었습니다.
2. CNI(Container Network Interface)의 이해와 EKS VPC_CNI의 특징
CNI는 컨테이너 오케스트레이션 시스템에서 네트워크 통신을 담당하는 표준 인터페이스입니다. 클러스터에서 실행 중인 파드의 네트워크 구성과 내, 외부 통신을 관리하는 중요한 역할을 합니다. CNI는 특정 네트워킹 기술과 무관한 표준화된 인터페이스를 제공합니다. 이 인터페이스를 통해 다양한 네트워크 플러그인을 쿠버네티스에 쉽게 통합할 수 있습니다. CNI 표준만 준수한다면 다양한 솔루션을 선택할 수 있습니다.
CNI는 쿠버네티스가 네트워크를 효율적으로 관리하고 확장성을 제공하면서도 특정 네트워크 구현에 종속되지 않게 해줍니다. 이로써 개발자와 시스템 관리자는 쿠버네티스 클러스터의 네트워크 요구 사항에 가장 적합한 솔루션을 자유롭게 선택할 수 있게 되는 것입니다. 예를 들어, 오버레이 네트워크나 SDN 솔루션과 같이 특정 요구 사항에 따른 다양한 네트워크 구현을 선택할 수 있습니다.
CNI는 컨테이너가 생성되거나 삭제될 때, CNI 플러그인은 해당 컨테이너에 필요한 네트워크 리소스를 자동으로 할당하거나 해제합니다. 특정 CNI 플러그인은 Network Policy를 지원하여 개별 파드 단위로 방화벽으로 작동하여 컨테이너 간의 트래픽 흐름을 제어하고 보안을 강화할 수 있습니다.
CNI 종류로 네이티브 쿠버네티스 환경에서는 Calico, Flannel, Cillium 등이 있는데 주로 Calico를 많이 사용하고 최근에는 eBPF 환경이라 성능 및 확장성이 좋은 Cillium도 많이 고려됩니다. EKS는 기본 CNI인 AWS VPC-CNI를 거의 대부분 환경에서 사용합니다. AWS VPC-CNI의 가장 큰 특징은 파드와 노드의 IP가 동일한 VPC 대역의 IP를 사용하는 것입니다. 따라서 서로 다른 노드의 파드 간 통신 시 파드와 노드의 IP가 다른 경우 발생하는 추가적인 IP 변경(NAT, Network Address Translation) 작업없이 직접 통신이 가능하여 성능이 향상됩니다. 물론 동일한 대역을 사용하여 파드의 IP가 많이 필요하여 VPC IP 대역을 미리 충분하게 할당(/20 이상 권고, 4096개)하기를 권고합니다.
그럼, EKS 환경에서 직접 파드 IP를 확인하겠습니다.
k get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-hello-7d95c6dbcb-8dnbs 1/1 Running 0 4h50m 10.110.23.249 ip-10-110-24-222.ap-southeast-1.compute.internal <none> <none>
파드 현황을 확인하는 ‘k get pod’ 명령어에 ‘-o wide’를 추가하면 IP 정보까지 같이 확인할 수 있습니다. 위 출력 결과에서 확인할 수 있듯이 파드의 IP가 ‘10.110.23.249’ 입니다. 그리고 해당 파드가 실행되는 노드의 호스트네임이 ‘ip-10-110-24-222.ap-southeast-1.compute.internal’ 인데 호스트네임에서 알 수 있듯이 노드의 IP가 ‘10.110.24.222’ 임을 확인할 수 있습니다. 파드와 노드의 IP 대역이 동일하게 10.110.x.x를 사용하는 것을 알 수 있습니다.이에 반하여 네이티브 쿠버네티스 환경은 파드와 노드가 사용하는 IP 대역이 서로 다릅니다.
k get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES netshoot-796845c847-t888l 1/1 Running 0 76s 10.233.104.127 master1 <none> <none> k get nodes -o wide master1 NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME master1 Ready control-plane 107d v1.26.2 192.168.1.101 <none> Ubuntu 18.04.6 LTS 4.15.0-206-generic containerd://1.7.0
네이티브 쿠버네티스 환경에서 실행한 ‘netshoot-xxxx’ 파드의 IP는 ‘10.233.104.127’이며 해당 파드가 실행 중인 master1 노드의 IP는 ‘192.168.1.101’ 입니다. 10.233.x.x 과 192.168.x.x으로 서로 다른 IP 대역을 사용하는 것을 확인할 수 있습니다. 따라서 서로 다른 노드에서 실행 중인 파드가 통신을 하기 위해서는 중간 단계에서 노드의 IP로 IP를 변경하는 작업이 필요합니다.
3. 쿠버네티스 리소스 Service의 주요 기능 실습 : 서비스 디스커버리, 로드밸런싱
쿠버네티스는 서비스(Service) 리소스를 이용하여 클러스터 내, 외부의 트래픽을 파드와 연결합니다. 일반적으로 IT에서 서비스란 웹 서비스, DB 서비스 등 애플리케이션을 의미합니다. 하지만 쿠버네티스는 파드와 파드가 서로 연결하는 서비스를 제공하는 의미로 사용하여 네트워크 서비스를 제공하는 의미로 사용합니다. 처음 접하는 분들이 흔히 혼동하는 내용입니다. 쿠버네티스에서 서비스는 애플리케이션의 내부와 외부 간의 네트워크 통신을 관리하는 추상화된 개념이라고 생각하면 조금 편리합니다.
쿠버네티스 서비스의 주요 특징은 서비스 디스커버리와 로드밸런싱입니다. 서비스 디스커버리(discovery)란 discovery 이름에서 알 수 있듯이 변경 사항을 자동으로 발견하는 기능입니다. 클러스터에서 동적으로 파드를 생성하거나 삭제하면 이러한 변경 사항을 서비스가 감지하고 내부에 자동으로 업데이트하여 기존 파드 연결을 유지합니다. 기존 VM 환경에서는 VM의 IP가 변경되면 수동으로 설정 파일에 변경된 IP를 등록해야 하는데 쿠버네티스 환경에서는 자동으로 업데이트하여 추가 설정이 필요없습니다.
쿠버네티스는 DNS 기능을 이용하여 서비스 디스커버리를 구현합니다. 쿠버네티스 서비스는 각 서비스마다 고유한 DNS 이름을 등록하고 각 파드 간 통신 시 파드는 서비스 이름을 이용하여 연결합니다. 서비스 이름에 등록된 파드의 IP 주소와 포트 번호는 쿠버네티스 내부의 서비스 디스커버리 메커니즘을 이용하여 실시간으로 파드의 변경 여부를 체크하여 변경 사항이 업데이트됩니다. 일반적으로 파드는 연결하려는 파드(웹서버의 DB 서버 정보 등)의 서비스 이름을 환경 변수(ConfigMap 이용 권장)에 등록하여 사용합니다.
또한, 쿠버네티스 서비스는 로드 밸런싱 기능을 지원하여 서비스 이름에 등록된 여러 파드에 트래픽을 분산하여 전달합니다. 파드가 실행하는 노드의 iptables(또는 IPVS)의 로드밸런싱 기능을 사용합니다. 파드 수량이 증가하여 여러 개가 있을 경우 서비스는 트래픽을 파드들 사이에 균등하게 분배하여 애플리케이션 가용성과 확장성을 향상시킵니다.
실습
그럼 파드(Deployment)와 서비스를 직접 만들어 보겠습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-hello
namespace: default
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginxdemos/hello
Nginx를 실행하는 간단한 Deployment 파일입니다.
spec.template.metadata.labels.app: nginx
레이블이 app: nginx로 지정되었습니다. 향후 이 레이블 이름을 기준으로 서비스 리소스가 Nginx 파드를 선택합니다.
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector: # 선택해야 할 파드를 지정
app: nginx # 파드 Label과 동일
type: ClusterIP
ports:
- name: tcp
port: 80
targetPort: 80
위에서 선언한 Nginx Deployment와 연결하는 서비스 명세서(매니페스트) 파일입니다.
spec.selector.app: nginx
서비스는 selector 속성을 이용하여 서비스 리소스가 연결할 파드를 선택(select)합니다. 여러 개의 파드 중에서 내가 선택할 파드를 레이블(app: nginx)을 이용하여 지정합니다.
spec.ports.port: 80
서비스가 노출하는 포트 번호를 지정합니다. 클라이언트로 사용하는 다른 파드에서 연결하는 포트 번호입니다.
spec.ports.targetPort: 80
서비스가 바라보는 타겟 파드의 포트 번호입니다. 위의 경우 80 이므로 타겟이 되는 nginx 파드의 80 포트로 연결합니다.
그럼 위 YAML 파일 기준으로 Deployment, Service 리소스를 생성합니다.
$ (⎈ |switch-singapore-test:default) k apply -f nginx-deploy.yaml -f clusterIP-svc.yml deployment.apps/nginx-hello created service/nginx-svc created
$ (⎈ |switch-singapore-test:default) k get deploy,svc NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx-hello 1/1 1 1 75s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx-svc ClusterIP 172.20.107.173 <none> 80/TCP 74s
위와 같이 nginx-svc 라는 이름으로 서비스 리소스가 생성되었습니다. 이제 다른 파드에서 nginx-hello 파드를 연결하기 위해서 서비스 이름인 nginx-svc를 사용합니다.
이렇게 서비스가 생성되면 쿠버네티스는 엔드포인트(endpoint, 종점) 컨트롤러를 이용하여 서비스를 관리합니다. 엔드포인트는 서비스와 파드간의 연결(endpoint)을 관리하여 파드의 상태가 변경되어 IP 정보가 변경되면 자동으로 해당 정보를 업데이트 합니다.
[(jerry-test:default) service]$ k get endpoints nginx-svc NAME ENDPOINTS AGE nginx-svc 10.110.12.31:80 7m34s
ep(endpoint 줄임말) 리소스를 확인하면 nginx-svc 서비스 이름과 nginx 파드의 IP:포트(10.110.12.31:80)를 확인할 수 있습니다. nginx-svc 이름과 nginx 파드가 서로 정상 연결되었다는 의미입니다.
그럼 새로운 파드를 실행하여 서비스 이름으로 통신하겠습니다. 네트워크 트러블슈팅 용도로 많이 사용하는 netshoot 이미지를 가지는 디플로이를 실행합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: netshoot
labels:
app: netshoot
spec:
replicas: 1
selector:
matchLabels:
app: netshoot
template:
metadata:
labels:
app: netshoot
spec:
containers:
- name: netshoot
image: nicolaka/netshoot
args:
- sleep
- infinity
netshoot-xxxx 이름의 파드가 실행됩니다.
[(jerry-test:default) ~]$ k get pod netshoot-7844866874-xjhc9 NAME READY STATUS RESTARTS AGE netshoot-7844866874-xjhc9 1/1 Running 0 6m2s
해당 파드에 접속하여 nginx-svc 서비스 이름으로 파드 간 연결이 가능합니다. 마치 VM에 SSH로 연결하는 것처럼 파드에 접속하기 위하여 exec(실행) + bash 명령어를 사용합니다.
[(jerry-test:default) ~]$ k exec -it netshoot-7844866874-xjhc9 -- bash netshoot-7844866874-xjhc9:~# curl -I nginx-svc HTTP/1.1 200 OK Server: nginx/1.25.2 Date: Tue, 29 Aug 2023 18:34:36 GMT Content-Type: text/html Connection: keep-alive Expires: Tue, 29 Aug 2023 18:34:35 GMT Cache-Control: no-cache
nginx-svc 서비스 이름으로 curl 명령어가 정상으로 실행됩니다. 이처럼 쿠버네티스 환경에서 파드 간 연결에 서비스 이름을 사용하면 됩니다.
다음으로 서로 다른 네임스페이스 간 파드의 통신을 알아보겠습니다. 먼저 네임스페이스(Namespace)는 쿠버네티스 클러스터 내에서 리소스들을 구분하고 격리하는 논리적인 공간입니다. 네임스페이스를 사용하여 클러스터 내의 리소스를 그룹화하여 리소스 간 충돌이나 혼동을 방지할 수 있습니다. 같은 네임스페이스 안에서는 파드, 서비스 이름을 중복하여 사용할 수 없으나 네임스페이스가 다르면 같은 이름을 사용할 수 있습니다. 쿠버네티스 클러스터는 여러 개의 네임스페이스를 가질 수 있으며, 각 네임스페이스는 고유한 이름으로 식별됩니다.
[(jerry-test:default) argo-cd-app-of-apps-qa]$ k ns argocd default kube-node-lease kube-public kube-system nginx
필자의 테스트 클러스터에 사용 중인 네임스페이스 리스트입니다. 네임스페이스는 임의로 생성할 수 있으나, 위와 같이 애플리케이션 이름으로 많이 구분합니다.
같은 네임스페이스 내에서 파드 간 연결은 앞의 예제와 같이 서비스 이름(nginx-svc)으로 가능합니다. 하지만 네임스페이스가 다르면 연결을 위한 서비스 이름에 네임스페이스 이름까지 추가합니다. 예를 들어 nginx-svc가 nginx 네임스페이스에서 실행 중이면 nginx-svc.nginx로 {서비스 이름}.{네임스페이스 이름} 형식으로 연결합니다.
아래는 필자가 임의로 nginx 네임스페이스에 nginx 이름의 서비스를 생성한 예제입니다.
[(jerry-test:nginx) service]$ k get svc -n nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP 172.20.202.76 <none> 80/TCP,9113/TCP 6d23h
default 네임스페이스에서 실행 중인 파드에서 nginx 네임스페이스의 서비스와 연결하기 위해서는 아래와 같이 nginx 네임스페이스 이름을 추가합니다.
netshoot-7844866874-xjhc9:~# curl -I nginx.nginx
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 29 Aug 2023 18:37:22 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 13 Jun 2023 18:21:37 GMT
Connection: keep-alive
ETag: “6488b3b1-267”
X-Frame-Options: SAMEORIGIN
Accept-Ranges: bytes
네임스페이스 이름없이 서비스 이름만으로 호출하면 아래와 같이 연결하지 못합니다.
netshoot-7844866874-xjhc9:~# curl -I nginx curl: (6) Could not resolve host: nginx
실제 사례로 앞으로 배우게 될 모니터링 대시보드 그라파나는 로그 솔루션인 Loki 연결을 아래와 같이 {서비스 이름}.{네임스페이스 이름}을 이용하여 loki-gateway.loki-s3로 연결합니다.
다음은 로드밸런싱 기능입니다. nginx 파드를 재시작하여 파드의 IP가 변경되거나 파드의 수량을 증가하면 서비스가 바라보는 타겟 IP 정보가 변경됩니다. 위와 같은 변동 사항을 서비스는 자동으로 감지하여 정보를 업데이트 합니다. 변경된 내역은 endpoint 리소스에서 확인할 수 있습니다.
실제 파드의 수량을 증가해 보겠습니다. 파드의 수량 증가는 scale 명령어를 사용합니다.
$ (⎈ |switch-singapore-test:default) k scale deployment nginx-hello --replicas 5
deployment.apps/nginx-hello scaled
$ (⎈ |switch-singapore-test:default) k describe ep nginx-svc
Name: nginx-svc
Namespace: default
Labels: <none>
Annotations: endpoints.kubernetes.io/last-change-trigger-time: 2023-07-03T23:51:41Z
Subsets:
Addresses: 10.110.11.214,10.110.15.167,10.110.19.90,10.110.20.44,10.110.23.249
NotReadyAddresses: <none>
Ports:
Name Port Protocol
---- ---- --------
tcp 80 TCP
Events: <none>
describe 명령어를 이용하여 nginx endpoint의 상세 정보를 확인하면 타겟 주소가 이전 1개에서 5개로 증가하였습니다. endpoint 객체가 자동으로 5개로 증가한 파드 IP를 반영하였습니다. 이제 nginx-svc라는 이름으로 접속하면 자동으로 5개의 파드에 균등하게 접속되는 걸 확인할 수 있습니다.
netshoot-7844866874-xjhc9:~# curl -S nginx-svc |grep address
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0<p><span>Server address:</span> <span>10.110.0.151:80</span></p>
100 7236 0 7236 0 0 756k 0 --:--:-- --:--:-- --:--:-- 785k
netshoot-7844866874-xjhc9:~# curl -S nginx-svc |grep address
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
<p><span>Server address:</span> <span>10.110.2.237:80</span></p>:-- 0
100 7236 0 7236 0 0 3381k 0 --:--:-- --:--:-- --:--:-- 7066k
netshoot-7844866874-xjhc9:~# curl -S nginx-svc |grep address
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
1<p><span>Server address:</span> <span>10.110.4.201:80</span></p>-- 0
00 7236 0 7236 0 0 3695k 0 --:--:-- --:--:-- --:--:-- 7066k
위와 같이 nginx-svc 접속 시 응답하는 서버의 IP가 10.110.0.151, 10.110.2.237, 10.110.4.201 등으로 서로 다릅니다. 서비스가 로드밸런싱 하여 하나 이상의 파드에 트래픽을 분산시키기 때문입니다.
4. 클러스터 내/외부 접속에 따른 쿠버네티스 서비스 분류
쿠버네티스 서비스는 클러스터 내부 간 통신을 담당하는 ClusterIP와 내부가 아닌 외부에서 클러스터 내부의 파드와 연결을 담당하는 NodePort, LoadBalancer 타입으로 구분할 수 있습니다. 현업에서는 외부에서 연결 시 주로 Ingress를 사용합니다.
ClusterIP 타입은 클라이언트 파드에서 서비스 이름으로 호출하면 서비스 이름은 DNS 쿼리를 이용하여 ClusterIP를 응답하고 해당 IP는 IPTables 등의 룰로 각각의 파드에 부하분산되어 접속합니다.
$ (⎈ |switch-singapore-test:default) k get svc nginx-svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-svc ClusterIP 172.20.107.173 <none> 80/TCP 3d1h
위 예제에서 CLUSTER-IP는 172.20.107.173 입니다. 실제 다른 파드에서 서비스 이름으로 DNS 쿼리를 하면 아래와 같이 해당 CLUSTER-IP가 응답합니다. curl 등을 이용하여 접속 테스트를 하면 정상 접속됩니다.
netshoot:~# nslookup nginx-svc Server: 172.20.0.10 Address: 172.20.0.10#53 Name: nginx-svc.default.svc.cluster.local Address: 172.20.107.173
netshoot:~# curl -I 172.20.107.173 HTTP/1.1 200 OK Server: nginx/1.25.1 Date: Thu, 06 Jul 2023 19:54:01 GMT Content-Type: text/html Connection: keep-alive Expires: Thu, 06 Jul 2023 19:54:00 GMT Cache-Control: no-cache
클러스터 외부에서 접속하는 방법으로 NodePort, LoadBalancer 타입을 사용합니다.
노드포트 타입은 이름에서 유추할 수 있듯이 노드의 IP와 포트로 외부에서 접속할 수 있습니다. 노드포트 서비스 타입을 사용하면 클러스터의 모든 노드가 동일한 포트 번호로 서비스를 외부에 노출시킵니다. 외부 트래픽이 노드 포트로 들어오면, 쿠버네티스는 이 트래픽을 적절한 파드로 자동으로 라우팅합니다. 포트 번호는 30000-32767 중 하나의 포트를 사용합니다.
노드포트는 클러스터 내 모든 노드에서 동일한 포트로 접근할 수 있으므로, 하나의 노드가 실패하더라도 서비스 접근이 유지됩니다. 해당 트래픽은 쿠버네티스에 의해 자동으로 적절한 파드로 라우팅됩니다.
[service]$ k get svc ingress-nginx-controller NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx-controller NodePort 10.233.59.140 <none> 80:30080/TCP,443:30443/TCP 6d7h
현업에서 온프레미스 환경의 ingress-nginx 서비스를 위와 같이 노드포트 타입을 사용합니다. 위 예제는 30080, 30443 포트를 사용하였습니다.
LoadBalancer 서비스 타입은 클러스터 외부에서 쿠버네티스 서비스에 접근하기 위한 로드 밸런서를 자동으로 프로비저닝합니다. 이 서비스 타입은 클라우드 프로바이더가 제공하는 로드 밸런서 또는 온프레미스 환경에서 자체 생성한 로드밸런서(MetalLB 등)를 사용하여, 외부 트래픽을 클러스터 내 특정 서비스로 라우팅합니다. 현업에서는 로드밸런서 보다는 주로 Ingress를 사용합니다. 로드밸런서 타입은 L4 기반이라 URL, PATH를 구분하지 못하는 단점이 있습니다.
이상 이번 장에서는 쿠버네티스 네트워크에 대하여 알아보았습니다. 이어지는 다음 장에서 인그레스를 알아보겠습니다.
해당 기술 블로그에 질문이 있으시면 언제든지 문의해 주세요. 직접 답변해 드립니다.
k8sqna@jennifersoft.com
1.유사하게 스토리지를 담당하는 CSI(Container Storage Interface)도 있습니다.
2.일반적으로 쿠버네티스에서는 이러한 파일을 매니페스트(명세서)라고 합니다.
