본문 바로가기

Deploy/kubernates

Kubernates 내에서의 Pod 통신 (with Service)

※ 이 글은 개인적으로 공부하기 위해 정리한 글입니다. 

 

Kubernates와 더불어 Devops는 백엔드와 프론트엔드에서 분리할 수 없는 존재이다.

 

이번에 새롭게 배포 파이프라인이 배포가 되면서, Kubernates 내의 새로운 Cluster들이 배포됨에 따라 그 프로세스들을 다시 한번 정리하고자 이 글을 작성하게 되었다.

 

프로세스를 간단하게 정리하자면 다음과 같다. 

1) aks 서버 만들기

2) 코드상에서 배포 파이프라인 파일, ingress 설정파일(.yml 파일), 여러 설정파일들을 새로운 aks 서버에 따라 설정값을 바꿔준다. 

3) 새로운 cluster 배포 + 새로운 파이프라인을 구축한다. 

 

출처 : https://tech.kakao.com/2018/12/24/kubernetes-deploy/

 

이번에 kubectl get service를 통해 현재 띄워져있는 ClusterIP와 LoadBalancer 등의 목록을 확인할 수 있었다.

이 명령어는 처음 써보는데, kubernates에서 service는 어떤 의미인지 궁금해지다가 kubernates에서 통신 방법도 이번 기회에 정리해보고자 한다. 

 

들어가기에 앞서, Kubernates의 Pod들은 비영구적으로, 종종 소멸되거나 복구된다.

또한 Pod들은 고유한 IP주소를 가지긴 하지만, 동적으로 변경되는 특징을 가지고 있다. 

 

이 Pod들의 집합과 통신하려면 일반적으로 Service 디스커버리 매커니즘이 필요하다. 

Kubernates에서는 Service라는 개념을 통해 Pod에게 고유한 IP주소와 집합에 대한 단일 DNS명을 부여하고, 레플리카들에게 알아서 로드밸런싱을 수행해준다.

 

Cluster IP - 클러스터 내부에서만 접근 가능한 IP 

LoadBalancer - 외부의 로드 밸런서 사용 (LoadBalancer로 설정하면 외부에서도 접근이 가능해야 하니 EXTERNAL-IP에 이름이 부여된다) 

ExternalName - kube dns 컴포넌트로 DNS를 이용하는 방법 

NodePort - Port번호를 통해 외부에서 접근 

 

 

 

 

 

Kubernates에서의 Service 네트워킹 방식 

 

1) 서로 결합된 Container - Container 간의 통신

컨테이너는 Docker로 생성된다. 각 Container는 veth라는 가상 네트워크 인터페이스를 가지게 되며, 각각의 veth IP 주소값으로 통신할 수 있다.

 

2) Pod - Pod 간의 통신

Pod는 고유한 IP 주소를 가진다.

 

3) Pod - Service 통신 

Pod IP를 어떤 서비스의 엔드포인트로 설정하는 것은 가능하지만, 해당 Pod가 계속 존재하고 있을 보장은 없다. 

또한 새로운 Pod가 생성되었을 때 그 IP주소가 엔드포인트와 동일할 것이라는 보장도 없는데, 이런 보장성을 만들기 위해 Service 앞단에

LoadBalancer를 위치시킴으로써 해결이 가능하다. 

 

또 한가지 방법으로는 클라이언트에서 proxy로 연결을 하면 proxy의 역할은 서버들의 목록을 관리하며 현재 살아있는 서버에게 트래픽을 전달한다. 

 

4) 외부-Service 통신 

기본적으로 Service는 ClusterIP라는 IP 주소를 부여받으며 클러스터 내부적으로 이 IP주소를 통해 자신이 포워딩 해야할 Pod들에게 트래픽을 전달해야 한다. Kubernates에서의 Service는 클러스터 내부적으로만 통신할 수 있게끔 설계되어있지만, Pod는 외부로도 통신이 되어야 하기 때문에 외부-Service 통신이 필요한 것이다. 

 

4-1) NodePort 

NodePort는 ClusterIP의 타입과 동일하지만 몇 가지 기능이 더 있다. 

노드 네트워크의 IP를 통하여 접근이 가능함과 동시에 Cluster IP로도 접근이 가능하다. 

NodePort 타입의 서비스를 생성하려면 kube-proxy가 각 노드의 eth0 네트워크 인터페이스에 30000~32767 포트 사이에서 임의의 포트를 할당해준다. 

이 할당된 포트로 요청이 들어오게 되면 이것을 맵핑된 CluterIP로 전달한다. 

 

4-2) LoadBalancer

AWS나 AZURE 같은 외부 클라우드 서비스를 사용하여 프로비저닝(IT 인프라를 생성하고 설정)이 가능하다.

외부 로드밸런서의 트래픽은 클러스터 내의 Pod로 전달된다.

 

 

 

 

Kubernates Cluster의 구조 

Traffic (외부) 

|

Ingress (라우팅 주소=도메인명) 

|

Service (LoadBalancer 역할) : 단일 Pod에 대한 진입점 제공, 로드밸런싱 수행

|

Pod1 Pod2 Pod3 ... 

 

Ingress는 클러스터 외부의 요청을 Ingress 리소스에 정의된 규칙에 따라 클러스터 내부의 서비스로 연결해준다. 

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 객체로, HTTP 및 HTTPS 트래픽을 처리한다. 

 

Ingress의 경우, LoadBalancer가 여러 개일 경우 비용이 많이 발생한다. LoadBalancer은 네트워크 트래픽을 여러 서버 또는 서비스 인스턴스로 분산시키는 역할을 한다. 

 

즉 Ingress는 외부 트래픽을 내부 서비스로 라우팅 / LoadBalancer은 리소스를 사용하여 트래픽을 분산시키는 차이점이 있다. 

 

비용이 많이 발생하는 것을 방지하기 위해서 1개의 LoadBalancer로 특정 도메인 URL 기반 다른 성격의 서비스들을 라우팅하는 것이 역할이다. 

 

참고

핀다 기술블로그 https://medium.com/finda-tech/kubernetes-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A0%95%EB%A6%AC-fccd4fd0ae6