이 장에서는 쿠버네티스에서 서비스라는 오브젝트에 대해서 알아 보겠습니다.
Kubernetes networking addresses four concerns:
- Containers within a Pod use networking to communicate via loopback.
- Cluster networking provides communication between different Pods.
- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
- You can also use Services to publish services only for consumption inside your cluster.
쿠버네티스 네트워킹은 4가지 고려 합니다.
- 파드안의 컨테이너들은 loopback을 통해서 통신합니다.
- 클러스터 네트워킹은 제공합니다. 각기 다른 파드들의 통신을
- 서비스 리소스는 우리에게 어플리케이션(파드안에서 실행중인) 에 접근할수 있도록 클러스터 밖에서도.
- 당신은 서비스를 사용할수 있습니다. 클러스터 내부의 서비스를 밖으로 표출하기 위해
Service
An abstract way to expose an application running on a set of Pods as a network service.
With Kubernetes you don't need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
서비스란? 논리적인 방법입니다. 몇개의 파드를 network service를 통해서 밖으로 노출할수 있게 만들어주는.
쿠버네티스를 통해서 당신은 어플리케이션을 친숙하지 않은 서비스 discovery 메카니즘을 몰라도 되게 만들어줍니다.
쿠버네티스는 당신의 파드들에게 각자 ip addr과 DNS 네임을 제공합니다. 그리고 또한 로드벨런싱을 그들 위에 있게 해줍니다.
Motivation
Kubernetes Pods are created and destroyed to match the state of your cluster. Pods are nonpermanent resources. If you use a Deployment to run your app, it can create and destroy Pods dynamically.
Each Pod gets its own IP address, however in a Deployment, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later.
This leads to a problem: if some set of Pods (call them "backends") provides functionality to other Pods (call them "frontends") inside your cluster, how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload?
Enter Services.
쿠버네티스의 파드는 일시적인 리소스입니다. 그들은 Deployment라는 오브젝트 안에서 당신의 어플리케이션을 동작하기 위해 존재하지만, 언제라도 다시 만들어지고 소멸될수 있습니다.
각 파드들은 그들만의 IP addr을 가지는데, 그러나, 그들이 어느 순간에는 통신을 하고 있지만, 갑자기 그 통신이 달라질수 있습니다.
이것은 이러한 문제를 야기합니다.
당신의 backend 파드들이 frontend 파드들에게 기능적인 제공을 하고 있어야만 하는데, 어떻게 그 ip connect의 추적을 할수 있을까요?
바로 서비스 덕분 입니다.
Defining a Service
A Service in Kubernetes is a REST object, similar to a Pod. Like all of the REST objects, you can POST a Service definition to the API server to create a new instance. The name of a Service object must be a valid RFC 1035 label name.
For example, suppose you have a set of Pods where each listens on TCP port 9376 and contains a label
서비스 오브젝트는 라벨을 통해서 pod와 연결되어 있습니다.
deployment의 selector와
Service의 selector / label이 일치해야 합니다.
port: 부분은 파드끼리 통신할 포트
targetPort: 외부에서 접속할때의 포트
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
'컨테이너 > Kubernetes' 카테고리의 다른 글
[Kubernetes](8) kubeadm으로 k8s 구성(2) (0) | 2021.01.06 |
---|---|
[쿠버네티스](7) kubeadm으로 k8s 구성 (1) (0) | 2020.12.27 |
[쿠버네티스] (6) 서비스 & microservice (0) | 2020.12.20 |
[쿠버네티스] (4) 레플리카 셋 사용하기 (0) | 2020.12.12 |
[쿠버네티스] (3) Pod와 내부 컨테이너들의 이해 (0) | 2020.12.08 |