Kubernetes Service

---

Ⅰ. Service (서비스)

Service (서비스)	구분	설명
	개념	Pod는 Controller에 의해 동적으로 생성되기 때문에 Pod의 IP가 바뀌어도 항상 동일한 방식으로 접근할 수 있게 해주는 네트워크 추상화 리소스
	역할	클러스터 내부 및 외부에서 Pod로의 안정적인 접근 가능
	필요성	Pod의 IP는 변경될 수 있어 직접 접근이 어렵기 때문에 Service가 고정 IP (ClusterIP)와 가상 포트를 제공하여 안정적인 통신 지원
	구성 원리	동일한 Label을 가진 Pod 그룹을 묶어 하나의 단일 엔드포인트로 접근 가능
		내부적으로 kube-proxy가 Pod IP와 Service IP를 매핑하여 트래픽 라우팅
	특징	클러스터 내부 및 외부 연결 모두 가능
		Service 생성 시 고정 IP 할당
		Service는 Pod가 재시작되어도 동일한 이름과 주소 유지
	Service 타입	타입	설명	접근 가능 범위
		ClusterIP (기본값)	클러스터 내부 전용 IP로 Pod에 접근 가능	내부 전용
		NodePort	각 노드의 포트를 통해 외부 접근 허용 (30000 ~ 32767 범위)	외부 접근 가능
		LoadBalancer	클라우드 환경에서 외부 로드밸런서를  생성하여 외부 트래픽 분산	외부 접근 가능
		ExternalName	외부 DNS 이름으로 트래픽 전달 (CNAME 역할)	외부 서비스 연동
	추천 구성	Deployment와 Service를 하나의 YAML 파일 (--- 구분)로 작성하여 함께 배포하는 것이 일반적
	동작 예시	클러스터 내부에서 ClusterIP를 통해 통신
		외부 접근 시 NodePort, LoadBalancer 사용
	명령어 예시	ex) bash kubectl expose deployment webserver --type=NodePort --port=80

 

---

Ⅰ - Ⅰ. Service Type별 구조도 및 동작 방식

타입	내부 구조 및 동작	주요 특징	사용 예시
ClusterIP (기본값)	클러스터 내부 전용 IP를 생성하여 Pod 그룹에 트래픽 라우팅	기본 Service 타입	마이크로서비스 간 내부 API 통신
		외부 접근 불가 (클러스터 내부 통신 전용)
		Pod IP 변경에도 동일한 Service IP로 접근 가능	내부 DB 접근
NodePort	각 노드의 고정 포트 (3000 ~ 32767)를 개방하여 외부에서 노드 IP + 포트로 접근 가능	ClusterIP 기반 위에 동작	로컬 환경 테스트용 외부 접근
		모든 노드의 동일한 포트로 접근 가능
		방화벽, 보안 그룹 설정 필요	온프레미스 서비스 노출
LoadBalancer	클라우드 공급자 (GCP, AWS 등)의 외부 로드밸런서를 자동으로 생성하여 NodePort로 트래픽 전달	NodePort + ClustserIP 구조 포함	클라우드 기반 웹 서비스 배포
		클라우드 기반 서비스에 적합	외부 유저 접근 서비스
		공인 IP 자동 할당
ExternalName	CNAME 형태로 외부 DNS 주소로 트래픽 전달	외부 DNS로 요청 리다이렉트	외부 API 또는 외부 DB 연동 (ex. mysql.example.com)
		실제 프록시 없이 DNS 레벨에서 동작

 

 

# testpod 리소스 생성 (Pod)

 

kubectl run testpod —image=nginx 명령을 통해 Nginx 이미지 사용하여 testpod 리소스 생성 및 실행

 

--port=80 옵션을 통해 testpod 리소스를 80번 포트에 매핑

 

kubectl get pod –o wide 명령을 통해 리소스가 잘 생성되었는지 확인

 

 

# testpod 리소스 삭제

 

kubectl delete pod testpod 명령을 통해 testpod 삭제

 

 

cd kubespray/inventory/mycluster/group_vars/k8s_cluster/ 명령을 통해

 

홈 디렉터리에서 k8s_cluster 디렉터리로 이동

 

