챕터5. 서비스: 클라이언트가 파드를 검색하고 통신을 가능하게 함

서비스: 클라이언트가 파드를 검색하고 통신을 가능하게 함

쿠버네티스가 아닌 세계에서 서비스를 제공하는 서버의 정확한 IP주소나 호스트 이름을 지정해 애플리케이션을 구성하는 것과 달리, 쿠버네티스에서 동일한 작업을 수행하면 다음과 같은 이유로 동작하지 않는다.

• 파드는 일시적인다.
• 쿠버네티스는 노드에 파드를 스케줄링한 후 파드가 시작되기 바로 전에 파드의 IP주소를 할당한다.
• 수평 스케일링은 여러 파드가 동일한 서비스를 제공할 수 있음을 의미한다.

쿠버네티스는 이런 문제를 해결하기 위해 또 다른 리소스 유형인 서비스를 제공함

5.1 서비스 소개

쿠버네티스의 서비스: 동일한 서비스를 제공하는 파드 그룹에 지속적인 단일 접점을 만들려고 할 때 생성하는 리소스이다.

파드의 IP주소가 변경되더라도 서비스의 IP주소는 변경되지 않는다.

또한 서비스를 생성하면 환경변수 또는 DNS 이름으로 서비스를 쉽게 찾을 수 있다.

ex) 프론트엔드, 백엔드 파드

5.1.1 서비스 생성

서비스를 지원하는 파드가 한 개 혹은 그 이상일 수 있다.

→ 서비스 연결을 서비스 뒷단의 모든 파드로 로드밸런싱 된다.

 

kubectl expose로 서비스 생성

expose 명령어는 레플리케이션컨트롤러에서 사용된 것과 동일한 파드 셀렉터를 사용해

서비스 리소스를 생성하고 모든 파드를 단일 IP 주소와 포트로 노출한다.

 

YAML 디스크립터를 통한 서비스 생성

//Kubia-svc.yaml
apiVersion: V1
kind: Service
metadata:
	name: kubia
spec:
	ports:
	- port: 80 //서비스가 사용할 포트
		targetPort: 8080 //서비스가 포워드할 컨테이너 포트
	selector:
		app: kubia //app=kubia 레이블이 있는 모든 파드가 이 서비스에 포함된다.

• kubia 라는 서비스를 정의한 것
• 이 서비스는 포트 80의 연결을 허용하고 각 연결을 app=kubia 레이블 셀렉터와 일치하는 파드의 포트 8080으로 라우팅한다.

클러스터 내에서 서비스 테스트

• 서비스의 클러스터 Ip로 요청을 보내고 응답을 로그로 남기는 파드를 만드는 것
  → 파드의 로그를 검사해 서비스의 응답이 무엇인지 확인
• 쿠버네티스 노드로 ssh 접속하고 curl 명령을 실행
• kubectl exec 명령어로 기존 파드에서 curl 명령을 실행

실행 중인 컨테이너에 원격으로 명령어를 실행

$ kubectl exec kubia-7nog1 -- curl -s <http://10.111.249.153>

더블 대시를 사용하는 이유

→ 더블 대시(—)는 kubectl 명령줄 옵션의 끝을 의미한다.

더블 대시 뒤의 모든 것은 파드 내에서 실행돼야 하는 명령이다.

• 파드의 컨테이너 내에서 curl명령을 실행하도록 쿠버네티스에 지시했다.
• curl은 HTTP 요청을 서비스로 IP로 보냈다.
• 쿠버네티스 서비스 프록시가 연결을 가로채서 세 개의 파드 중 임의의 파드로 요청을 전달한다.
• 파드 내에서 실행 중인 요청을 처리하고 해당 파드의 이름을 포함하는 HTTP 응답을 반환한다.
• curl은 표준 출력으로 응답을 출력하고 이를 kubectl이 있는 로컬 시스템의 표준 출력에 다시 표시한다.

서비스의 세션 어피니티 구성

동일한 클라이언트에서 요청하더라도 서비스 프록시가 각 연결을 임의의 파드를 선택해 연결을 다시 forward 하기 때문에 요청마다 다른 파드가 선택된다.

매번 같은 파드로 리다이렉션하려면 서비스의 세션 어피니티 속성을 기본값 None 대신 ClientIP로 설정한다.

apiVersion: V1
kind Service
spec:
	sessionAffinity: ClientIp
	...

