[Docker/K8S] 웹 서비스를 GKE로 배포하기(4) - Gateway API로 배포하기

이번에 업무과정에서 썼던 툴들을 정리해보면서 k8s 웹 배포를 작년에 했던 기억을 되살려 다시 공부해보면서 포스팅하기로 했다. 지난 포스팅에서는 DB 설정에 필요한 파일들을 만들어보면서 PV, PVC, configmap 등 내가 헷갈렸던 것들을 정리해보는 시간을 가졌다. 이번 포스팅에서는 kubernetes의 네트워킹에 대해서 간단히 알아보고, ingress와 gateway에 대해 정리하고, 나의 삽질(...)을 기록하도록 하겠다.

목표

• GKE(Google Kubernetes Engine)와 GCE(Google Compute Engine) 등을 활용한 풀스택 웹 서비스 배포하기
  1. docker file 구성하기
  2. kubectl 활용하기
  3. 쿠버네티스 구성에 관한 이해 및 적용
     • Deployment
     • StatefulSet
     • Persistent Volume
     • Service
     • Gateway 

 

1. Kubernetes 네트워크

쿠버네티스(Kubernetes) 네트워크 정리

• 위 글을 참고해 공부했습니다. 좋은 글 감사합니다.

• 순서로 따지면 gateway를 적용하려고 하다가 너무 안돼서 네트워크가 어떻게 이루어졌는지 다시 돌아가서 확인했다고 보는 것이 옳은데, 내가 중점적으로 본 것은 다섯 가지이다.

A. Docker container 간의 네트워킹

• 도커의 경우 각각의 container가 가상 네트워크 인터페이스를 고유하게 가져가 ip 주소가 다르다.
• 그러나 하나의 가상 네트워크 인터페이스 안에 묶여있기 때문에 이걸 통해서 통신이 가능하다.
• ex) eth0 = 10.100.0.2 일 때, docker network interface = 172.17.0.1 이라고 한다.
  • 이때 container 1 = 172.17.0.2  /  container 2 = 172.17.0.3
  • 이렇게 docker network interface에 묶인 채로 서로 다른 ip 주소를 가진다.

 

 B. K8S pod 내부의 네트워킹

• kubernetes의 pod를 보면 하나의 가상 네트워크 인터페이스에 두 개의 container가 동시에 할당되어 있다(ip 주소같음).
• 따라서 pod 내부에서는 port 번호로 서로를 구분한다. 
• pod에 네트워크 인터페이스를 제공해주는 특수 컨테이너를 pause 라고 부르며, 이 컨테이너는 pod마다 존재한다.

 

C. Pod 간의 네트워킹

• kubernetes에서 kubenet이라는 네트워크 플러그인을 제공하긴 하지만 CNI 스펙을 준수하는 다른 플러그인 사용을 권장한다.
• 각각의 pod는 고유한 ip 주소를 가진다.
• 따라서 kubenet 혹은 다른 네트워크 인터페이스(플러그인)을 사용해서 ip로 통신이 가능하다.
• 아예 Node가 다른 pod의 경우에는 라우터를 거쳐야한다.

 

D. Pod to Service 네트워킹

• 지난 번에도 이야기했듯이 pod는 계속 변하고 대체되기 쉬우므로 pod to pod 연결에는 의미가 없다. 새로 생성됐을 때 이전과 ip가 같을 것이란 보장도 없고(statefulset이 아니라면)
• 때문에 서비스로 reverse proxy 혹은 loadbalancer를 올려서 해결했다.
  • 클라이언트에서 proxy로 연결하면 서버 목록을 관리하면서 살아있는 pod로 트래픽을 연결한다.
• pod와 동일하게 service도 가상 ip인데, pod 네트워크는 가사아 이더넷 네트워크 인터페이스가 있어서 ifconfig가 동작하지만 service에서는 불가능하다.(당연함)
• 예시와 같이 보자.

예시!

• (같은 클러스터 내) 서로 다른 두 개의 워커 노드가 있고, 하나의 게이트웨이/라우터로 연결되어 있다. 서비스는 아래와 같다.

apiVersion: v1
kind: Service
metadata:
	name: service-test
spec:
	selector:
    	app: server-pod1
    ports:
    	- protocol: TCP
          port: 80
          targetPort: 8080

• 한 쪽의 워커 노드에서 다른 쪽으로 요청을 보내면서 ip를 찾는 과정을 한 번 확인해보자.