ls –l 명령을 통해 해당 디렉터리 내 파일 목록 상세히 확인

 

 

ip address show kube-ipvs0 명령을 통해 Kubernetes 클러스터가 kube-proxy IPVS 모드로 작동 중일 때,

 

내부 가상 인터페이스인 kube-ipvs0의 IP 정보 확인

 

kubectl get svc –A 명령을 통해 클러스터 내 모든 네임스페이스의 Service 목록 조회

 

---

Ⅱ. ClusterIP

ClusterIP	구분	설명
	개념	동일한 Label을 갖는 Pod 그룹에 대해 단일 진입점 (가상 IP 주소, Virtual IP)을 제공하는 기본 Service 타입
	역할	클러스터 내부에서 Pod 간 통신을 안정적으로 수행할 수 있도록 고정된 내부 IP 주소 부여
	특징	Service의 기본 동작 방식 (별도 설정이 없을 경우, ClusterIP로 생성됨)
		클러스터 외부에서는 접근 불가 (내부 전용 통신용)
		IP 주소는 10.233.0.0 ~ 10.233.63.255 대역 내에서 자동 할당
	구조	kube-proxy가 IPVS 또는 iptables 규칙을 사용해 요청을 해당 Pod의 Endpoints로 라우팅
	장점	Pod IP 변경에도 안정적인 통신 유지
		서비스 디스커버리 (DNS 기반)와 함께 사용 시 효율적
	단점	외부 접근이 불가능하므로 외부 서비스 노출 시 NodePort나 LoadBalancer 필요
	명령어 예시	ex) bash kubectl expose deployment web --type=ClusterIP --port=80
	사용 예시	내부 마이크로서비스 간 통신 (ex. frontend가 backend API 호출 시)

 

 

cd kube/08/ 명령을 통해 홈 디렉터리에서 kube/08 디렉터리로 이동

 

ls 명령을 통해 해당 디렉터리 내 파일 목록 확인

 

cd clusterip/ 명령을 통해 kube/08 디렉터리에서 clusterip 디렉터리로 이동

 

kubectl api-resources 명령을 통해 쿠버네티스 클러스터 내에서 사용 가능한 리소스 타입 목록 확인

 

 

vi cluster-id.yml 명령을 통해 vi 편집기 사용하여 cluster-id.yml 파일 생성 및 내용 입력

 

cat cluster-id.yml 명령을 통해 cluster-id.yml 파일의 내용 확인

 

 

[ cluster-id.yml 파일의 내용 ]

 

apiVersion: v1 명령을 통해 리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해 리소스의 종류를 Service로 지정

 

metadata.name; nginx-clusterip 명령을 통해 리소스 이름을 nginx-clusterip로 설정

 

spec.selector.app: webui 명령을 통해 클러스터 내부 DNS로

 

nginx-clusterip.default.svc.cluster.local처럼 접근하도록 설정

 

spec.ports.protocol: TCP 명령을 통해  전송 프로토콜을 TCP로 지정

 

spec.ports.port: 80 명령을 통해  클러스터 내부에서 서비스가 노출되는 포드로 80번 포트 지정

 

spec.ports.targetPort: 80 명령을 통해  Service가 트래픽을 전달하는 대상 포트를 80번 포트로 지정

 

 

# nginx-clusterip 리소스 생성 (Service)

 

kubectl create –f cluster-id.yml 명령을 통해 cluster-id.yml 파일 사용하여 nginx-clusterip 리소스 생성

 

kubectl get svc –o wide 명령을 통해 현재 클러스터에 존재하는 Service 목록 확인

 

 

# cluster-id.yml 파일과 그와 관련된 리소스 등 모두 삭제

 

kubectl delete –f cluster-id.yml 명령을 통해 cluster-id.yml 파일과 그와 관련된 리소스 등 모두 삭제

 

 

# nginx-clusterip 리소스 생성 (Service)

 

kubectl create –f cluster-id.yml 명령을 통해 cluster-id.yml 파일 이용하여 nginx-clusterip 리소스 생성

 

kubectl get svc –o wide 명령을 통해 nginx-clusterip 리소스가 잘 생성되었는지 확인

 

