Kubernetes Network 이론
Kubernetes Network 관련 글 이동
1. Kuberentes Network 이론
2. Kubernetes Network (ClusterIP, NodePort)
3. Kubernetes Network (LoadBalancer)
4. Kubernetes Network (Ingress)
이번 글은 Kubernetes의 Network 위주로
Pod 간의 Network 통신 구조와 Service Object가 왜 필요한지에 대해서 설명드리겠습니다.
1. Pod Network 구조
Pod는 기본적으로 Docker의 네트워크를 그대로 사용합니다.
Kubernetes는 docker 와는 다르게 Pod 단위로 Container를 관리하여
Pod 내의 Container 들은 같은 IP주소를 사용하고 있습니다.
그래서 Kubernetes의 Pod 내부의 Container 간 네트워크 통신은 localhost로 이루어집니다.
상위 그림에서 보이는 Pause Container 가 있어서 이와 같이 Container 간 동일한 IP를 사용할 수 있습니다.
아래의 그림을 보면 생성된 Pod의 수만큼 모두 Pause Container 가 존재하고 있는 것을 확인할 수 있습니다.
실제로 veth0는 Pause Container와 연결되어 있고
사용자가 생성한 Container 들의 네트워크는 Pause Container를 바라보고 있습니다.
하지만 이와 같은 Pod의 네트워크 구조에는 문제가 하나 있습니다.
상위 그림과 같이 Worker Node 가 2개 생성될 시
Pod에 부여되는 IP주소가 동일하여
Worker Node 1의 Pod에서 Worker Node 2 Pod로 통신을 할 시 IP가 같아서 문제 발생합니다.
즉 다른 Worker Node에 있는 Pod 간의 네트워크 통신에 문제가 생깁니다.
2. Worker Node 간의 Pod 통신을 위해 CNI 사용
kubernetes에서는 다른 Worker Node의 Pod 간 통신 문제점을 해결하기 위해
Kubernetes Addon 중 CNI를 사용합니다.
대표적으로 사용되는 CNI는 flannel 이 있습니다.
flannel을 사용하면 상위 그림과 같이 다른 Worker Node 간 Pod의 IP가 동일하지 않아서
라우터를 거쳐서 Pod 간 통신이 가능해집니다.
flannel CNI를 설치 후 ifconfig 확인 시
아래와 같이 flannel과 cni0 장치가 추가됨을 확인할 수 있습니다.
Pod의 Ip를 확인해 보면 더 이상 Docker의 네트워크를 사용하지 않고
Flannel 장치를 사용해서 Ip가 할당되는 것을 확인할 수 있습니다.
CNI 란?
CNI (Container Network Interface)
보통 Pod는 여러 노드에 걸쳐서 배포되는데 pod는 서로 하나의 네트워크에 있는 것처럼 통신이 가능.
이러한 기능을 지원하는 것이 CNI
Flannel 이란?
서로 다른 노드에 있는 pod 간 통신을 완성하기 위해서는 관련 기능을 제공하는 network-plugin이 필요함.
Flannel 은 대표적인 CNI 종류 중 하나.
하지만 이 또한 문제점이 있습니다.
Kubernetes에서 pod는 영구적인 것이 아니고 계속해서 재생성이 되는 특징을 가지고 있어서
IP가 굉장히 유동적입니다.
그래서 IP를 명시해서 통신하는 것은 실무적인 Kubernetes 환경에서는 거의 의미가 없고 불가능합니다.
3. Service Object 가 필요한 이유
상위의 IP를 명시해서 통신할 때 생기는 문제점을 해결하기 위해 도입된 개념이 바로 Service Object입니다.
위 그림과 같이 Kubernetes에서는 다양한 Object를 제공하고 있는데
Service Object는 Kubernetes의 Network 부분을 담당하는 Object로
Network를 구성하는데 필요한 다양한 type을 가지고 있습니다.
그중 대표적으로 가장 많이 사용되는 ClusterIP, NodePort, LoadBalancer 3가지 Type을
그림으로 상세히 설명드리겠습니다.
나아가 실무 환경에서 가장 많이 사용하는 네트워크 Addon인 Ingress까지 설명드리겠습니다.
4. Service Object 개념과 Type
그림을 통해 순서대로 설명드리겠습니다.
먼저 그림과 같이 192.168.0번 대역대의 내부망이 형성되어 있고
관리자는 해당 내부망에 kubernetes를 구성하기 위해 총 3대의 서버를 놓았습니다.
해당 3대의 서버에 1개의 master node, 2개의 worker node로 구성해서
Kubernetes 설치를 완료하면
다음과 같이 Kubernetes Cluster 가 형성될 것입니다.
그리고 해당 Cluster에 설명드렸던 Flannel CNI Addon 이 설치되어있는 상태입니다.
구성된 cluster에 pod 가 생성되면 20 대역대, service 가 생성되면 10 대역대로 생성된다고 가정하겠습니다.
해당 cluster에 WAS pod, DB pod를 생성하면
서로 각자의 IP를 통해 통신이 가능하긴 합니다.
하지만 둘 중 하나의 Pod 라도 재생성되면 IP가 변경되어 연결이 끊깁니다.
다시 연결을 하기 위해서는 Pod를 재생성할 때마다 IP 설정을 변경해줘야 하는 문제가 있습니다.
해당 문제점을 해결하기 위해 사용되는 것이
바로 service object의 cluster type입니다.
WAS Pod와 연결된 Service가 생성되어있고
DB Pod와 연결된 Service가 생성되어있으면
Pod 간의 IP를 확인하여 pod와 pod 가 통신할 필요 없이
ClusterIP Service를 통하여 통신하게 돼서
Pod 재생성 상관없이 통신할 수 있게 됩니다.
일종의 proxy 서버 역할을 수행한다고 이해하시면 될 것 같습니다.
여기서 발생할 수 있는 또 하나의 문제점은 Service object의 IP를 확인하여 통신하게 된다면
통신하던 중 Service 가 재생성되면 Service 또한 IP가 변경되는 문제가 발생할 수 있습니다.
이 문제를 해결하기 위해 Kubernetes는
Service 가 재생성될 시 IP가 변경되어도 문제없이 통신이 가능하도록
자체 Service Object Domain을 제공합니다.
서비스 object의 이름과 네임스페이스의 이름 그리고 뒤의 고정 값을 사용하여 Domain을 구성하게 되어
해당 domain으로 통신을 하여 문제를 해결했습니다.
이러한 ClusterIP는 주로 프런트앤드와 백앤드간의 통신에 사용됩니다.
추가로 1개의 Service Object는 Deployment로 생성된 동일한 Pod 다수와 연동될 수 있습니다.
여기서 드는 의문이 Service Object 가 다수의 Pod와 연결되어 있으면
어떤 원리로 다수의 Pod 중 한 Pod에 연결이 되는가 인데
해당 부분 역할을 하는 것은 Kubernetes Cluster를 구성하는 모듈 중 worker node의 kube-proxy 가 담당합니다.
Kube-proxy는 [user space, iptables, ipvs]와 같은 mode로 동작할 수가 있는데
현재는 iptables mode가 default로 동작되고
해당 모드에서 다양한 로드밸런싱 알고리즘(라운도 로빈, 라스트 커넥션, 등등)으로 동작하고 있습니다.
다음으로는 NodePort Type에 대해 설명드리겠습니다.
예제로 동일한 WAS server 역할을 하는 Pod가 생성이 되어있다면
관리자가 서버 관리를 위해 내부망에서도 접근이 가능해야 하고
서비스 제공을 위해 외부 네트워크에서 접속이 가능해야 합니다.
Kubernetes에서는 외부 네트워크에서 pod에 접속하기 위한 가장 간단한 방법으로
NodePort Type을 제공하고 있습니다.
NodePort Type을 생성하면
Kubernetes Cluster를 구성하는 모든 Server에 3만 번 대의 포트가 열리게 됩니다.
그리고 외부에서 Master Node 또는 Worker Node의 Server IP로 해당 Port를 통해 접속하면
바로 NodePort Type의 Service로 연결되어
Service object와 연결되어 있는 pod로 접근이 가능하게 됩니다.
하지만 NodePort 또한 한 가지 문제가 있습니다.
특정 Server로 접근하던 중
Server에 문제가 생겨서 뻗을 경우
Pod로 접근하지 못하는 문제가 발생할 수 있습니다.
NodePort는 정상적으로 운영되는 Server로 loadbalaning 해주는 역할을 지원하지 않습니다.
이와 같은 단점으로 NodePort는 보통
내부 관리자가 Server에 접근하여 관리하는 용도로 사용한다고 합니다.
NodePort의 단점을 해결하기 위해 나온 것이 바로 LoadBalaner Type입니다.
AWS, GCP, Azure 같은 클라우드 서비스를 사용할 때 사용 가능한 옵션이고
외부 IP를 가지고 있는 로드밸런서를 할당받아서 동작합니다.
하지만 on-premise 환경에서도 MetalLB이라는 Addon을 사용해서
LoadBalaner Type의 Service를 사용할 수 있습니다.
하지만 이런 LoadBalaner Type도 Service Object 수만큼의 외부 IP를 할당받아야 하는 단점이 있습니다.
Public cloud 환경에서 이와 같이 LoadBalancer가 증가하면 그만큼의 비용도 더 과금이 되어 사용 시 주의해야 합니다.
이러한 단점을 해결하기 위해 사용되는 것이 바로 Ingress입니다.
Service Object의 Type은 아니고 Addon 종류에 속합니다.
왼쪽부터 설명드리면 Pod에 연결되는 ClusterIP Type의 Service Object를 생성하고
해당 Service Object를 Ingress와 연동시키는 원리입니다.
Ingress는 도메인을 기반으로 Service Object를 연결하기 때문에 다수의 Service Object를 연결시킬 수 있습니다.
Ingress는 nginx, haproxy, kingkog, GCP의 GKE에서 제공하는 GCE 등 많은 종류를 지원하고 있지만 Kubernetes에서 공식적으로 Addon에 포함시킨 건
Nginx, 와 GCE ingress입니다.
해당 그림은 nginx ingress를 LoadBalancer Type으로 사용한 상태의 그림입니다.
이전에 설명드렸던 LoadBalancer Type과 동일하게 Public Cloud에서 LoadBalancer 외부 IP를 할당받으면
Ingress Controller Pod로 연결되고
해당 Ingress Controller Pod가 ingress에 설정되어있는 domain주소로 service object와 연결하게 됩니다.
참고로 Node Port Type으로도 ingress를 사용하실 수 있습니다.
지금까지 Kubernetes의 Service Object에 대해서 알아보았습니다.
제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!
참고
https://kubernetes.io/docs/concepts/services-networking/service/
https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/expose/
pod 간 네트워크 설명
https://arisu1000.tistory.com/27850
Loadbalancer
https://blog.leocat.kr/notes/2019/08/22/translation-kubernetes-nodeport-vs-loadbalancer-vs-ingress
https://kubernetes.io/ko/docs/concepts/services-networking/
부하분산 원리 동영상 강의: https://www.youtube.com/watch?v=v6TUgqfV3Fo&list=PL9mhQYIlKEhdTu31zyb_QelQMaqFGgASA&index=7
08:54 지점
service 란
동영상 강의 : https://www.youtube.com/watch?v=v6TUgqfV3Fo&list=PL9mhQYIlKEhdTu31zyb_QelQMaqFGgASA&index=7
https://arisu1000.tistory.com/27838
https://arisu1000.tistory.com/27839?category=787056
https://blog.leocat.kr/notes/2019/08/22/translation-kubernetes-nodeport-vs-loadbalancer-vs-ingress
https://www.ibm.com/support/knowledgecenter/SSBS6K_3.2.0/manage_network/kubernetes_types.html
'클라우드 > Kubernetes' 카테고리의 다른 글
| 07. Kubernetes Network (LoadBalancer) (3) | 2020.08.09 |
|---|---|
| 06. Kubernetes Network (ClusterIP, NodePort) (0) | 2020.08.09 |
| 04. Kubernetes Pod 더 자세히 알아보기 (2) | 2020.08.07 |
| 03. Kubernetes 설치 과정 (0) | 2020.08.07 |
| 02. Kubernetes Addon (0) | 2020.08.05 |