- 서비스 리소스를 만들고, Pod 그룹을 하나의 주소로 노출하기
- 클러스터에서 서비스를 찾기
- 서비스를 외부 클라이언트에게 노출하기
- 외부 서비스를 내부 클러스터와 연결하기
- Pod이 서비스의 일부로 준비되었는지를 컨트롤하기
- 서비스 문제를 해결하기
- 기존의 환경에서는 시스템 관리자가 특정한 IP를 지정하여 서비스 간의 통신을 해왔음
- 그러나, 쿠버네티스 환경에서는 다음과 같은 이유로 불가능
- Pod는 일시적. 같은 노드의 다른 Pod의 스케일링이나 클러스터 노드의 실패로, 언제나 사라질 수 있기 때문
- 쿠버네티스는 노드에 Pod이 스케쥴 된 후에 IP를 할당하기에, 클라이언트는 Pod의 IP를 알 수 없음
- 클라이언트는 얼마나 많은 Pod이 있는지 알 필요가 없음. 스케일링이 가능한 Pod은 같은 IP를 가지고 있음
- 이러한 문제를 해결하기 위해, 쿠버네티스는 서비스라는 리소스 타입을 제공함
- 같은 서비스를 하는 Pod 그룹을 서비스로 제공
- 하나의 고정 포인트
- 서비스의 IP와 Port는 변하지 않음
- 따라서 클라이언트는 Pod의 구성과 위치에 대해서 신경쓸 필요가 없음
- Client는 Frontend의 구성을 신경쓰지 않고, Frontend는 Backend의 구성을 신경쓰지 않음
- 각각 서비스의 Pod이 Node가 바뀌어 IP가 바뀌더라도 서비스를 통해 묶여있어 하나의 고정된 Endpoint를 제공
- 따라서, 인프라 상황에 따라 Pod의 설정을 바꿀 필요가 없음
- Pod으로 로드밸런싱은 서비스의 연결로 가능함
- 그런데 이런 서비스의 구성은 어떻게 하는걸까?
Label Selector를 사용ReplicationController에도 사용됨
- 서비스를 만드는 가장 쉬운 방법은
kubectl expose를 사용 - ReplicationController에서도 사용되었듯이, 라벨 셀렉터를 통해 선택된 Pod을 단일 IP로 노출함
- 하지만 이제부터는 (고오오급) YAML을 배워보자
kubia-svc.yaml를 작성한다
- 서비스로 접속될 Port 80
- Pod에 접속할 Port 8080
app=kubia인 Pod을 모두kubia서비스로 등록kubectl create kubia-svc.yaml
- 이상하지만, pod이 서비스 cluster IP로 요청을 보내도록하고, 응답을 로깅
- 그리고 pod의 로깅과 서비스의 응답을 비교
- node에 ssh로 접속하여 curl을 사용
- pod 내부에서 curl을 사용
kubectl exec
kubectl exec로 특정 Pod에서 curl이 실행되도록 함- curl로 요청할 cluster IP는
kubectl get svc를 사용하여 확인 kubectl get pods로 임의의 Pod을 선택
- curl로 요청할 cluster IP는
$ kubectl exec kubia-7nog1 -- curl -s http://10.111.249.153
You’ve hit kubia-gzwlissh을 통해서도 비슷한 결과를 확인할 수 있음
double dash (--)는 kubectl 명령어의 끝을 알려준다. 이게 없으면 뒤에오는 command의 option과 kubectl의 option이 혼재되어 파싱에 문제가 생긴다.
$ kubectl exec kubia-7nog1 curl -s http://10.111.249.153 The connection to the server 10.111.249.153 was refused – did you specify the right host or port?kubectl의 -s 옵션은 다른 쿠버네티스 API 서버를 사용하라는 의미
- 위 그림의 요청 방식은 외부에서 서비스로 요청하는 방식과 그리 다르지 않음
- 기본적으로 서비스 프록시는 랜덤하게 Pod을 연결
- 이미 접속했던 Pod으로 계속 접속하게 하려면
sessionAffinity를 사용 - 값은 None(default)과 ClientIP이 가능
- 쿠버네티스는 payload가 어떤 프로토콜을 사용하는지 신경쓰지 않기에, 쿠키 기반의 친화도는 제공하지 않음
apiVersion: v1
kind: Service
spec:
sessionAffinity: ClientIPapiVersion: 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
- name: https
containerPort: 8443apiVersion: v1
kind: Service
spec:
ports:
- name: http
port: 80
targetPort: http
- name: https
port: 443
targetPort: https - (장점) 이렇게 port name을 사용하면, port name이 바뀌지 않는한 Service는 Port에 신경쓰지 않고 Pod만 바꿔주면 됨
- 그럼 클라이언트는 어떻게 서비스의 IP와 포트를 알 수 있을까?
- 서비스가 만들어지고 생성된 Pod의 환경변수를 확인
$ kubectl delete po --all
pod "kubia-7nog1" deleted
pod "kubia-bf50t" deleted
pod "kubia-gzwli" deleted- ReplicaController에 의해 생성될거고 Pod 하나 고르고 다음을 해보자
- 두개의 서비스가 있음
kubernetes, kubiakubectl get svc로 확인 가능
- 서비스 이름은 Underscore와 대문자로 변경됨
- 환경변수로는 IP와 Port는 알수 있으나, DNS는 모름!
- Pod은
kube-dns로도 불림 - (무슨말?) kube-system namespace 또한 이름이 같은 서비스에 대응됨
/etc/resolv.conf를 쿠버네티스가 관리해줌- 쿠버네티스의 DNS 서버(모든 서비스를 알고 있음)를 통해 DNS query가 수행됨(?)
- Pod 내부 DNS 사용 여부는 Pod.spec의
dnsPolicy를 통해 설정 가능 - 각 서비스는 내부 DNS 항목을 가져오고, 클라이언트 Pod은 서비스 이름을 알고 있으며 그것으로 정규화된 도메인 이름(FQDN, fully qualified domain name)에 접근 가능함
backend-database.default.svc.cluster.local
- backend-database는 서비스 이름
- default는 서비스가 정의 된 네임 스페이스
- svc.cluster.local은 모든 클러스터 로컬 서비스 이름에 사용되는 구성 가능한 클러스터 도메인 접미사
- 여전히 포트번호를 모르지만, 널리쓰이는 포트 번호를 사용하면 됨(HTTP 80, Postgres 5432)
- 직접 설정했다면, 환경변수로부터 알아내야함
default.svc.cluster.local은 생략가능(네임 스페이스와 suffix)
# 접속됨
$ kubectl exec -it kubia-3inly bash
root@kubia-3inly:/#
# 다음과 같이 kubia 서비스에 접근 가능
root@kubia-3inly:/# curl http://kubia.default.svc.cluster.local
You’ve hit kubia-5asi2
root@kubia-3inly:/# curl http://kubia.default
You’ve hit kubia-3inly
root@kubia-3inly:/# curl http://kubia
You’ve hit kubia-8awf3
# 생략 가능한 이유
root@kubia-3inly:/# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local ...- 서비스도 만들줄 알고 장하다
- 이제 하다보면 curl이 안되서, ping으로 확인해볼거다
root@kubia-3inly:/# ping kubia
PING kubia.default.svc.cluster.local (10.111.249.153): 56 data bytes
^C--- kubia.default.svc.cluster.local ping statistics ---
54 packets transmitted, 0 packets received, 100% packet loss- 서비스에 curl은 동작하는데, 왜 ping은 안될까?
- 서비스의 cluster IP가 가상 IP이기 때문이다
- 자세한 건 ch.11를 참고
- 삽질할까봐 미리 알려줌 ㅋ
- 서비스를 클러스터 내부 Pod로 리다이렉트가 아니라,
- external IP와 Port로 리다이렉트
- 이는 로드밸런싱이랑 서비스 디스커버리의 두 장점을 모두 가짐
- 클러스터 내의 Client Pod은 internal service와 동일하게 external service에 연결 가능
- 서비스는 Pod에 직접적으로 연결되지 않음
- 중간에
Endpoint리소스가 존재함 kubectl describe로 확인 가능
- Endpoints 리소스는 IP 주소와 서비스가 노출할 포트의 리스트
kubectl get endpoints kubia
$ kubectl get endpoints kubia
NAME ENDPOINTS AGE
kubia 10.108.1.4:8080,10.108.2.5:8080,10.108.2.6:8080 1h- Pod selector
- service spec에 정의가 되어있지만 들어오는 연결을 리다이렉트하는데 직접적으로 사용되진 않음
- 대신에, IP와 포트 리스트를 만드는데 사용됨
- 이는 Endpoints 리소스 내부에 저장됨
- 클라이언트가 서비스에 접속하면 서비스 프록시가 IP, 포트를 하나 선택하여 리다이렉트(?)
- Pod selector 없이 서비스를 만들면, Endpoint가 생성되지 않음
- selector 없이 어느 Pod을 포함시킬지 모름
- 직접 Endpoint를 서비스에 만들려면, 서비스와 Endpoint 모두 만들어야함
- Endpoints는 서비스와 별개의 리소스. 속성 같은게 아님
- Pod selector 없는 서비스 만든다고 생성되는게 아님
- 직접 만들어주자
- 서비스와 Endpoints 객체는 동일한 이름을 가져야함(따로 연결되는 속성이 없음)
- 위 구름모양의 Service는 Pod selector가 있는거 같은 서비스와 동일하게 동작함
- 그러나 외부의 서버를 가르키고 있음
- 로드밸런서, 서비스 디스커버리의 역할
- Service가 생성되고 난 후 생성된 Pod에는 환경 변수로 Endpoints가 가르키는 External server가 IP:Port로 들어있음
- External service를 쿠버네티스 클러스터로 편입시킬 때는, 서비스에 Pod selector만 붙여주면 됨
- 그 반대도 마찬가지!
- 서비스에서 Pod selctor를 제거하면 쿠버네티스는 Endpoint 업데이트를 중단함(?)
- 서비스가 변하는 실제 구현 동안 서비스 IP 주소는 동일하게 유지된다(???????????)
- 직접 Endpoint 안만들어되게 편한 메소드를 제공한다
- FQDN 써보자
- 서비스에
type: ExternalName을 설정 api.somecompany.com라는 공개된 API가 있다고 가정
external-service.default.svc.cluster.local또는external-service로 연결 가능- 외부 서비스를 요청하는 Pod에게 실제 서비스의 이름이나 위치를 은닉할 수 있음
- 이로써, 서버 정의나, 다른 외부 서비스를 가르키도록 언제나 바꿀 수 있음
- externalName을 바꾸거나
- type을 ClusterIP로 바꾸고 pod selector에 맞는 Endpoints를 만들어서
- ExternalName 서비스는 DNS level에서만 구현됨
- CNAME DNS 레코드가 서비스에 대해 생성됨
- 서비스 프록시로 외부 서비스에 바로 붙기 때문에 이 유형의 서비스는 ClusterIP를 제공하지 않음
- CNAME 레코드는 IP가 아니라 FQDN을 가르킴
- 지금까지 클러스터 내부에서 Pod이 어떻게 서비스를 소비할지에 대해서만 알아봤음
- 그런데 프론트 엔드 같은 서비스는 외부에 노출되어야함
서비스가 밖에서 접속 가능하게 하는 방법이 몇가지 있음
type: NodePort서비스- 클러스터 노드가 포트를 열고, 해당 포트의 서비스로 리다이렉트. ClusterIP와 port로도 되고, dedicated port로도 가능
type: LoadBalancer서비스(NodePort의 확장)- 서비스가 쿠버네티스가 동작하고 있는 클라우드 환경의 프로비저닝된 dedicated load balancer가 되도록함. 로드밸런서는 모든 노드에서 노드 포트로 리다이렉트. 클라이언트는 로드밸런서의 IP를 통해 서비스로 연결.
- Ingress 리소스를 만듬
- 획기적으로 다른 매커니즘인 Ingress는 여러 서비스를 하나의 IP로 노출시킴
- HTTP level에서 동작(network layer 7)
- 따라서 layer 4에서보다 더 많은걸 할 수 있음
- 5.4에서 설명할꺼임
$ kubectl get svc kubia-nodeport
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubia-nodeport 10.111.254.223 <nodes> 80:30123/TCP 2m-
EXTERNAL-IP를 보면
<nodes>라고 되어있음 -
서비스가 어느 클러스터 노드로부터 접근 가능함을 의미
-
cluster IP 내부 포트 (80), node port(30123)으로 모두 접근 가능
- 10.11.254.223:80
- <1st node’s IP>:30123
- <2nd node’s IP>:30123, and so on.
- node port로 서비스에 접근하려면, GCP 같은 쿠버네티스가 올라가있는 클라우드 플랫폼의 방화벽 설정에서 node port에 대한 연결을 허용해야함
$ gcloud compute firewall-rules create kubia-svc-rule --allow=tcp:30123
Created [https://www.googleapis.com/compute/v1/projects/kubia1295/global/firewalls/kubia-svc-rule].
NAME NETWORK SRC_RANGES RULES SRC_TAGS TARGET_TAGS
kubia-svc-rule default 0.0.0.0/0 tcp:30123- 이로써 node port 30123으로 접속이 가능하지만 IP를 알아야 한다
$ kubectl get nodes -o jsonpath='{.items[*].status.
➥ addresses[?(@.type=="ExternalIP")].address}'
130.211.97.55 130.211.99.206$ curl http://130.211.97.55:30123
You've hit kubia-ym8or
$ curl http://130.211.99.206:30123
You've hit kubia-xueq1
- 그런데 처음 요청된 노드가 fail하면 서비스에 접근 할 수 없음
- 따라서, 로드 밸런서가 앞에 위치하여 모든 노드에 요청을 분산시키고, 오프라인 노드로 요청을 보내지 않아야함
- 로드 밸런서를 알아보자
- 보통, 클라우드 인프라 provider가 로드 밸런서 프로비전을 지원함
- 해야되는 건
LoadBalancer서비스를 만드는 것 - 로드 밸런서 프로비전을 지원하지 못하는 환경에서는
NodePort로 동작함 LoadBalancer가NodePort의 확장이기 때문임- 미니 쿠베에서는 작성 당시 기준으로 안됨!
- NodePort는 설정하지 않음
- 할수 있지만, 쿠버네티스가 고르게 함
$ kubectl get svc kubia-loadbalancer
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubia-loadbalancer 10.111.241.153 130.211.53.173 80:32143/TCP 1m- 서비스 만드는데 시간이 좀 걸릴거고 로드 밸런서 서비스를 확인해보면 이렇다
- EXTERNAL-IP
130.211.53.173을 통해 접속 가능!
$ curl http://130.211.53.173
You've hit kubia-xueq1- 로드 밸런서를 이용하면, 방화벽 설정이 필요없음
- 로드 밸런서 자체가 외부에 노출됨을 가정한 서비스이기에 cloud provider가 알아서 해줄거 같음
웹브라우저로 요청이 왜 같은 Pod으로 되는걸까?반면, curl은 매번 다른 Pod으로 접속된다.
kubectl explain을 통해서, 서비스의 session affinity가 None으로 꺼져있는 것을 확인했다.이는 keep-alive connection이 하나의 연결을 통해 계속 요청하기 때문이다. curl은 매번 연결로 새로운 요청을 보낸다. 서비스는 connection level에서 동작하기에 모든 네트워크 패킷은 하나의 pod로 전송된다. 따라서 session affinity를 설정하지 않아도, 유저는 연결이 끊길 때까지, 같은 pod으로 접속한다.
- 외부 클라이언트가 80 포트로 접속하여도, 로드 밸런서가 임의로 설정된 내부의 NodePort로 연결하고 하나의 Pod과 연결된다.
- LoadBalancer 서비스는 NodePort 서비스의 확장이므로,
kubectl describe로 NodePort가 설정된 것을 확인할 수 있다. 그리고 NodePort의 방화벽을 열면 NodePort로도 접근가능하다. - 미니 쿠베라면 로드 밸런서 서비스는 NodePort로만 접근 가능하다.
외부 연결로 인한 알아야할 특성을 설명한다.
-
NodePort나 LoadBalancer에 외부 클라이언트가 연결하면, 임의로 선택된 Pod은 요청을 받은 노드일수도 있고, 아닐 수도 있다.
-
다른 노드로 접근할 때는 추가적인 network hop을 필요로 하지만, 이상적인 형태는 아니다.
-
추가적인 네트워크 홉을 막기 위해, 연결을 받은 노드로만 리다이렉트하도록 변경할수 있다.
-
서비스 spec의
externalTrafficPolicy필드를 설정 -
spec: externalTrafficPolicy: Local ...
-
해당 노드에 Pod이 없으면 연결이 끊어짐
- annotation을 사용하지 않았을 때, 랜덤 글로벌 Pod으로 전달하지 않음(?)
- 따라서 Pod이 있는 노드인지 확인 필요
-
annotation의 단점
- Node가 다른 갯수의 Pod을 가지고 있을 때,
- Node로 봤을 때는 트래픽이 균등하게 나뉘는데, Pod 단위에서는 아닐 수 있음
- 클러스터 내부 클라이언트가 서비스에 연결하면 IP를 알 수 있음
- 그러나, NodePort를 통해 연결하면
SNAT(Source Network Address Translation)에 의해, 패킷의 Source IP가 변경됨 - 클라이언트 IP 확인이 필요한 어플리케이션에서는 문제가 될 수 있음
- 이전 section에 설명된
Local external traffic policy은 연결을 받은 노드와 Target pod을 호스팅하는 노드 간에 추가적인 네트워크 홉을 필요로하지 않으므로(SNAT가 수행되지 않음), client IP가 보존됨
DEFINITION Ingress (noun)—The act of going in or entering; the right to enter; a means or place of entering; entryway.
각 LoadBalancer 서비스는 public IP가 하나씩 필요하지만, Ingress는 수십개의 서비스더라도 하나만 필요로 한다.
- 클라이언트가 HTTP로 요청한 host와 path로 어느 서비스로 전달할지 결정함
- Ingress는 HTTP의 application layer에서 동작
- 서비스에서 불가능한, 더 많은 기능
- 쿠키 베이스 session affinity도 제공
- Ingress 기능을 살펴보기 전에 Ingress 리소스가 동작하려면,
- Ingress controller가 클러스터에서 동작해야함
- Cloud Provider에 따라 Ingress controller가 동작하지 않을 수 있음(?)
- 미니 쿠베에서는 add-on으로 Ingress를 켤 수 있음
- Cloud Provider에 따라 Ingress가 가르켜야할 리소스에 제한이 있을 수 있음
- GKE에서 Ingress는 NodePort를 가르켜야함
$ kubectl get ingresses
NAME HOSTS ADDRESS PORTS AGE
kubia kubia.example.com 192.168.99.100 80 29m- ADDRESS를 사용
- /etc/hosts
- C:\windows\system32\drivers\etc\hosts on Windows
192.168.99.100 kubia.example.com$ curl http://kubia.example.com
You've hit kubia-ke823$ openssl genrsa -out tls.key 2048
$ openssl req -new -x509 -key tls.key -out tls.cert -days 360 -subj
➥ /CN=kubia.example.com$ kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key
secret "tls-secret" created$ curl -k -v https://kubia.example.com/kubia
* About to connect() to kubia.example.com port 443 (#0)
...
* Server certificate:
* subject: CN=kubia.example.com
...
> GET /kubia HTTP/1.1
> ...
You've hit kubia-xueq1--------------- 하루의 목표----------------