외부 서비스에서 외부 클라이언트로...(Nodeport, Loadbalancer, Ingress)

[서비스가 외부에서 액세스 가능하게 하는 방법]

 

ㅇ. NodePort 서비스 타입으로 설정하기

   - NodePort 서비스의 각 클러스터 노드는 노드 자체 이름을 통해 port를 열고 port에서 발생한 트래픽을 서비스로 Redirect함.

 

ㅇ. LoadBalancer 서비스 타입으로 설정 하기

  - Kubenetes가 실행 중인 클라우드 인프라스트럭처에 provision된 지정된 LoadBalancer를 통해 서비스 액세스 가능

 

ㅇ. Ingrea Resource 생성하기

  - HTTP fpqpf(네트워크 7계층) 수준에서 동작하기 때문에 4계층 서비스보다 좀 더 기능을 제공

 

1. NodePort 서비스

 

ㅁ NodePort 서비스 생성

 

apiVersion: v1
kind: Service
metadata:
    name: kubia-nodeport
spec:
    type: NodePort
    ports:
    - port: 80
      targetPort: 8080
      nodePort: 30123
    selector:
      app: kubia

 

외부 클라이언트 노드 1 혹은 노드 2를 통해 NodePort Service로 연결

 

2. LoadBalancer 서비스

 

Loadbalancer는 자신만의 고유하면서 외부에서 액세스 가능한 IP한 IP 주소를 갖고 모든 연결을 서비스로 리다이렉트함.

Loadbalancer 서비스는 AWS, Azure, GCP등의 주요 CSP에서는 제공하나 minikube에서는 이 기능을 제공하지 않는다.

 

ㅁ LoadBalancer 타입 서비스 정의

 

apiVersion: v1
kind: Service
metadata:
     name: kubia-loadbalancer
spec:
    type: LoadBalancer
    ports: 
    - port: 80 
       targetPort: 8080 
    selector: 
       app: kubia

 

Loadbalancer 서비스로 연결하는 외부 클라이언트

 

3. 인그레스 리소스를 이용해 외부로 서비스 노출

 

 - Ingress(명사) - 가거나 들어가는 행위; 들어갈 수 있는 권리; (어떤 장소에) 들어감; 입장권

 

[인그레스 필요한 이유]

 

인그레스가 필요한 가장 중요한 이유는 각 LoadBalancer 서비스는 그 자신만의 외부 IP를 갖는 자체 로드 밸런서를 요구

하지만 인그레스는 수십가지 서비스에 액세스를 제공하

 

 

ㅁ 인그레스 리소스 생성

 

kubia-ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: kubia
    spec:
      rules:
      - host: kubia.example.com
       http:
        paths:
        - path: /
         backend:
           serviceName: kubia-nodeport
           servicePort: 80

 

 

kubia.example.com으로 요청은 80 포트의 kubia-nodeport 서비스로 보내지고 그러한 모든 HTTP 요청이 인그레스 컨트롤러를 통해 수신되도록 하는 하나의 규칙을 갖는 인그레스를 정의

 

* 위의 yaml(GKE 기반)에서 ingress가 nodeport 서비스를 가리키도록 요구한다. 하지만 쿠버네티스 자체 요구 사항은 아님

 

ㅁ 인그레스를 이용한 서비스 액세스

 

도메인 이름이 인그레스 컨트롤러의 IP와 매핑되는지 확인해야 함

 

$ kubectl get ingress

을 통해 IP를 확인 후 /etc/hosts 파일에 해당 IP와 URL 추가

 

ㅁ 인그레스 동작 방식

1. 클라이언트는 처음으로 kubia.example.com에 대하여 DNS 룩업을 하고 DNS 서버는 인그레스 컨트롤러의 IP를 반환 

2. 클라이언트는 HTTP 요청을 인그레스 컨트롤러로 보내고 Host 헤더에 kubia.example.com을 지정 

3. 이 헤더에서 컨트롤러는 클라이언트가 액세스하려고 하는 서비스를 결정하고, 서비스와 연관된 엔드 포인트 객체를 통해 포드 IP를 조회한 다음 클라이언트 요청을 포드 중 하나로 전달 

 

ㅁ 하나의 인그레스로 다수의 서비스 노출

 

동일한 호스트의 서로 다른 서비스를 다른 경로로 매핑 하기 

.... 
- host: kubia.example.com 
http: paths: 
- path: /kubia 
   backend: 
       serviceName: kubia  #kubia.example.com/kubia의 요청은 /kubia서비스로 라우팅된다.
       servicePort: 80 
- path: /bar 
   backend: 
       serviceName: bar     #kubia.example.com/bar의 요청은 /bar서비스로 라우팅된다. 
       servicePort: 80 

 

 

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

spec: 
    rules: 
    - host: foo.example.com   #foo.example.com의 요청은 서비스 foo로 라우팅될 것이다. 
      http: 
        paths:
         - path: /
           backend: 
                serviceName: foo
                servicePort: 80. 
    - host: bar.example.com   # bar.example.com의 요청은 서비스 bar로 라우팅될 것이다.
       http:
         paths:
         - path: / 
           backend: 
               serviceName: bar
               servicePort: 80

 

 

ㅁ TLS 트래픽을 처리하기 위한 인그레스 설정

 

Ingress Controller가 쿠버네티스 환경에서 TLS의 모든 것에 관여할 수 있도록 하려면 TLS의 인증서와 개인키를 덧붙여야 하며 이 두가지는 Secret 리소스에 저장됨

 

$ 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

 

TLS 트래픽을 핸들링하는 인그레스: kubia-ingress-tls.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: kubia
spec:
    tls:
    - hosts:
       - kubia.example.com
      secretName: tls-secret
    rules:
- host: kubia.example.com
  http:
    paths:
    - path: /
       backend:
       serviceNAme: kubia-nodeport
       servicePort: 80

 

$ curl -k -v https://kubia.example.com/kubia