Kubernetes Service
Service는 Kubernetes의 기본 오브젝트 중 하나입니다.
Kubernetes에서 Pod은 생성과 삭제가 자유로운 오브젝트입니다. Controller를 통해 Pod을 관리하는 경우 Pod에 문제가 생기면 새로운 Pod을 생성하게 되는데 이 때 Pod의 IP주소가 랜덤하게 생성됩니다.
이 때, 트래픽을 전달할 대상인 Pod의 IP를 Endpoint라고 하며, 서비스는 Label을 통해 Pod의 라벨을 매칭해 Endpoint 정보를 수집하고, 자신에게 오는 트래픽을 적절한 Endpoint로 분배합니다.
만약 사용자나 다른 애플리케이션이 어떤 Pod에 접근할 때 Pod의 IP주소를 이용해 접근한다면 그 Pod에 문제가 생겨 IP가 변경되면 기존과 동일한 서비스를 제공하는 Pod으로 접속하는 것을 보장할 수 없습니다.
Kubernetes는 이를 Service를 통해 해결하고 있습니다.
Service의 역할
Kubernetes에서 이러한 문제점을 해결하기 위해 Pod의 네트워크 정보가 변경되어도 정상적으로 통신이 가능하도록 Pod 레벨의 네트워크를 추상화 하였는데 이것을 Service라고 부르며, Control Plane중 하나인 kube-proxy가 이 Service를 관리합니다.
Kubernetes는 Service를 통해 Pod에서 실행중인 Container를 외부로 노출시킵니다.
이 때, 동일한 기능을 하는 Pod들의 Endpoint 정보를 Service라는 네트워크 리소스로 추상화합니다.
Pod에 접근을 하고자 하는 경우 해당 Pod를 추상화한 Service에 접근하면 Service가 적절한 Pod로 트래픽을 전달해 줍니다.
Service라는 이름 때문에 혼동이 있을 수도 있지만, 쉽게 말하자면 Service는 어떠한 기능을 제공하는 Pod에 대한 연결을 보장해주는 중간 통로라고 볼 수 있을 것 같습니다.
Label selector를 이용해 특정한 Label을 가진 Pod들을 Service 아래에 연결하고 사용자나 다른 애플리케이션은 해당 기능을 제공하는 Pod에 접근할 때 Pod의 IP주소가 아닌 Service의 주소를 통해 접근합니다.
만약 기존 Pod에 문제가 생겨 IP주소가 변경되더라도 새로 생성한 Pod에 Label selector에 정의한 Label이 있다면 Service는 새로 생성된 Pod으로의 연결을 자동으로 제공해줍니다.
이렇게되면 만약 Cluster 내부적으로 Pod에 문제가 생겨 IP주소가 변경되더라도 외부에서는 이런 문제에 대해 알 필요가 없습니다.
Service의 종류
Service에는 크게 3가지 종류가 있습니다.
위의 그림을 보면 알 수 있듯이 Cluster IP, Node Port, Load Balancer 입니다.
각각의 Service들은 Pod를 외부로 노출시키는 방법이나 형태가 조금씩 다릅니다.
1. Cluster IP
Cluster IP는 type을 지정해주지 않으면 자동으로 생성되는 Service입니다.
Cluster IP라는 이름처럼 Cluster내부에서만 이용할 수 있는 IP로 외부에서는 Cluster IP를 통한 접근이 불가능합니다.
위의 그림과 같은 형태로 접근을 제공하며, 같은 Cluster에 위치한 Pod들은 Cluster IP를 이용해 Service가 관리하는 Pod에 접근이 가능합니다.
서로 다른 Worker Node에 있는 경우 kube-proxy를 활용해 조금 복잡한 방식으로 통신이 이루어지는데 이에 대해서는 나중에 자세히 설명하겠습니다.
2. Node Port
Node Port란 이름 그대로 Pod가 위치한 Node 즉 Worker Node들의 특정 Port를 통해 Service에 접근하는 것을 의미합니다.
그림으로 보면 위의 그림과 같은 형태로 통신이 이루어지는데, 기존의 Cluster IP상단에 Node Port라는 새로운 Service가 생성된 것을 확인할 수 있습니다.
이 그림을 보면 Cluster IP는 마치 Node안에 존재하는 것 처럼 보이지만 그렇지 않습니다.
위의 그림에서는 Node가 하나만 표현되어 있기 때문에 혼동이 있을 수 있습니다.
Cluster IP는 Label selector를 통해 선택된 모든 Pod들에 대한 접근을 제공해야 합니다.
그런데 일반적으로 Kubernetes 환경에서 Pod들은 여러 Worker Node에 걸쳐서 배포되어 있기 때문에 다수의 Worker Node에 흩어져 있는 같은 Label을 가진 Pod에 접근하기 위해서는 Cluster IP가 특정 Node안에 존재하는 형태가 아닌 모든 Worker Node가 접근할 수 있는 Cluster의 어딘가에 위치해야 합니다.
3. LoadBalancer
마지막으로 LoadBalancer란 말 그대로 Load balancing을 제공해 줄 수 있는 Service입니다.
LoadBalancer로 접근하면, LoadBalancer에 설정된 리시버, 타겟 설정에 따라 Worker Node의 특정 Port로 트래픽을 전달해주는 방식입니다.
LoadBalancer타입 Service를 사용하기 위해서는 실제 LoadBalancer 장비가 필요한데 물리적 장비를 이용하거나, AWS, Azure, GCP 등 Cloud Service Provider가 제공하는 LoadBalancer를 사용하면 됩니다.
온프레미스/베어메탈 환경에서 물리 장비의 사용이 어려울 경우 MetalLB와 같은 가상의 로드밸런서를 사용할 수도 있습니다.
$ kubectl describe svc nginx
Name: nginx
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=nginx
Type: LoadBalancer
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.106.84.164
IPs: 10.106.84.164
LoadBalancer Ingress: 10.0.1.79
Port: http 8080/TCP
TargetPort: 80/TCP
NodePort: http 31181/TCP
Endpoints: 172.17.0.11:80
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>위의 코드는 어떤 LoadBalnacer Service의 정보를 조회한 결과입니다.
Type이 LoadBalancer인 것을 확인할 수 있고,
NodePort와 Cluster IP(IP, IPs)도 확인할 수 있습니다.
자세한 흐름은 아래와 같습니다.
- 외부에서
LoadBalancerIP로 접근을 시도Service가Label selector을 통해 관리하는Pod가 위치한Worker Node중 하나의 31181번 Port로 트래픽이 전달- 10.106.84.164라는
Cluster IP의 8080번 Port로 트래픽이 전달Label selector에 의해 선택된Pod들 중 하나로 트래픽 전달
정리
Service는 Kubernetes의 기본 오브젝트 중 하나일 정도로 매우 중요한 오브젝트입니다.
Service는 자동으로 Pod이 생성되고 삭제되는 환경에서 Label selector를 이용해 외부 사용자들에게 내부에 어떤 문제가 발생하던 동일한 기능을 제공하는 Pod 로의 접속을 보장합니다.