kubectl describe svc nginx-clusterip 명령을 통해 nginx-clusterip 리소스 상세 정보 확인

 

 

# nginx-clusterip 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc nginx-clusterip 명령을 통해 nginx-clusterip와 그와 관련된 것 모두 삭제

 

kubectl get svc –o wide 명령을 통해 잘 삭제되었는지 확인

 

 

vi nginx-deploy.yml 명령을 통해 vi 편집기 사용하여 nginx-deploy.yml 파일 생성 및 내용 입력

 

cat nginx-deploy.yml 명령을 통해 입력한 파일 내용 확인

 

 

[ nginx-deploy.yml 파일의 내용 ]

 

apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 지정

 

kind: Deployment 명령을 통해 리소스 종류를 Deployment로 설정

 

metadata.name: nginx-deploy 명령을 통해  Deployment의 이름을 nginx-deploy로 설정

 

spec.replicas: 3 명령을 통해  Pod를 3개 복제해서 실행하도록 지정

 

spec.selector.matchLabels.app: webui 명령을 통해  app=webui 라벨을 가진 Pod를 관리하도록 설정

 

spec.template.metadata.name: nginx-pod 명령을 통해  Pod의 이름을 nginx-pod로 설정

 

spec.template.metadata.labels.app: webui 명령을 통해  Pod에 app=webui 라벨 부여

 

spec.spec.containers.name: nginx-container 명령을 통해  컨테이너 이름을 nginx-container로 지정

 

spec.spec.containers.image: nginx:1.14 명령을 통해  사용할 Docker 이미지를 Nginx 1.14로 지정

 

 

kubectl get pod –o wide 명령을 통해 현재 네임스페이스의 모든 파드를 자세히 확인

 

curl http://172.16.135.45 명령을 통해 master 노드에서

 

각 Pod 내부 IP에 직접 HTTP 요청을 보내 Nginx 페이지 확인

 

 

vi nginx-clusterip.yml 명령을 통해 vi 편집기 사용하여 nginx-clusterip.yml 파일 생성 및 내용 입력

 

cat nginx-clusterip.yml 명령을 통해 nginx-clusterip.yml 파일의 내용 확인

 

 

[ nginx-clusterip.yml 파일의 내용 ]

 

apiVersion: v1 명령을 통해  리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해  리소스의 종류를 Service로 지정

 

metadata.name; nginx-clusterip 명령을 통해 리소스 이름을 nginx-clusterip로 설정

 

spec.type: ClusterIP 명령을 통해  type을 ClusterIP로 설정

 

spec.clusterIP: 10.233.10.10 명령을 통해  ClusterIP를 10.233.10.10로 설정

 

spec.selector.app: webui 명령을 통해 클러스터 내부 DNS로

 

nginx-clusterip.default.svc.cluster.local처럼 접근하도록 설정

 

spec.ports.protocol: TCP 명령을 통해  전송 프로토콜을 TCP로 지정

 

spec.ports.port: 80 명령을 통해  클러스터 내부에서 서비스가 노출되는 포드로 80번 포트 지정

 

spec.ports.targetPort: 80 명령을 통해  Service가 트래픽을 전달하는 대상 포트를 80번 포트로 지정

 

 

kubectl get pod —show-labels 명령을 통해 파드 목록을 라벨까지 출력하여

 

Deployment와 Service의 Selector 매칭 관계 확인

 

kubectl get svc,pod,ep –o wide 명령을 통해 Service, Pod, Endpoint의 상세 정보 확인

 

 

kubectl describe svc nginx-clusterip 명령을 통해 nginx-clusterip 리소스의 상세 정보 확인

 

 

# nginx-deploy 리소스 개수 확장

 

kubectl scale deployment nginx-deploy —replicas 5 명령을 통해 리소스의 개수를 3개에서 5개로 확장

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 확장되었는지 확인

 

 

# nginx-deploy 리소스 개수 축소

 

kubectl scale deployment nginx-deploy —replicas 3 명령을 통해 리소스의 개수를 5개에서 3개로 축소

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 축소되었는지 확인

 

 

# nginx-clusterip 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc nginx-clusterip 명령을 통해 nginx-clusterip 리소스와 그와 관련된 것 함께 삭제

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 삭제되었는지 확인