1.  client pod가 http request를 service-test라는 dns 이름으로 요청한다.
2. 클러스터 dns 서버가 해당 이름을 service ip로 매핑해준다.
3. http client가 dns 서버로부터 ip를 받아 ip 주소로 최종 요청을 보낸다.

• 여기까지가 ip 주소를 얻는 방법이다. 이제 ip 주소로 목적지를 찾는 과정을 보자.

• ip 네트워크는 자신의 host에서 목적지를 찾지 못하면 상위 게이트웨이로 패킷을 전달한다.
• client pod에서 시작했다고 할 때, 목적지 주소가 10.3.241.152라면 veth1에 맞지 않으니 cbr0으로, cbr0에서 eth0으로, eth0에서 router로 간다.
• 그러면 결국에는 못 찾는 거 아닌가? 싶은데, 실제로는 패킷 목적지 주소가 변경되어 server pod 1을 찾아간다.
• 왜일까???

 

Kube-proxy

• 얘가 그 이유다. 
• kubernetes는 netfilter와 iptables로 패킷 흐름을 제어한다.
  • netfilter : 룰 베이스 패킷 처리 엔진. 오고 가는 패킷의 생명주기를 확인하고 규칙에 맞는 패킷이 있으면 정해진 action을 수행한다.
    • 이 action 중에 Destination NAT라는 목적지 주소 변경 action이 있다.
  • iptables : netfilter를 사용해서 chain rule이라는 규칙을 지정하고, 패킷을 포워딩하도록 네트워크를 설정한다.
• kubernetes는 이 netfilter를 proxy 형태로 사용한다.
  1. kube-proxy가 localhost에서 서비스 요청을 받기 위해 포트를 연다.
  2. kube-proxy가 netfilter로 service IP로 들어오는 패킷은 kube-proxy 자신에게 오게 설정한다.
  3. kube-proxy로 온 요청을 실제 server pod의 ip:port로 전달한다.
• 다만 이렇게 user space에서 proxying하는 것은 패킷을 다시 user에서 커널로 변환하는 비용이 발생한다.

>> iptable을 대신 사용하기!

• kube-proxy가 proxy 역할을 하지 않고 netfilter에게 전체를 다 맡기고, 규칙 수정만 한다.
• kube-proxy는 마스터 노드 api server에서 정보를 받기 때문에 클러스터 변화를 감지해서 살아있는 서버 pod를 알 수 있다. 알게되면 iptables를 업데이트 해서 규칙을 갱신한다.
  • 마스터 노드 api에서 health check를 하는 법 = kubelet

 

E. 외부와 Service 간의 네트워킹

• 여태까지는 cluster 내부통신이었다. 
• 외부 통신이 가능한 service 타입은 두 개다. 

1. NodePort

• 노드 네트워크 ip로도 접근 가능하고, cluster ip로도 이 서비스에 접근할 수 있다.
• nodeport가 생성될 때 kube proxy가 네트워크 인터페이스에 30000~32767 사이 포트를 할당한다.
• 이 포트로 외부에서 요청이 들어오면 매핑되어 있는 cluster ip로 전달한다.

2. Load Balancer

• 외부 클라우드 서비스를 사용해서 프로비저닝할 수 있는 경우에 사용한다.
• 외부 로드밸런서 트래픽이 클러스터 내의 pod로 전달되는 방식이고, 클라우드 제공 업체 쪽에서 동작을 결정한다.

 

2. Ingress와 Gateway API

A. Ingress

• 쿠버네티스 클러스터 외부의 HTTP/HTTPS 트래픽을 클러스터 내 서비스로 라우팅한다.
• 단일 IP 주소로 외부에서 접근해서 클러스터 내부 여러 서비스로 트래픽을 분산시킨다.
  • url 경로 설정 / SSL, TLS로 보안 설정 / 로드밸런싱 등의 역할도 수행한다.
• ingress api
  • 쿠버네티스에서 ingress 리소스 정의를 위해 사용하는 api로, 우리가 작성하는 yaml 구성 파일로 설정한다.
• ingress controller
  • ingress api와 리소스에서 정의한 규칙을 구현하고 실행하는 소프트웨어이다.
  • 여기서 실제로 트래픽을 처리한다.
  • nginx controller가 대표적이다.
• ingress controller - ingress가 하나의 짝이다.

 

B. Gateway

• 서비스 네트워킹을 위한 오픈소스 표준.
• ingress의 한계 극복을 위한 Multi Tenant network routing solution이다.
  • ingress는 crds(custom resource definition)을 직접 다 적어주어야한다는 한계가 있다.
