TheKoguryo's 기술 블로그

1.2.2.1.2 OCI Native Ingress Controller에서 PATH 기반 라우팅

PATH 기반 기본 라우팅 테스트

가장 기본적인 라우팅으로 URL PATH에 따라 라우팅 서비스를 달리하는 경우입니다.

1. 테스트를 위한 샘플 앱을 배포합니다.

   배경 색깔이 다른 두 개의 웹페이지를 배포합니다.

   kubectl create deployment nginx-blue --image=thekoguryo/nginx-hello:blue
   kubectl expose deployment nginx-blue --name nginx-blue-svc --port 80
   kubectl create deployment nginx-green --image=thekoguryo/nginx-hello:green
   kubectl expose deployment nginx-green --name nginx-green-svc --port 80
   

2. ingress 설정 YAML(native-ic-ingress-path-basic.yaml)을 작성합니다.

   • /blue 요청은 nginx-blue-svc 로 라우팅
   • /green 요청은 nginx-green-svc로 라우팅
   • spec.ingressClassName에 앞서 생성한 IngressClass의 이름을 입력하였습니다. 나머지는 Nginx Ingress Controller 때와 큰 차이가 없습니다.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: native-ic-ingress-path-basic
   spec:
     ingressClassName: native-ic-ingress-class
     rules:
     - http:
         paths:
         - path: /blue
           pathType: Prefix
           backend:
             service:
               name: nginx-blue-svc
               port:
                 number: 80
     - http:
         paths:
         - path: /green
           pathType: Prefix
           backend:
             service:
               name: nginx-green-svc
               port:
                 number: 80
   

3. 작성한 native-ic-ingress-path-basic.yaml을 배포합니다.

   • 여기서 OCI Load Balancer의 IP를 확인할 수 있습니다.

   $ kubectl apply -f native-ic-ingress-path-basic.yaml
   ingress.networking.k8s.io/native-ic-ingress-path-basic created
   $ kubectl get ingress
   NAME                           CLASS                     HOSTS   ADDRESS          PORTS   AGE
   native-ic-ingress-path-basic   native-ic-ingress-class   *       158.180.xx.xxx   80      5s
   

4. 지금 상태에서 Load Balancer에서 Pod로 접속이 불가합니다. 그림과 같이 OCI Load Balancer에서 Backend Set에서 오류가 나는 것을 볼 수 있습니다.

   

5. Security List에 관련 보안 정책을 추가해 줍니다. OCI VCN-Native Pod Networking CNI를 사용하기 때문 Pod Subnet으로 접속가능하도록 규칙 추가가 필요합니다.

   • Load Balancer Subnet -> Pod Subnet(10.0.40.0/24)의 대상 포트(80): oke-svclbseclist-~~ Security List 업데이트

     • Egress 규칙:

     Stateless	Destination	IP Protocol	Source Port Range	Destination Port Range
     No	10.0.40.0/24	TCP	All	80

   • Load Balancer Subnet -> Pod Subnet(10.0.40.0/24)의 대상 포트(80): oke-pods-seclist-~~ Security List 업데이트

     • Ingress Rules:

     Stateless	Source	IP Protocol	Source Port Range	Destination Port Range
     No	10.0.20.0/24	TCP	All	80

6. 앞서 확인한 ingress controller의 EXTERNAL IP로 접속하여 결과를 확인합니다.

   • /blue 요청

     

   • /green 요청

     

   • POD 정보 확인

     정의한 PATH에 따라 각각 blue, green 앱이 배포된 POD로 라우팅 된 것을 웹페이지 배경색 및 POD IP로 알 수 있습니다.

     $ kubectl get pod -o wide
     NAME                          READY   STATUS    RESTARTS   AGE   IP           NODE         NOMINATED NODE   READINESS GATES
     nginx-blue-565656fd64-rm49s   1/1     Running   0          95m   10.0.40.52   10.0.10.93   <none>           <none>
     nginx-green-8c6dc77b6-hk7h7   1/1     Running   0          95m   10.0.40.16   10.0.10.93   <none>           <none>
     

OCI Load Balancer 설정 내용 확인

1. OCI 콘솔에 로그인합니다.

2. 좌측 상단 햄버거 메뉴에서 Networking > Load Balancers > Load Balancer로 이동합니다.

3. 생성된 OCI Native Ingress Controller의 Load Balancer를 클릭합니다.

4. Resources > Listener에서 기본값으로 80 포트로 등록된 것을 볼 수 있습니다.

   

5. Resources > Backend sets에서 default외에 두개의 Backend Set이 등록된 것을 볼 수 있습니다. 각각 native-ic-ingress-path-basic에서 두 Path에서 라우팅되는 서비스에 현재 있는 Pod가 Backend로 등록되어 있습니다.

   

   • 그 중 /blue의 Backend 서비스인 nginx-blue-svc로 등록된 화면입니다.

   

6. 다시 Load Balancer에서 Resources > Routing policies을 선택하면, 2개의 라우팅 규칙이 등록되어 있습니다. 클릭하여 등록된 규칙을 보면, native-ic-ingress-path-basic에서 요청한 그대로 각각 /blue, /green Path에 따라 대상 Backend Set로 라우팅하는 규칙이 등록된 것을 볼 수 있습니다.

   

참고

• https://kubernetes.io/docs/concepts/services-networking/ingress/#deprecated-annotation

  Deprecated annotation

  Before the IngressClass resource and ingressClassName field were added in Kubernetes 1.18, Ingress classes were specified with a kubernetes.io/ingress.class annotation on the Ingress. This annotation was never formally defined, but was widely supported by Ingress controllers.

  The newer ingressClassName field on Ingresses is a replacement for that annotation, but is not a direct equivalent. While the annotation was generally used to reference the name of the Ingress controller that should implement the Ingress, the field is a reference to an IngressClass resource that contains additional Ingress configuration, including the name of the Ingress controller.

  Nginx Ingress Controller에서 kubernetes.io/ingress.class annotation을 사용하였고, 인터넷 상의 많은 예시가 그렇게 되어 있지만, 공식적으로는 ingressClassName 사용을 권고하고 있으니, OCI Native Ingress Controller의 예시에 있는 ingressClassName 을 여기에서는 사용합니다.