---

Ⅲ. NodePort

NodePort	구분	설명
	개념	Kubernetes Service의 한 종류
		모든 노드에 동일한 외부 접근 포트 (NodePort)를 예약하여 클러스터 외부에서 접근할 수 있게 해주는 서비스
	역할	클러스터 외부 클라이언트가 노드의 IP와 NodePort 번호를 이용해 Pod에 직접 접근할 수 있도록 연결 경로 제공
	특징	ClusterIP 기반으로 동작
		내부 통신은 ClusterIP를 통해 유지
		외부에서는 노드 IP : NodePort 형식으로 접근 가능
		모든 노드에서 동일한 포트를 개방하여 트래픽 분산 처리
		외부 요청은 kube-proxy가 적절한 Pod로 라우팅
	기본 포트 범위	30000 ~ 32767 (kube-apiserver 설정에서 변경 가능)
	포트 할당 시점	ClustserIP가 생성된 이후 자동으로 NodePort가 할당됨
	장점	별도 로드밸런서 없이 외부 접근 가능
		개발 및 테스트 환경에서 유용
		클라우드 외 환경 (On-premise)에서도 사용 가능
	단점	포트 중복 방지 필요
		고정 포트 범위로 인해 보안상 노출 가능성
		대규모 트래픽 분산에는 부적합
	사용 예시	내부 테스트용 웹서버 노출
		개발 환경에서의 Pod 직접 접근 확인
	명령어 예시	ex) bash kubectl expose deployment webserver --type=NodePort --port=80
	접근 예시	ex) bash curl http://<Node_IP> : <할당된_NodePort>

 

 

cd ../nodeport/ 명령을 통해 clusterip 디렉터리에서 nodeport 디렉터리로 이동

 

vi nginx-nodeport.yml 명령을 통해 vi 편집기 사용하여 nginx-nodeport.yml 파일 생성 및 내용 입력

 

cat nginx-nodeport.yml 명령을 통해 nginx-nodeport.yml 파일의 내용 확인

 

 

[ nginx-nodeport.yml 파일의 내용 ]

 

apiVersion: v1 명령을 통해 리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해  리소스의 종류를 Service로 지정

 

metadata.name; nginx-nodeport 명령을 통해 리소스 이름을 nginx-nodeport로 설정

 

spec.type: NodePort 명령을 통해  type을 NodePort로 설정

 

spec.clusterIP: 10.96.13.200 명령을 통해  ClusterIP를 10.96.13.200으로 설정

 

spec.selector.app: webui 명령을 통해 클러스터 내부 DNS로

 

nginx-clusterip.default.svc.cluster.local처럼 접근하도록 설정

 

spec.ports.protocol: TCP 명령을 통해  전송 프로토콜을 TCP로 지정

 

spec.ports.port: 80 명령을 통해  클러스터 내부에서 서비스가 노출되는 포드로 80번 포트 지정

 

spec.ports.targetPort: 80 명령을 통해  Service가 트래픽을 전달하는 대상 포트를 80번 포트로 지정

 

spec.ports.nodePort: 32080 명령을 통해  클러스터 외부에서도 접근 가능한 nodeport를 32080번으로 지정

 

 

# nginx-nodeport 리소스 생성 (Service)

 

kubectl create –f nginx-nodeport.yml 명령을 통해 

 

nginx-nodeport.yml 파일 이용하여 nginx-nodeport 리소스 생성

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 생성되었는지 확인

 

 

nmap –p 30200 IP address 명령을 통해 NodePort 포트가 실제로 열려 있는지 확인

 

 

# nginx-nodeport 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc nginx-nodeport 명령을 통해 nginx-nodeport 리소스와 그와 관련된 것 모두 삭제

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 삭제되었는지 확인

---

 

Ⅳ. LoadBalancer