• 여러 유형의 Layer 7 리소스를 쉽게 관리할 수 있게 해준다.
  • 멀티 테넌트 지원 = 클러스터 한 개에서 여러 사용자가 독립적으로 네트워크 트래픽 관리 가능
  • TCP, UDP 까지 확장 지원
  • 세분화된 트래픽 정책 설정 가능
• gateway class에는 여러가지가 있는데, 예를 들어보면
  • gke-l7-regional-external-managed(리전 외부 애플리케이션 부하 분산기)
  • gke-l7-regional-external-managed-mc(리전 외부 멀티클러스터 애플리케이션 부하 분산기)

출처 :(https://www.bespinglobal.com/google-cloud-insight/gateway-api/)

• Ingress와 비교해보았을 때, Ingress는 url routing까지 처리해서 service와 바로 연결한다.
• gateway의 경우 gateway api와 routeing 부분이 분리되어 있으므로 유지보수가 좀 더 쉽다는 것이 장점이다.

C. GatewayAPI 와 HTTPRoute 설정

Gateway API

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: http-gateway
  namespace: web
spec:
  gatewayClassName: gke-l7-regional-external-managed 
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same

• gateway api 설정파일을 분석해보자.
• 먼저 apiVersion이 gateway.networking.k8s.io/v1 이다. 이전과는 다르니 느낌이 팍팍 오겠지만, 이 말은 gateway api는 추가 설치가 필요하다라는 것이다.
• 만일 클러스터 생성 시에 고급 네트워킹 탭에서 gateway api를 설정했다면 자동으로 설치를 해주므로 추가 설치를 할 필요는 없다. 
• 설치 명령어는 아래와 같다.

gcloud container clusters update <YOUR_CLUSTER_NAME> --region=<YOUR_REGION> --gateway-api=standard

• 설치 후 아래 명령어를 실행하면 설치된 gateway class들을 확인할 수 있다. 

kubectl get gatewayclass

• spec.gatewayClassName에 이 class 중 하나를 적는데, 나는 리전 외부 애플리케이션 부하 분산 gateway api를 원하므로 gke-l7-regional-external-managed 를 선택했다. 멀티클러스터라면 mc 가 붙은 클래스를 선택하면 된다.
• spec.listeners는 트래픽 처리 인프라 인스턴스가 어느 트래픽을 어느 포트에서 수신할 것인지를 적는다. 지금 예제에서는 HTTP 프로토콜을 포트 80번에서 수신하도록 했다. 
  • allowRoutes는 어디로 가는 라우팅을 허용할 것인지 제약을 준다. 지금의 경우 같은 namespace 안에 있는 서비스로 라우팅이 가능하도록 제한해두었다. 
  • 이는 뒤에 라우팅 규칙을 지정하는 HTTPRoute에서 지정하는 포트나 service 정보가 다른 요소와 중복되더라도 같은 namespace 안에 있는 service에 라우팅하도록 한다.

HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: web
spec:
  hostnames:
    - bunny-bun.me
  parentRefs:
    - name: http-gateway
      group: gateway.networking.k8s.io
      kind: Gateway
      sectionName: http
  rules:
    - matches:
    	- path:
            type: pathPrefix
            value: /
      backendRefs:
        - port: 80
          name: server-svc

• HTTPRoute도 같은 apiVersion을 사용한다. 
• spec.hostnames에는 dns 주소가 들어간다. 나는 내가 가지고 있는 주소 bunny-bun.me 를 넣었다.
• parentRefs에는 등록한 gateway api를 지정해서 이 gateway의 라우팅 규칙임을 딱 정해준다. 
  • 맞는 이름, group(api version), kind를 작성해주고 sectionName에 프로토콜을 적는다.
• rules는 gateway로 들어온 어떤 조건에 맞는 트래픽이 어느 서비스와 포트로 갈 것인지 규칙을 정해준다. 
  • rules.matches.path는 hostname 뒤 경로가 value와 type으로 설정한 것에 맞는 경로를 통과시킨다. 이 규칙에 맞아야 아래 서비스로 라우팅된다.
  • rules.matches.backendRefs는 포트 번호와 서비스를 연결한다. 이 gateway 로 들어온 트래픽이 어느 서비스의 어떤 포트로 가는지를 정해준다. 여러 개의 서비스를 연결해서 트래픽을 퍼센트 단위로 분산할 수도 있다. 이 경우에는 weight 옵션을 사용한다.
• rules에서 여러 backendRefs와 matches를 설정할 수 있는 것이 Ingress보다 Gateway가 더 유연하고 강력한 트래픽 라우팅 기능을 사용할 수 있는 이유이다.
• matches는 비단 경로 뿐 아니라 다른 것들도 설정할 수 있다. 

rules:
  - matches:
    - method: POST
      - headers:
        - name: user-type
          value: admin
    backendRefs:
      - name: admin-api-svc
        port: 80

• 위 예시에서 보면, 요청이 POST 이고 header에 user-type=admin 일 때, 이 rule을 적용하여 admin-api-svc의 80번 포트로 전달하라고 되어 있다. 이런 식으로 세밀한 트래픽 흐름을 선언적으로 정의하는 것이 가능하다.

 

3. 적용 중에 마주한 오류들과 해결 방안

예전에 K8S를 사용했을 때는 nginx ingress controller를 사용해서 ingress로 배포를 했었기 때문에 GatewayAPI로는 처음 라우팅해보게 되었다. 따라서 굉장히 많은 오류들을 마주하게 되었으므로 그 삽질 기록을 한 번 공유해보려고 한다. 

a. Fault filter abort

우선 처음 Gateway API와 HTTPRoute를 올렸을 때 마주한 에러이다. hostname으로 연결하지 않고 gateway에 할당된 외부 ip 주소로 접속했는데 웹 페이지에 딱 이것만 뜨고 아무 정보값이 없었다. 찾아보니까 gateway 쪽에서 연결된 백엔드 서비스의 health check에 실패하면 이런 문제가 발생한다고 한다.

시도한 방법 1

때문에 fastapi pod가 죽었는지 확인하기 위해서 health check를 배포했다.

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: fastapi-health-policy
  namespace: web
spec:
  targetRef:
    group: ""
    kind: Service
    name: server-svc
  default:
    config:
      type: HTTP
      httpHealthCheck:
        port: 8080
        requestPath: /

• targetRef에 health check를 할 서비스를 지정하고, default의 config 하위에 health check 방법을 설정했다.
• 이 경우에는 HTTP 트래픽으로 8080 port, 경로  / 로 health check를 수행한다.

이 구성파일을 적용시킨 뒤에 health check를 진행한다.

kubectl describe healthcheckpolicy fastapi-health-policy -n web

가장 아래 events 와 conditions 항목을 확인해보면, 

Gateway는 잠시 내렸으니 없는 것이 맞고, event도 normal 인 것을 보면 pod 자체에는 문제가 없이 살아있는 것을 확인할 수 있었다. 

시도한 방법 2 

Gemini와 토론해봤을 때 방화벽 문제일 가능성이 있다고 해서 pod로 연결되는 8080 port TCP를 열어주었지만 해결되지 않았다. 굳이 방법을 공유하지 않는다...

해결 방안 1

결론부터 말하자면 service type이 loadbalancer이면 안된다. 반드시 Cluster IP로 설정되어야 한다. 이유는 아래와 같다.

• server service를 loadbalancer 타입으로 설정하면 GCP L4 network loadbalancer가 생성된다.
• 여기에 gateway가 GCP L7 HTTP(S) loadbalancer를 사용하면 L4-L7 이중화가 발생한다
  • 원래 L4-L7 연결이 안되는 건 아니다.(HA프록시 등) 그런데 gcp 관리형 서비스+k8s 컨트롤러 설계가 겹치면서 문제가 발생한다.
  • 기본적으로 L7 게이트웨이 로드밸런서는 pod에 직접 health check를 할 것이라고 생각한다.
  • 그러나 L4 Loadbalancer 로 설정된 서비스가 있기 때문에 pod에 직접 닿는 것이 아니라 L4 Loadbalancer ip를 백엔드로 참조하게 된다. 그러면 health check 요청을 받았을 때 pod로 전달하기 위해 추가 레이어가 생성된다.
  • L4와 L7의 health check port 혹은 경로가 다르거나, L7이 참조를 잘못해서 실제 pod의 리스닝 포트에 닿지 못하면 unhealthy 상태가 리턴된다.
  • 그러면 fault filter abort를 뱉는다!!
• +) gke gateway api는 gcp의 gateway controller에서 아예 cluster ip에서 pod ip를 뽑아서 직접 L7에 붙이지 않으면 유효하지 않다고 판단한다.