• 쿠버네티스는 None과 ClientIP라는 두 가지 유형의 서비스 세션 어피니티만 지원한다.
• 쿠키 기반 세션 어피니티 옵션은 없다
• 서비스는 TCP와 UDP 패킷을 처리하고 그들이 가지고 있는 페이로드는 신경 쓰지 않는다.
• 쿠키는 HTTP 프로토콜의 구성이기 때문에 서비스는 쿠키를 알지 못한다

동일한 서비스에서 여러 개의 포트 노출

하나의 서비스를 사용해 멀티 포트 서비스를 사용하면 단일 클러스터 IP로 모든 서비스 포트가 노출된다.

여러 포트가 있는 서비스를 만들 때는 각 포트의 이름을 지정해야 한다.

//서비스 정의에서 멀티 포트 지정
apiVersion: v1
kind: Service
metadata:
	name: kubia
spec:
	ports:
	- name: http
		port: 80
		targetPort: 8080
	- name: https
		port: 443
		targetPort: 8443
	selector:
		app: kubia

이름이 지정된 포트 사용

각 파드의 포트에 이름을 지정하고 서비스 스펙에서 이름으로 참조할 수 있다.

//파드 정의에 포트 이름 사용
kind: Pod
spec:
	containers:
	- name: kubia
		ports:
		- name: http
			containerPort: 8080 //컨테이너 포트 8080은 http라고 한다
		- name: https
			containerPort: 8443 //포트 8443을 https라고 한다

//서비스에 이름이 지정된 포트 참조하기
apiVersion: v1
kind: Service
spec:
	ports:
	- name: http
		port: 80
		targetPort: http //포트 80은 http라는 컨테이너 포드에 맵핑
	- name: https
		port: 443
		targetPort: https //포트 443은 컨테이너 포드의 이름이 https인 것과 맵핑

5.1.2 서비스 검색

쿠버네티스는 클라이언트 파드가 서비스의 IP와 포트를 검색할 수 있는 방법을 제공한다.

 

환경변수를 통한 서비스 검색

파드가 시작되면 쿠버네티스는 해당 시점에 존재하는 각 서비스를 가리키는 환경변수 세트를 초기화 한다.

 

DNS를 통한 서비스 검색

파드에서 실행 중인 프로세스에서 수행된 모든 DNS쿼리는 시스템에서 실행 중인 모든 서비스를 알고 있는

쿠버네티스의 자체 DNS 서버로 처리된다.

각 서비스는 내부 DNS 서버에서 DNS항목을 가져오고 서비스 이름을 알고 있는 클라이언트 파드는 환경변수

대신 FQDN(정규화된 도메인 이름)으로 액세스 할 수 있다.

 

FQND를 통한 서비스 연결

ex) backend-database.default.svc.cluster.local

backend-database는 서비스 이름이고 default는 서비스가 정의된 네임스페이스를 나타내며 svc.cluster.local은

모든 클러스터의 로컬 서비스 이름에 사용되는 클러스터의 도메인 접미사다.

 

파드의 컨테이너 내에서 셸 실행

셸을 올바르게 사용하려면 -it 옵션을 kubectl exec에 넣어야한다.

5.2 클러스터 외부에 있는 서비스 연결

쿠버네티스 서비스 기능으로 외부 서비스를 노출하려는 경우

→ 서비스가 클러스터 내에 있느 파드로 연결을 전달하는게 아니라 외부 IP와 포트로 연결을 전달하는 것

클러스터에서 실행 중인 클라이언트 파드는 내부 서비스에 연결하는 것처럼 외부 서비스에 연결할 수 있다.

5.2.1 서비스 엔드포인트 소개

서비스는 파드에 직접 연결되지 않는다.

→ 엔드포인트 리소스가 그 사이에 있다.

• 엔드포인트 리소스는 서비스로 노출되는 파드의 IP 주소와 포트 목록이다.
• 엔드포인트 리소스는 다른 쿠버네티스 리소스와 유사하므로 kubectl get을 사용해 기본 정보를 표시 할 수 있다.
• 파드 셀렉터는 서비스 스펙에 정의돼 있지만 들어오는 연결을 전달할 때 직접 사용하지는 않는다.

5.2.2 서비스 엔드포인트 수동 구성

서비스의 엔드포인트를 서비스와 분리하면 엔드포인트를 수동으로 구성고 업데이트 할 수 있다.