LoadBalancer	구분	설명
	개념	클라우드 환경 (AWS, Azure, GCP 등)에서 외부 로드 밸런서를 자동 생성하여 트래픽을 분산 처리하고, 서비스를 외부에 노출시키는 Kubernetes 서비스 타입
	역할	클러스터 외부에서 접근 가능한 공인 IP (Public IP)를 자동 할당
		외부 요청을 LoadBalancer -> NodePort -> ClusterIP -> Pod 순으로 전달
		사용자는 클라우드 로드밸런서를 통해 외부 트래픽을 안정적으로 수신
	특징	NodePort, ClusterIP 서비스를 자동으로 함께 생성
		클라우드 공급자의 인프라와 연동되어 로드밸런서를 자동 프로비저닝 ( 프로비저닝 = 사용자가 요청한 IT 자원을 사용할 수 있는 상태로 준비하는 것)
		온프레미스 환경에서는 직접 설정 (ex. MetalLB 등) 필요
		외부 트래픽을 내부 Pod로 안전하게 분산
	지원 환경	퍼블릭 클라우드 (AWS ELB, Azure Load Balancer, GCP Load Balancing 등) 온프레미스 환경에서는 MetalLB, OpenELB 등 별도 구성 필요
	접근 방식	클라우드가 할당한 외부 IP 주소로 접근 가능
		ex) http://<External-IP> : <Port>
	장점	외부에서 직접 접근 가능한 공인 IP 제공
		트래픽 부하 분산 및 자동 Failover 지원
		서비스 안정성, 확장성 우수
	단점	클라우드 의존적 (온프레미스 환경에서는 기본 미지원)
		사용 시 비용 발생 (클라우드 로드밸런서 과금)
	명령어 예시	ex)bash kubectl expose deployment webapp -type=LoadBalancer --port=80 --target-port=8080
	사용 예시	클라우드 환경에서 외부 사용자에게 공개되는 웹 서비스 배포 (ex. 프론트엔드 서비스)

 

 

 

cd ../loadbalancer/ 명령을 통해 nodeport 디렉터리에서 loadbalancer 디렉터리로 이동

 

vi nginx-loadbalancer.yml 명령을 통해 vi 편집기 사용하여 nginx-loadbalancer.yml 파일 생성 및 내용 입력

 

cat nginx-loadbalancer.yml 명령을 통해 nginx-loadbalancer.yml 파일의 내용 확인

 

 

[ nginx-loadbalancer.yml 파일의 내용 ]

 

apiVersion: v1 명령을 통해 리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해  리소스의 종류를 Service로 지정

 

metadata.name: nginx-loadbalancer 명령을 통해 리소스 이름을 nginx-loadbalancer로 설정

 

spec.type: LoadBalancer 명령을 통해  type을 LoadBalancer로 설정

 

spec.clusterIP: 10.96.13.200 명령을 통해  ClusterIP를 10.96.13.200으로 설정

 

spec.selector.app: webui 명령을 통해 클러스터 내부 DNS로

 

nginx-clusterip.default.svc.cluster.local처럼 접근하도록 설정

 

spec.ports.protocol: TCP 명령을 통해  전송 프로토콜을 TCP로 지정

 

spec.ports.port: 80 명령을 통해  클러스터 내부에서 서비스가 노출되는 포드로 80번 포트 지정

 

spec.ports.targetPort: 80 명령을 통해  Service가 트래픽을 전달하는 대상 포트를 80번 포트로 지정

 

spec.ports.nodePort: 30000 명령을 통해  클러스터 외부에서도 접근 가능한 nodeport를 30000번으로 지정

 

 

# nginx-loadbalancer 리소스 생성 (Service)

 

kubectl create –f nginx-loadbalancer.yml 명령을 통해

 

nginx-loadbalancer.yml 파일 이용하여 nginx-loadbalancer 리소스 생성

 

kubectl get svc,pod,ep –o wide 명령을 통해 리소스가 잘 생성되었는지 확인

 

 

# nginx-loadbalancer 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc nginx-loadbalancer 명령을 통해 nginx-loadbalancer 리소스와 그와 관련된 것 모두 삭제

 

 

# nginx-deploy 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete deployments.apps nginx-deploy 명령을 통해 nginx-deploy 리소스와 그와 관련된 것 모두 삭제

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 삭제되었는지 확인

---

Ⅴ. ExternalName