b.  An active proxy-only subnetwork is required in the same region and VPC as the forwarding rule.

이쯤에서 의심되는 걸 다 하나씩 바꿔보고 있었는데, 이때 gateway class를 global에서 regional으로 변경해보았다(cluster가 regional이니 어쨌든 혹시나 해서)

그랬더니 새로운 에러가 발생했다!

Gateway: Invalid : error cause: gceSync: generic::invalid_argument: Insert: Invalid value for field 'resource.target': 'regions/us-central1/targetHttpProxies/gkegw1-jst4-web-http-gateway-bqvswgdmrblp'. An active proxy-only subnetwork is required in the same region and VPC as the forwarding rule.

에러메세지는 있는 게 없는 것보다 백 배 낫다.

읽어보니 같은 region에 프록시 전용 서브넷이 있어야한다고 한다. 그런데 같은 Loadbalancer인데 왜 L4 loadbalncer에서는 없어도 됐을까?

• L4는 헤더 검사를 하지 않는다. 따라서 프록시 서브넷이 따로 필요가 없다. 바로 노드 ip로 직접 전달되기 때문이다.
• 반면 L7 gateway loadbalancer의 경우에는 트래픽을 처리할 프록시 배치공간이 반드시 필요하다.

해결 방법

서브넷 프록시를 등록한다. 프록시 등록 전에 확인해야할 것은, 현재 cluster가 속한 vpc 네트워크 대역과 다른 대역을 선택해야한다는 것이다. 따라서 현재 network 대역을 확인해봐야한다. 먼저 vpc 네트워크 이름을 확인해보자.