파드 셀렉터 없이 서비스를 만들면 쿠버네티스는 엔드포인트 리소스를 만들지 못한다.

수동으로 관리되는 엔드포인트를 사용해 서비스를 만들려면 서비스와 엔드포인트 리소스를 모두 만들어야 한다.

 

셀렉터 없이 서비스 생성

apiVersion: v1
kind: Service
metadata:
	name: external-service //서비스 이름은 엔드포인트 오브젝트 이름과 일치해야 한다.
spec:
	port:
	- port: 80 //이 서비스에는 셀렉터가 정의돼 있지 않다.

셀렉터가 없는 서비스에 관한 엔드포인트 리소스 생성

엔드포인트는 별도의 리소스이며, 서비스 속성은 아니다

apiVersion: v1
kind: Endpoints
metadata:
	name: external-service
subsets:
	- addresses:
		- ip: 11.11.11.11
		- ip: 22.22.22.22
		ports:
		- port: 80

• 엔드포인트 오브젝트는 서비스와 이름이 같아야 하고 서비스를 제공하는 대상 IP 주소와 포트 목록을 가져야 한다.

5.2.3 외부 서비스를 위한 별칭 생성

FQDN(정규화된 도메인 이름)으로 외부 서비스를 참조할 수 있다.

ExternalName 서비스 생성

외부 서비스의 별칭으로 사용되는 서비스를 만들려면 유형 필드를 ExternalName으로 설정해 서비스 리소스를 만든다.

ex) api.somecompany.com에 공개 API가 있다고 가정

apiVersion: v1
kind Service
metadata:
	name: external-service
spec:
	type: ExternalName //서비스 유형이 ExternalName으로 설정된다.
	externalName: someapi.somecompany.com //실제 서비스의 정규화된 도메인 이름
	ports:
	- port: 80

• ExternalName 서비스는 DNS 레벨에서만 구현된다.
• 서비스에 관한 간단한 CNAME DNS 레코드가 생성된다.
• ExternalName 유형의 서비스는 ClusterIP를 얻지 못한다.

5.3 외부 클라이언트에 서비스 노출

프론트엔드 웹 서버와 같은 특정 서비스를 외부에 노출해 외부 클라이언트가 액세스 할 수 있게 노출 시키는 것.

• 노드포트로 서비스 유형 설정: 노드포트 서비스의 경우 각 클러스터 노드는 노드 자체에서 포트를 열고 해당 포트로 수신된 트래픽을 서비스로 전달한다.
• 서비스 유형을 노드포트 유형의 확장인 로드밸런서로 설정: 쿠버네티스가 실행 중인 클라우드 인프라에서 프로비저닝된 전용 로드 밸런서로 서비스에 액세스 할 수 있다. 로드밸런서는 트래픽을 모든 노드의 노드포트로 전달한다. 클라이언트는 로드밸런서의 IP로 서비스에 액세스한다.
• 단일 IP주소로 여러 서비스를 노출하는 인그레스 리소스 만들기: HTTP레벨에서 작동하므로 4계층 서비스보다 더 많을 기능을 제공할 수 있다.

5.3.1 노드포트 서비스 사용

서비스를 생성하고 유형을 노드포트로 설정하는 것이다.

노드포트 서비스를 만들면 쿠버네티스는 모든 노드에 특정 포트를 할당하고 서비스를 구성하는 파드로 들어오는 연결을 전달한다.

 

노드포트 서비스 생성

//kubia-svc-nodeport
apiVersion: v1
kind: Service
metadata:
	name: kubia-nodeport
spec:
	type: NodePort //서비스 유형을 노드포트로 설정
	ports:
	- prot: 80 //서비스 내부 클러스터 Ip의 포트
		targetPort: 8080 //서비스 대상 파드의 포트
		nodePort: 30123 //각 클러스터 노드의 포트 30123으로 서비스에 액세스 할 수 있다.
	selector:
		app: kubia

• 유형을 노드포트로 설정하고 이 서비스가 모든 클러스터 노드에 바인딩돼야 하는 노드포트를 지정한다.

• 외부 클라이언트가 노드포트 서비스에 액서스 할 수 있도록 방화벽 규칙을 변경해 주어야 한다.

5.3.2 외부 로드밸런서로 서비스 노출

일반적으로 클라우드 인프라에서 로드밸런서를 자동으로 프로비저닝 하는 기능을 제공한다.