ExternalName	구분	설명
	개념	클러스터 내부 Pod가 외부 도메인으로 접근할 수 있도록 내부 DNS를 CNAME 레코드로 매핑해주는 Kubernetes 서비스 타입
	역할	내부 DNS 질의 시 외부 도메인으로 직접 리다이렉트
		외부 API, 외부 DB, 외부 SaaS와의 연동 시 유용
	특징	spec.externalName 필드에 외부 FQDN (Fully Qualified Domain Name) 지정
		ClusterIP 생성하지 않음 (네트워크 프록시 없이 DNS 수준에서만 동작)
		내부 DNS 서버 (CoreDNS)가 CNAME 레코드로 변환하여 반환
	작동 방식	내부 Pod에서 ExternalName 서비스 이름으로 접근
		DNS 조회 시 CoreDNS가 CNAME 응답 반환
		외부 도메인으로 요청 전달
	접근 방식	Pod 내부에서 nslookup external-google.default.svc.cluster.local 실행 시 www.google.com으로  CNAME 리턴
	장점	외부 서비스를 Kubernetes 내부 DNS 체계에 통합 가능
		네트워크 프록시나 LoadBalancer 불필요
		간단한 설정으로 외부 자원 연결 가능
	단점	트래픽 제어 및 로드밸런싱 불가능 (단순 DNS 매핑 기능)
		보안 제어나 TLS 인증 처리 불가
		외부 서비스의 가용성에 직접 의존
	사용 예시	클러스터 내부 애플리케이션이 외부 DB (rds.amazonaws.com)나 API (api.naver.com)에 접근할 때 사용

 

 

cd ../externalname/ 명령을 통해 loadbalancer 디렉터리에서 externalname 디렉터리로 이동

 

vi externalname-svc.yml 명령을 통해 vi 편집기 사용하여 externalname-svc.yml 파일 생성 및 내용 입력

 

cat externalname-svc.yml 명령을 통해 externalname-svc.yml 파일의 내용 확인

 

 

[ externalname-svc.yml 파일의 내용 ]

 

apiVersion: v1 명령을 통해 리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해  리소스의 종류를 Service로 지정

 

metadata.name: externalname-svc 명령을 통해 리소스 이름을 externalname-svc로 설정

 

spec.type: ExternalName 명령을 통해  type을 ExternalName으로 설정

 

spec.externalName: www.google.com 명령을 통해  externalName을 www.google.com으로 설정

 

 

# externalname-svc 리소스 생성 (Service)

 

kubectl create –f externalname-svc.yml 명령을 통해

 

externalname-svc.yml 파일 사용하여 externalname-svc 리소스 생성

 

kubectl get svc –o wide 명령을 통해 리소스가 잘 생성되었는지 확인

 

 

# externalname-svc.yml 파일과 그와 관련된 것 모두 삭제

 

kubectl delete –f externalname-svc.yml 명령을 통해 externalname-svc.yml 파일과 그와 관련된 것 모두 삭제

 

 

# externalname-svc 리소스와 그와 관련된 것 모두 삭제

 

rm –rf externalname-svc 명령을 통해 externalname-svc 리소스와 그와 관련된 것 모두 삭제

 

 

# externalname-svc 리소스 생성 (Service)

 

kubectl create -f externalname-svc.yml 명령을 통해

 

externalname-svc.yml 파일 사용하여 externalname-svc 리소스 생성

 

 

# testspod 리소스 생성 및 실행하여 컨테이너 내부 동작 (Pod)

 

kubectl run testpod --image=ubuntu 명령을 통해 Ubuntu 이미지 사용하여 testpod Pod 리소스 생성

 

-it 옵션을 통해 생성된 testpod 리소스 내부 내부 컨테이너의 터미널에 바로 접속하도록 설정

 

apt update 명령을 통해 패키지 목록 최신 상태로 갱신

 

 

apt –y install bind9-dnsutils iputils-ping 명령을 통해

 

컨테이너 안에서 네트워크와 DNS 모두 테스트할 수 있도록 도구 추가

 

nslookup externalname-svc.default.svc.cluster.local 명령을 통해 externalname-svc의 IP 주소 확인

 

 

dig externalname-svc.default.svc.cluster.local 명령을 통해

 

externalname-svc.default.svc.cluster.local의 실제 IP 주소 확인

 