gcloud container clusters describe <cluster-name> --region <region> --format="value(network)"

이렇게 하면 네트워크 이름만 따낼 수 있다. 이제 대역을 확인해보자.

gcloud compute networks subnets list -- network <network-name>

실행하면 현재 클러스터 vpc 네트워크 대역을 알 수 있다. 나의 경우 10. 대였기 때문에, subnet 대역은 192.168 혹은 172.16 대역을 선택하면 된다.

gcloud compute networks subnets create gke-proxy-subnet-<REGION> 
	\ --region=<REGION> 
        \ --network=<NETWORK_NAME> 
        \ --range=192.168.0.0/20 
        \ --purpose=REGIONAL_MANAGED_PROXY 
        \ --role=ACTIVE

서브넷 생성 후에 다시 gateway와 httproute를 올려보자.

c. 다시 Fault filter abort

위의 모든 것을 했는데도!!!!!!!!!!!! 또 fault filter abort 에러가 발생했다. 방화벽부터 health check policy 재확인, pod 확인 등 오만 것을 해본 결과, 이유와 해결 방안은 아래와 같았다...

해결 방안 

hostname을 설정한 경우 dns 제공 업체에서 ip address를 지정해주어야하는데, ip address가 틀린 경우에도 마찬가지로 같은 에러가 발생하는 것을 확인할 수 있었다. 이것은 gateway loadbalancer의 ip로 접속해도 같은 현상이 발생했다. 이유는 아래와 같다.

• L7 서비스는 라이팅을 위해 HTTP/1.1 프로토콜의 Host 헤더에 의존한다. 이는 서버가 하나의 IP 주소로 여러 도메인을 호스팅할 때 어떤 도메인을 요청했는지 구분하도록 한다.
• 브라우저가 IP로 직접 접속하면 host 헤더에 도메인 대신 ip 주소가 들어가고, gateway api에 hostname 규칙이 있다면 host 헤더가 ip인 경우 규칙에 매칭되지 않아 처리 실패할 수 있다.
• hostname을 제거하면 와일드카드(*) 처리되어 규칙이 적용된다.

때문에 hostname을 httpRoute에서 제거한 뒤에는 정상적으로 해결되는 것을 확인할 수 있었다. 말인 즉슨, dns 제공업체 쪽에서 반영한 host의 ip 주소가 실제로 반영될 때까지는 문제가 생길 수 있다는 것이다.

 

3. 마무리하며

3개의 포스트를 작성하며 웹 서비스를 gcloud gke로 올려보는 작업을 진행했다. 사실 보안적인 측면이나 네트워크에 관한 지식이 조금 부족한 편이라 클라우드 서비스 위에 올려보고 autopilot과 standard cluster를 사용해 간단히 운영해보는 정도로 했으나, 이 과정에서 kubernetes의 deployment, statefulset, persistant volume, service(load balancer, cluster ip), health check policy, configmap, secret, gateway api와 httproute, VPC 네트워크까지 시스템 전반에서 필요로하는 요소를 직접 사용해보고 오류를 분석해보며 깊이 이해하고 디버깅해볼 수 있는 좋은 기회가 되었다.

추후 개인 웹 페이지 프로젝트를 한다면 한 번 더 올려볼 생각이 있지만... 운영비용이 상당히 비싸서 깊생해봐야할 것 같다🥲