→ 노드포트 대신 서비스 유형을 로드밸런서로 설정하기만 하면 된다.

로드밸런서는 공개적으로 액세스 가능한 고유한 IP주소를 가지며 모든 연결을 서비스로 전달한다.

→ 로드밸런서의 IP주소로 서비스에 액세스 할 수 있다.

 

로드밸런서 서비스 생성

apiVersion: v1
kind: Service
metadata:
	name: kubia-loadbalancer
spec:
	type: LoadBalancer // 이 유형의 서비스는 쿠버네티스 클러스터를 호스팅하는 인프라에서 로드 밸런서를 얻을 수 있다.
	ports:
	- port: 80
		targetPort: 8080
	selector:
		app: kubia

로드밸런서를 통한 서비스 연결

• 외부 클라이언트는 로드밸런서의 포트 80에 연결하고 노드에 암묵적으로 할당된 노드포트로 라우팅된다. 여기에서 연결은 파드 인스턴스로 전달된다.
• 로드밸런서 유형 서비스는 추가 인프라 제공 로드밸런서가 있는 노드 포트 서비스다.

5.3.3 외부 연결의 특성 이해

불필요한 네트워크 홉의 이해와 예방

spec:
	externalTrafficPolicy: Local
	...

• 외부 클라이언트가 노드포트로 서비스에 접속할 경우 임의로 선택된 파드가 연결을 수신한 동일한 노드에서 실행 중일 수도 있고 않을 수도 있다.
• 파드에 도달하려면 추가적인 네트워크 홉이 필요할 수 있으며 이것이 항상 바람직한 것은 아니다.
• 이 추가 홉을 방지하기 위한 것이 서비스 스펙 세션의 externalTrafficPolicy
• 하지만 트래픽이 몰릴수 있고 로컬 파드가 존재하지 않으면 연결이 중단된다.

클라이언트 IP가 보존되지 않음 인식

노드포트로 연결을 수신하면 패킷에서 소스 네트워크 주소 변환이 수행되므로 패킷의 소스 Ip가 변경된다.

5.4 인그레스 리소스로 서비스 외부 노출

인그레스가 필요한 이유

• 로드밸런서 서비스는 자신의 공용 IP 주소를 가진 로드밸런서가 필요하지만 인그레스는 한 IP주소로 수십 개의 서비스에 접근이 가능하도록 지원해준다.
• 클라이언트가 HTTP 요청을 인그레스에 보낼 때, 요청한 호스트와 경로에 따라 요청을 전달할 서비스가 결정된다.
• 인그레스는 네트워크 스택의 애플리에키션 계층(HTTP)에서 작동하며 서비스가 할 수 없는 쿠키 기반 세션 어피니티 등과 같은 기능을 제공할 수 있다.

5.4.1 인그레스 리소스 생성

//kubia-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
	name: kubia
spec:
	rules:
		- host: kubia.example.com //인그레스는 kubia.example.com 도메인 이름을 서비스에 매핑한다
		http:
		paths:
		- path: / //모든 요청은 kubia-nodeport 서비스의 포트 80으로 전달된다.
			backend:
				serviceName: kubia-nodeport
				servicePort: 80

• Host kubia.example.com으로 요청되는 인그레스 컨트롤러에 수신된 모든 HTTP 요청을 포트 80의 kubia-nodeport 서비스로 전송하도록 하는 인그레스 규칙을 정의했다.

5.4.2 인그레스로 서비스 액서스

위 example.com 서비스에 액세스 하려면 도메인 이름이 인그레스 컨트롤러의 IP와 매핑되도록 해야한다.

인그레스의 IP주소를 얻고 → 인그레스 컨트롤러가 구성된 호스트의 IP를 인그레스 엔드포인트로 지정한다

(DNS 서버를 구성하거나, /etc/hosts 에 추가로 구성할 수 있다)

 

인그레스 동작 방식

• 클라이언트는 DNS 조회를 수행하여 인그레스 컨트롤러의 IP를 얻는다
• HTTP요청을 인그레스 컨트롤러에 전공하고 host 헤더에서 kubia.example.com을 지정한다
• 컨트롤러는 해당 헤더에서 클라이언트가 액세서하려는 서비스를 결정하고 서비스와 관련된 엔드포인트 오브젝트로 파드 IP를 조회한 다음 클라이언트 요청을 파드에 전달한다.
• 인그레스 컨트롤러는 요청을 서비스로 전달하지 않는다. 파드를 선택하는 데만 사용한다.