ping -c 3 externalname-svc.default.svc.cluster.local 명령을 통해 외부 인터넷과 연결되었는지 확인

 

cat /etc/resolv.conf 명령을 통해 Pod 내부의 DNS 설정 파일의 내용 확인

 

exit 명령을 통해  testpod 리소스 내부 컨테이너의 터미널에서 나옴

 

 

kubectl get pod -n kube-system –o wide 명령을 통해 쿠버네티스의 모든 내부 시스템 Pod들을 자세히 확인

 

 

# externalname-svc 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc externalname-svc 명령을 통해 externalname-svc 리소스와 그와 관련된 것 모두 삭제

 

kubectl get svc –o wide 명령을 통해 잘 삭제되었는지 확인

---

Ⅵ. Headless

Headless	구분	설명
	개념	clusterIP : None으로 생성하는 Headless 서비스
		Service 자체의 가상 IP (ClusterIP)를 만들지 않고, Pod들의 Endpoint를 DNS로 직접 노출
	동작	kube-proxy의 L4 로드 밸런싱 거치지 않음
		CoreDNS가 Pod 개별 IP (A 레코드) 또는 SRV 레코드를 그대로 응답
	용도	단일 진입점이 필요 없고, 클라이언트 측 로드밸런싱 / 서비스 디스커버리가 필요한 경우 사용 (ex. StatefulSet DB, Kafka, Cassandra)
	장점	Pod의 실제 IP를 직접 해석하므로 Peer-to-Peer, 리더 선출, 샤딩 등에 유리
	주의	Service VIP가 없으므로 NetworkPolicy와 LB 규칙은 Pod / Endpoint 기준으로 설계
		포트 이름을 지정하면 SRV 레코드 생성
	설정 요약	Service 스펙에 spec.clusterIP : None 지정

 

---

Ⅵ - Ⅰ. headless-svc.default.svc.cluster.local 도메인

headless-svc.default. svc.cluster.local 도메인	구분	설명
	개념	네임스페이스 default의 headless-svc 이름 질의
	DNS 응답	여러 개의 A 레코드 (연결된 각 Pod의 IP 목록) 또는 SRV 레코드 (포트 이름 사용 시) 반환
	특징	단일 진입점 없이 클라이언트가 받은 IP 리스트로 직접 선택, 헬스 체크, 리트라이 수행
	사용 예시	애플리케이션 라운드로빈 탐색
		gRPC 클라이언트 LB 탐색
		데이터베이스 클러스터 멤버 탐색

 

---

Ⅵ - Ⅱ. pod-ip-addr.namespace.pod.cluster.local 도메인

pod-ip-addr.namespace. pod.cluster.local 도메인	구분	설명
	개념	특정 Pod 한 개에 대한 정규화된 DNS 이름 (ex. a-b-c-d.default.pod.cluster.local (IP a.b.c.d))
	DNS 응답	해당 Pod 1개의 A 레코드 (단일 IP) 반환
	특징	StatefulSet처럼 고정 호스트명, 순서가 있는 워크로드에서 개별 Pod에 직접 연결할 때 사용
	사용 예시	mysql-0.mysql.default.svc.cluster.local처럼 멤버별 접속, 리더 / 팔로워 직접 지정

 

 

cd ../headless/ 명령을 통해 externalname 디렉터리에서 headless 디렉터리로 이동

 

vi headless-svc,yml 명령을 통해 vi 편집기 사용하여 headless-svc.yml 파일 생성 및 내용 입력

 

cat headless-svc.yml 명령을 통해 headless-svc.yml 파일의 내용 확인

 

 

[ headless-svc.yml 파일의 내용 ]

 

apiVersion: apps/v1 명령을 통해  API apps/v1 버전 사용하도록 설정

 

kind: Deployment 명령을 통해  리소스 종류를 Deployment로 설정

 

metadata.name: nginx-deploy 명령을 통해  Deployment의 이름을 nginx-deploy로 설정

 

spec.replicas: 3 명령을 통해  Pod를 3개 복제해서 실행하도록 지정

 

spec.selector.matchLabels.app: webui 명령을 통해  app=webui 라벨을 가진 Pod를 관리하도록 설정

 

spec.template.metadata.labels.app: webui 명령을 통해  Pod에 app=webui 라벨 부여

 

