오늘은 쿠버네티스의 서비스에 대해 얘기하려 합니다.
Service
포드 집합에서 실행 중인 응용 프로그램을 네트워크 서비스로 노출하는 추상적인 방법입니다.
Kubernetes를 사용하면 익숙하지 않은 서비스 검색 메커니즘을 사용하기 위해 응용 프로그램을 수정할 필요가 없습니다. 쿠버네티스는 팟들에게 자신들의 IP 주소와 팟들의 집합에 대한 단일 DNS 이름을 부여하고, 이들 사이에서 로드 밸런싱을 할 수 있다.
단일지점을 만든다는 것은 l4를 사용함 과 같은 효과를 내어 부하분산을 이뤄낼수 있다는 것을 얘기합니다. 바로 예제로 넘어가서 사용해 보도록 하겠습니다.
이전 시간에 만들었던 Deployment를 실행하여 pod 3개를 실행해 줍니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
그리고 다음과 같이 Service를 생성합니다.
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
type: ClusterIP
clusterIP: 10.100.100.10
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
kind 는 SERVICE이고 spec.type 은 clusterip로 주고 단일지점의 아이피 하나를 생성합니다. 그럼 사용하던 l4와 같이 균등하게 배분을 하는데 r/r방식은 아닙니다. 한번 확인해 보겠습니다. 아래와 같이 저는 nginx에서 index.html 파일을 수정해서 각 node의 pod를 구분해 줬습니다.
root@master:~/install/yaml# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16h
nginx ClusterIP 10.100.100.10 <none> 80/TCP 15h
어떻게 사용하시는지 알겠죠? 이게 단일지점 아이피의 사용 방법입니다.
DNS
추가 기능을 사용하여 Kubernetes 클러스터에 대한 DNS 서비스를 설정할 수 있으며 거의 항상 설정해야 합니다.
CoreDNS와 같은 클러스터 인식 DNS 서버는 새로운 서비스를 위한 Kubernetes API를 감시하고 각 서비스에 대한 DNS 레코드 집합을 만듭니다. 클러스터 전체에서 DNS를 사용하도록 설정한 경우 모든 포드는 DNS 이름으로 서비스를 자동으로 확인할 수 있습니다.
예를 들어, Kubernetes 네임스페이스 my-ns에 my-service라는 서비스가 있는 경우 제어부와 DNS 서비스가 함께 작동하면 my-service.my-ns에 대한 DNS 레코드가 생성됩니다. my-ns 네임스페이스의 포드는 my-service에 대한 이름 조회를 수행하여 서비스를 찾을 수 있어야 합니다(my-service.my-ns도 작동합니다).
다른 네임스페이스의 포드는 이름을 my-service.my-ns로 지정해야 합니다. 이러한 이름은 서비스에 할당된 클러스터 IP로 확인됩니다.
쿠버네티스는 명명된 포트에 대한 DNS SRV(서비스) 레코드도 지원합니다. my-service.my-ns 서비스에 프로토콜이 TCP로 설정된 http라는 포트가 있는 경우 _http._http.my-service.my-ns에 대한 DNS SRV 쿼리를 수행하여 http의 포트 번호와 IP 주소를 검색할 수 있습니다.
Kubernetes DNS 서버는 외부 이름 서비스에 액세스할 수 있는 유일한 방법입니다. 외부 이름 확인에 대한 자세한 내용은 DNS 포드 및 서비스를 참조하십시오.
Headless Services
경우에 따라 로드 밸런싱과 단일 서비스 IP가 필요하지 않습니다. 이 경우 클러스터 IP(.spec.cluster)에 대해 "없음"을 명시적으로 지정하여 "헤드리스" 서비스를 생성할 수 있습니다IP).
헤드리스 서비스를 사용하여 Kubernetes의 구현에 얽매이지 않고 다른 서비스 검색 메커니즘과 인터페이스할 수 있습니다.
헤드리스 서비스의 경우 클러스터 IP가 할당되지 않고, kube-proxy가 이러한 서비스를 처리하지 않으며, 플랫폼에서 헤드리스 서비스에 대해 수행하는 로드 밸런싱이나 프록시가 없습니다. DNS가 자동으로 구성되는 방법은 서비스에 선택기가 정의되어 있는지 여부에 따라 달라집니다:
우리가 기존에 설정한 yaml파일에서 CluterIP: None로 변경하면 다음과 같이 사용이 가능 합니다. 우선 아래와 같이 서비스하나를 추가해 줍니다.
apiVersion: v1
kind: Service
metadata:
name: nginx-none
spec:
type: ClusterIP
clusterIP: None
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16h
nginx ClusterIP 10.100.100.10 <none> 80/TCP 15h
nginx-none ClusterIP None <none> 80/TCP 15h
nginx-none라는 service가 생겼고, 아래와 같이 request pod를 하나 생성해 줍니다.
kubectl run test --image=kubetm/init -it -- /bin/bash
위와 같이 생성하면 바로 해당 pod에 진입할 겁니다.
그럼 다음과 같이 한번 테스트를 해보시면 됩니다.
[root@test /]# curl 192-168-84-132.default.pod.cluster.local
Node-1 : 2
그리고 단일 pod가 아닌 이전 만들었던 service의 clusterip의 dns로 호출하면 아래와 같이 호출 되는 것을 확인 할 수 있습니다.
잘 이해 되셨나요? 어떻게 사용해야 하는지 조금씩 감이 오실거라 생각 됩니다.
상세한 사항은 아래를 확인해 주세요
https://kubernetes.io/docs/concepts/services-networking/service/
'서버인프라 > kubernetes' 카테고리의 다른 글
[제 10강] Labels 사용 (0) | 2023.01.12 |
---|---|
[제 9강] Ingress (0) | 2023.01.05 |
[제 7강] NameSapace (4) | 2022.12.29 |
[제 6강] Updating a Deployment (1) | 2022.12.27 |
[제 5강] Deployments (0) | 2022.12.25 |
댓글