진취적 삶
06 쿠버네티스 네트워킹 본문
쿠버네티스의 네트워크를 담당하는 Service 리소스에 대해서 알아보자.
Service 리소스는 Pod IP 와는 또 다른 독자적인 IP를 부여받아 서비스의 끝점을 제공하여
라벨링 시스템을 통해 Pod로 부터 트래픽을 전달한다.
6.1 Service 소개
k8s 는 Pod 자체에도 IP가 부여된다.
6.1.1 불안정한 Pod vs 안정적인 service
k8s 에서는 Pod 리소스를 불안정한 자원으로 여긴다.
Pod는 쉽게 생성했다가 쉽게 삭제 가능
Pod의 생명주기와는 상관없이 안정적인 서비스 endpoint를 제공하는 service라는 리소스가 등장
리버스 프록시 : 클라이언트 서버 구조에서 서버로 전송되는 요청을 대신 받아 원래의 서버로 전달해주는 대리 서버를 의미한다.
6.1.2 서비스 탐색
myservice 라는 이름의 Service 리소스를 생성하면 사용자는 myservice라는 도메인 주소로 해당 Service에 요청할수 있다.
6.1.3 Service
apiVersion: v1
kind: Service
metadata:
labels:
hello: world
name: myservice
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 80
selector:
runt: mynginx
spec :Service 의 포트들을 정의
- port : Service 로 들어오는 포트 지정
- protocol: 사용하는 프로토콜을 지정 TCP, UDP ,HTTP 등이 있다 .
selector: 트래픽을 전달한 컨테이너의 라벨 선택
라벨 설렉터를 이용하여 Pod 선택
service 에서 pod의 이름이나 ip를 직접참조하게 되면 Pod의 생명주기에 따라 사용자가 매번 새로운Pod 정보를 service에 등록 및 삭제해야 한다.
라벨링 시스템으로 통해 느슨한 관계 유지
6.1.4
Service 도메인 주소 법칙
<서비스 이름>.<네임스페이스>.svc.cluster.local
- <서비스 이름>.<네임스페이스> == <서비스 이름>.<네임스페이스>.svc.cluster.local
- <서비스 이름> ==<서비스 이름>.<네임스페이스>.svc.cluster.local
sudo kubectl exec client -- nslookup myservice.default.svc.cluster.local
전체 도메인 주소 조회
sudo kubectl exec client -- nslookup myservice
이것도 같음
6.1.5 클러스터 DNS 서버
Kube-dns 의 라는 service 가 10.43.0.10 주인
sudo kubectl get svc kube-dns -n kube-system --show-labels
라벨 확인
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE LABELS
kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 5d21h k8s-app=kube-dns,kubernetes.io/cluster-service=true,kubernetes.io/name=CoreDNS,objectset.rio.cattle.io/hash=bce283298811743a0386ab510f2f67ef74240c57
k8s-app=kube-dns
해당 라벨로 필터링
sudo kubectl get pod -n kube-system -l k8s-app=kube-dns
coredns 발견
coredns : k8s 에서 제공하는 클러스터 dns 서버
6.2 Service 종류
6.2.1 ClusterIP
ClusterIp : service 리소스의 가장 기본이 되는 타입
클러스터 내에 존재하는 Pod에서만 clusterIP 타입의 Service로 접근이 가능 클러스터 외부에서는 접근할수 없다.
외부에서 접근하지 못하는 이유
- 네트워크 보안을 위해 한 두개의 서비스 끝점 외에는 직접 트래픽을 전달받는 경우가 드물다. 대신 외부로 열린 서비스 끝점으로부터 트래픽을 전달받아 서비스 제공
- clusterIp 타입은 확장된 k8s 네트워킹을 위한 기본 빌딩 블럭으로 사용된다.
sudo kubectl run cluster-ip --image nginx --expose --port 80 \\
> --dry-run=client -o yaml > cluster-ip.yaml
piVersion: v1
kind: Service
metadata:
creationTimestamp: null
name: cluster-ip
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: cluster-ip
status:
loadBalancer: {}
---
---
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: cluster-ip
name: cluster-ip
spec:
containers:
- image: nginx
name: cluster-ip
ports:
- containerPort: 80
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
해당 코드 생성
sudo kubectl get svc cluster-ip -oyaml | grep type
type: ClusterIP
ClusterIP 타입의 Service 는 k8s 클러스터 내부에 안정적인 서비스 끝점을 제공하고 도메인 주소를 통해 Pod로 트래픽을 전달할수 있는 매커니즘을 제공한다.
6.2.2 NodePort
ClusterIP 타입으로는 외부 트래픽을 클러스 내로 전달하지 못한다.
NodePort는 로컬 호스트의 특정 포트를 Service의 특정 포트와 연결시켜 외부 트래픽을 Service까지 전달한다.
k8s 에서 제공하는 NodePort 는 30000-32767 이다
apiVersion: v1
kind: Service
metadata:
name: node-port
spec:
type: NodePort
ports:
- port: 8080
protocol: TCP
targetPort: 80
nodePort: 30080
selector:
run: mynginx
---
apiVersion: v1
kind: Pod
metadata:
labels:
run: node-port
name: node-port
k8s는 클러스터 시스템이기 때문에 특정 노드에서만 서비스가 동작하지 않고 모든 노드에 동일하게 적용된다.
kube-proxy 덕분에 가능
kube-proxy는 리눅스 커널의 netfilter 를 이용하여 리눅스 커널 레벨에서 특정 트래픽을 중간에서 가로채 다른곳으로 라우팅 해주는 역할을 수행한다.
6.2.3 LoadBalancer
k8s 에서는 로드밸런스를 지원한다.
- 보안적인 측면으로 호스트 서버의 노드포트 대역을 직접 외부에 공개할 필요 없이 서버를 내부 네트워크에 두고 로드밸런서만 외부 네트워크에 위치해서 보안성 높힐수 있다.
- 로드밸런서가 클러스터 앞단에 존재하면 사용자가 각각의 서버 IP를 직접 알 필요 없이 로드밸런서의 IP 또는 도메인 주소만 가지고 요청을 보낼수 있다.
ClusterIP 타입 서비스가 Pod 레벨에서의 안정적인 서비스 끝점을 제공한다면
로드벨런서 타입 서비스는 노드 레벨에서의 안정적인 서비스 끝점을 제공한다.
suha@suhamaster:~$ sudo kubectl get svc load-bal
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
load-bal LoadBalancer 10.43.104.77 192.168.247.128 8080:30088/TCP 2m2s
로드밸런서 타입의 Service를 생성하면 EXTERNAL-IP에 로드밸런서의 IP가 설정된다.
6.2.4 ExternalName
외부 DNS 주소에 클러스터 내부에서 사용할 새로운 별칭을 만든다.
# external.yaml
apiVersion: v1
kind: Service
metadata:
name: google-svc # 별칭
spec:
type: ExternalName
externalName: google.com # 외부 DNS
6.3 네트워크 모델
- 각 Node 간 NAT 없이 통신이 가능해야 한다.
- 각 Pod 간 NAT 없이 통신이 가능해야 한다.
- Node 와 Pod 간 NAT 없이 통신이 가능해야 한다.
- 각 Pod는 고유의 IP를 부여받는다.
- 각 Pod IP 네트워크 제공자를 통해 할당 받는다.
- Pod IP는 클러스터 내부 어디서든 접근이 가능해야 한다.
K8S에서는 컨테이너의 네트워크 환경을 노드 레벨의 네트워크 한경과 분리하여 고립도를 높이려 했고 결과적으로 Pod 라는 독립적인 네트워크 환경을 구성하는 리소스를 만들게 되었다.
k8s 의 네트워크 모델
- 모든 리소스(Node,Pod)가 다른 모드 리소스(Node,Pod,Service)를 고유의 IP로 접근할수 있다
- NAT 통신으로 인한 부작용데 대해 신경 쓸 필요가 없다.
- 새로운 프로토콜을 재정의할 필요없이 기존의 TCP ,UDP ,IP 프로토콜대로 이용할수 있다.
- Pod 끼리의 네트워킹이 어느 노드에서든지 동일하게 동작한다.
'개발 도서 > 핵심만 콕 쿠버네티스' 카테고리의 다른 글
08 helm 패키지 매니저 (0) | 2023.11.17 |
---|---|
07 쿠버네티스 컨트롤러 (0) | 2023.11.17 |
05 Pod (0) | 2023.11.17 |
04 쿠버네티스 첫 만남 (0) | 2023.11.17 |
03 쿠버네티스 설치 (0) | 2023.11.17 |