5.4.3 하나의 인그레스로 여러 서비스 노출

동일한 호스트의 다른 경로로 여러 서비스 매핑

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
	name: kubia
spec:
	rules:
		- host: kubia.example.com //인그레스는 kubia.example.com 도메인 이름을 서비스에 매핑한다
		http:
		paths:
		- path: /kubia
			backend:
				serviceName: kubia-nodeport
				servicePort: 80
		- path: /bar
			backend:
				serviceName: bar
				servicePort: 80

• 요청은 URL의 경로에 따라 두 개의 다른 서비스로 전송된다.
• 클라이언트는 단일 IP로 두 개의 서비스에 도달할 수 있다.

서로 다른 호스트로 서로 다른 서비스 매핑하기

...
spec:
	rules:
		- host: foo.example.com
			http:
				paths:
				- path: /
					backend:
						serviceName: foo
						servicePort: 80
		- host: bar.example.com
			http:
				paths:
				- path: /
					backend:
						serviceName: bar
						servicePort: 80
			

• 컨트롤러가 수신한 요청은 요청의 호스트 헤더에 따라 서비스 foo 또는 bar로 전달된다.
• DNS는 두 도메인 이름 모두 인그레스 컨트롤러의 IP 주소로 지정해야 한다.

5.4.4 TLS 트래픽을 처리하도록 인그레스 구성

인그레스를 위한 TLS 인증서 생성

• 클라이언트가 인그레스 컨트롤러에 대한 TLS 연결을 하면 컨트롤러는 TLS 연결을 종료한다.
• 클라이언트와 컨트롤러 간의 통신은 암호화되지만 컨트롤러와 백엔드 파드 간의 통신은 암호화되지 않는다.

5.5 파드가 연결을 수락할 준비가 됐을 때 신호 보내기

5.5.1 레디니스 프로브 소개

쿠버네티스에서는 라이브니스 프로브와 비슷하게 파드에 레디니스 프로브를 정의할 수 있다.

레디니스 프로브는 주기적으로 호출되며 특정 파드가 클라이언트 요청을 수신할 수 있는지를 결정한다.

 

레디니스 프로브 유형

• 프로세스를 실행하는 Exec 프로브는 컨테이너의 상태를 프로세스의 종료 상태 코드로 결정한다.
• HTTP GET 프로브는 HTTP GET 요청을 컨테이너로 보내고 응답의 HTTP 상태 코드를 보고 컨테이너가 준비됐는지 여부를 결정한다.
• TCP 소켓 프로브는 컨테이너의 지정된 포트로 TCP 연결을 연다. 소켓이 연결되면 컨테이너가 준비된 것으로 간주한다.

레디니스 프로브의 동작

• 라이브니스 프로브와 달리 컨테이너가 준비 상태 점검에 실패하더라도 컨테이너가 종료되거나 다시 시작되지 않는다.
• 레디니스 프로브는 요청을 처리할 준비가 된 파드의 컨테이너만 요청을 수신하도록 한다.
• 레디니스 프로브가 실패하면 파드는 엔드포인트 오브젝트에서 제거된다.
• 레디니스 프로브를 사용하면 클라이언트가 정상 상태인 파드하고만 통신하고 시스템에 문제가 있다는 것을 절대 알아차리지 못한다.

5.5.2 파드에 레디니스 프로브 추가

레플리케이션컨트롤러의 파드 템플릿에 레디니스 프로브 추가

apiVsersion: v1
kind: ReplicationController
...
spec:
	...
	template:
	...
		spec:
			containers:
			- name: kubia
				image: luksa/kubia
				readinessProbe: //파드의 각 컨테이너에 레디니스 프로브가 정의될 수 있다.
					exec:
						command:
						- ls
						- /var/ready

• 레디니스 프로브는 컨테이너 내부에서 ls /var/ready 명령어를 주기적으로 수행한다.
• 레디니스 프로브는 기본으로 10초마다 주기적으로 프로브가 실행된다.

5.5.3 실제 환경에서 레디니스 프로브가 수행해야 하는 기능

실제 환경에서 레디니스 프로브는 애플리케이션이 클라이언트 요청을 수신할 수 잇는지 여부에 따라 성공 또는 실패를 반환해야 한다.

레디니스 프로브를 항상 정의하라