spec.spec.containers.name: nginx-container 명령을 통해  컨테이너 이름을 nginx-container로 지정

 

spec.spec.containers.image: nginx:1.14 명령을 통해  사용할 Docker 이미지를 Nginx 1.14로 지정

 

----

 

apiVersion: v1 명령을 통해  리소스 API 버전을 v1로 설정

 

kind: Service 명령을 통해  리소스의 종류를 Service로 지정

 

metadata.name: headless-svc 명령을 통해 리소스 이름을 headless-svc로 설정

 

spec.type: ClusterIP 명령을 통해  type을 ClusterIP로 설정

 

spec.clusterIP: None 명령을 통해 ClusterIP를 None으로 설정

 

spec.selector.app: webui 명령을 통해 클러스터 내부 DNS로

 

nginx-clusterip.default.svc.cluster.local처럼 접근하도록 설정

 

spec.ports.protocol: TCP – 전송 프로토콜을 TCP로 지정

 

spec.ports.port: 80 명령을 통해  클러스터 내부에서 서비스가 노출되는 포드로 80번 포트 지정

 

spec.ports.targetPort: 80 명령을 통해  Service가 트래픽을 전달하는 대상 포트를 80번 포트로 지정

 

 

# headless-svc 리소스 생성 (Service)

 

kubectl create –f headless-svc.yml 명령을 통해 headless-svc.yml 파일 사용하여 headless-svc 리소스 생성

 

kubectl get svc,pod,ep –o wide 명령을 통해 리소스가 잘 생성되었는지 확인

 

kubectl describe svc headless-svc 명령을 통해 headless-svc 리소스의 상세 정보 확인

 

 

kubectl get pod 명령을 통해 Pod의 상세 정보 확인

 

 

# testpod 리소스 내부 컨테이너 동작 (Pod)

 

kubectl exec testpod 명령을 통해 testpod 리소스 내부 진입

 

-it --/bin/bash 옵션을 통해 testpod 리소스 내부 컨테이너 bash 쉘 실행하도록 설정

 

cat /etc/resolv.conf 명령을 통해 /etc/resolv.conf 파일의 내용 확인

 

apt update 명령을 통해 패키지 목록 최신 상태로 갱신

 

exit 명령을 통해 testpod 리소스 내부 컨테이너 bash 쉘에서 나옴

 

 

# testpod 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete pod testpod 명령을 통해 testpod 리소스와 그와 관련된 것 모두 삭제

 

 

# testpod 리소스 생성 및 실행하여 리소스 내부 컨테이너 동작 (Pod)

 

kubectl run testpod --image=ubuntu 명령을 통해 Ubuntu 이미지 사용하여 testpod 리소스 생성

 

-it 옵션을 통해 생성된 testpod 리소스 내부 컨테이너의 터미널에 바로 접속하도록 설정

 

->  클러스터 내부 DNS가 정상 동작하는지 테스트

 

apt update 명령을 통해 패키지 목록 최신 상태로 갱신

 

 

apt –y install bind9-dnsutils iputils-ping 명령을 통해 컨테이너 안에서

 

네트워크와 DNS 모두 테스트할 수 있도록 도구 추가

 

 

cat /etc/resolv.conf 명령을 통해 Pod 내부의 DNS 설정 파일의 내용 확인

 

dig headless-svc.default.svc.cluster.local 명령을 통해

 

dig headless-svc.default.svc.cluster.local의 실제 IP 주소 확인

 

exit 명령을 통해 testpod 리소스 내부 컨테이너의 터미널에서 나옴

 

 

# testpod 리소스 삭제

 

kubectl delete pod testpod —force 명령을 통해 testpod 리소스 강제 삭제

 

 

# nginx-deploy 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete deployments.apps nginx-deploy 명령을 통해 nginx-deploy 리소스와 그와 관련된 것 모두 삭제

 

 

# headless-svc 리소스와 그와 관련된 것 모두 삭제

 

kubectl delete svc headless-svc 명령을 통해 headless-svc 리소스와 그와 관련된 것 모두 삭제

 

kubectl get svc,pod,ep –o wide 명령을 통해 잘 삭제되었는지 확인