[k8s] Service 리소스 Overview (2) : Ingress와 Health check

저번 글에 이어 Ingress와 Health check를 정리했다.

Ingress

• 쿠버네티스 Ingress 리소스를 통해 HTTP 트래픽을 여러 Service 로 전달할 수 있다.
• 우선 실제로 트래픽을 보고 처리해야 하는 Ingress Controller 가 필요하다. 대표적으로 오픈소스 웹서버인 nginx 구현체인 Nginx Ingress Controller 가 존재한다.
• https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/
  • 구글의 쿠버네티스 서비스인 GKE 는 자체적으로 구현한 ingress-gce 가 존재한다.

• 접근하는 트래픽에 대해 어떻게 처리할지에 대해서 관리하는게 Ingress 리소스이다.

인그레스 컨트롤러

 

• metadata 의 annotations 를 이용해 인그레스 오브젝트에 대한 옵션을 설정할 수 있다.
  • nginx 의 경우 nginx.ingress.kubernetes.io/rewrite-target 같은 옵션이 존재한다.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-test
  annotations:
  ...
spec:
  rules:
    - host: test.example.com
    http:
        paths:
        - path: /test
            backend:
                service:
                    name: test
                    port:
                        number: 80

 

• 이 Ingress 리소스의 경우 Ingress Controller 가 받는 트래픽 중
  • 요청의 Host 헤더가 test.example.com 인 요청에 대해 test 서비스의 80 포트로 보내진다.
• 하나의 Ingress 에 다양한 rules 와 path 를 사용할 수 있다.
  • GCP 에서 사용하는 Cloud Load Balacer 는 url map 이란 리소스가 해당 역할을 담당한다.
    • ingress-gce 레포에 pkg/loadbalancer/url_maps 로 확인할 수 있다.

Ingress TLS

• Ingress Controller 는 HTTPS 트래픽을 받아 TLS Connection 을 열고 백엔드에 위치한 서비스들에는 HTTP 트래픽으로 전송한다.(Terminate TLS)
• TLS 연결에 사용되는 서버 인증서는 발급받은 뒤 Secret 리소스를 사용하여 저장할 수 있다.

openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.cert -days 360 -subj \
CN=test.example.com

kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key

 

• 또는 CSR 을 생성해서 CertificateSigningRequest 리소스를 통해 발급받아도 된다고 한다.

kind: Ingress
...
spec:
    tls:
    - hosts: 
        - test.example.com
        secretName: tls-secret
...

 

annotation 중 nginx.gress.kubernetes.io/ssl-redirect 기본값은 True 다. 즉 HTTP 로 요청을 보내도 tls 가 존재하면 HTTPS 로 리다이렉트한다.

Health check

• Service 의 labelSelector 에 맞는 Pod 들은 자동으로 서비스의 Endpoint 리소스로 등록된다. 하지만 Pod 가 생성된 뒤 Configuration이 필요하거나 등의 warm-up 절차가 있다면 Service 는 해당 Pod 로 요청을 보내서는 안될것이다. 이를 위해 Readiness Probe가 존재한다.

Readiness Probes

• Pod 가 클라이언트의 요청을 받아들일 수 있는지 확인하기 위해 존재한다.
• 주기적으로 호출되어 Pod 가 요청을 받을 수 있는지 확인한다.
• Container 마다 요청을 받을 수 있다는 상태는 다르다. 쿠버네티스는 3가지 종류를 지원한다.
  • HTTP GET probe : 요청을 보내 HTTP Status code를 보고 확인한다.
  • TCP Socket : 컨테이너의 특정 port로 소켓을 오픈한다. Established 면 Ready 상태.
  • Exec probe : 컨테이너에서 프로세스를 실행해 Exit status code를 참조한다.
• Liveness Probe 와 달리 실패해도 Pod를 재시작하지는 않는다.