• 파드에 레디니스 프로브를 추가하지 않으면 파드가 시작하는 즉시 서비스 엔드포인트가 된다.
• 기본 URL에 HTTP 요청을 보내더라도 항상 레디니스 프로브를 정의해야 한다.
• 레디니스 프로브에 파드의 종료 코드를 포함하지 마라
  → 쿠버네티스는 파드를 삭제하자마자 모든 서비스에서 파드를 제거하기 때문이다.

5.6 헤드리스 서비스로 개별 파드 찾기

클라이언트가 모든 파드에 연결하려면 각 파드의 IP를 알아야 한다.

쿠버네티스는 클라이언트가 DNS 조회로 파드 IP를 찾을 수 있도록 한다.

일반적으로 서비스에 대한 DNS조회를 수행하면 하나의 IP를 반환한다.

그러나 쿠버네티스 서비스에 클러스터 IP가 필요하지 않다면 서비스 IP 대신 파드 IP들을 반환한다.

5.6.1 헤드리스 서비스 생성

서비스 스펙의 clusterIp 필드를 None으로 설정하면

쿠버네티스는 클라이언트가 서비스의 파드에 연결할 수 있는 클러스터 IP를 할당하지 않기 때문에 서비스가 헤드리스 상태가 된다.

apiVersion: v1
kind: Service
metadata:
	name: kubia-headless
spec:
	clusterIP: None //이 부분이 서비스를 헤드리스 서비스로 만든다.
	ports:
	- port: 80
		targetPort: 8080
	selector:
		app: kubia

5.6.2 DNS로 파드 찾기

헤드리스 서비스에서는 DNS가 파드의 IP를 반환하기 때문에 클라이언트는 서비스 프록시 대신 파드에 직접 연결한다.

헤드리스 서비스는 여전히 파드 간에 로드밸런싱을 제공하지만 서비스 프록시 대신 DNS 라운드 로빈 매커니즘으로 제공한다.

5.6.3 모든 파드 검색- 준비되지 않은 파드도 포함

쿠버네티스가 파드의 레디니스 상태에 관계없이 모든 파드를 서비스에 추가되게 하려면 서비스에 다음 어노테이션을 추가해야 한다.

5.7 서비스 문제 해결

서비스로 파드에 액세스할 수 없는 경우 다음과 같은 내용을 확인한 후 다시 시작해보자

• 외부가 아닌 클러스터 내에서 서비스의 클러스터 IP에 연결되는지 확인한다.
• 서비스에 액세스할 수 있는지 확인하려고 서비스 IP로 핑을 할 필요없다. (서비스의 클러스터 IP는 가상 IP이므로 핑되지 않는다.)
• 레디니스 프로브를 정의했다면 성공했는지 확인하라.
• 파드가 서비스의 일부인지 확인하려면 kubectl get endpoints를 사용해 해당 엔드포인트 오브젝트를 확인한다.
• FQDN이나 그 일부로 서비스에 액세스하려고 하는데 작동하지 않는 경우, FQDN 대신 클러스터 IP를 사용해 액세스 여부를 확인하라
• 대상 포트가 아닌 서비스로 노출된 포트에 연결하고 있는지 확인한다.
• 파드 IP에 직접 연결해 파드가 올바른 포트에 연결돼 있는지 확인한다.
• 파드 IP로 애플리케이션에 액세스 할 수 없는 경우 애플리케이션이 로컬호스트에만 바인딩하고 있는지 확인한다.

5.8 요약

• 쿠버네티스 서비스 리소스를 생성해 애플리케이션에서 사용 가능한 서비스를 노출하는 방법을 배웠다.
• 안정된 단일 IP주소와 포트로 특정 레이블 셀렉터와 일치하는 여러 개의 파드를 노출한다.
• 유형을 노드포트 또는 로드밸런서로 설정해 클러스터 외부에서 서비스에 액세스할 수 있다.
• 파드가 환경변수를 검색해 IP주소와 포트로 서비스를 검색할 수 있다.
• ExternalName 서비스 유형으로 외부 서비스에 대한 DNS CNAME 별칭을 제공한다.
• 단일 인그레스로 여러 HTTP 서비스를 노출한다.
• 파드 컨테이너의 레디니스 프로브는 파드를 서비스 엔드포인트에 포함해야 하는지 여부를 결정한다.
• 헤드리스 서비스를 생성하면 DNS로 파드 IP를 검색할 수 있다.