kubernetes - Ingress 사용

1. nginx-ingress-controller를 사용하여 Deploy, Request 하는 방법

Deploy Flow

• Deployment, Replicaset, pod, service, nginx-ingress-controller, ingress

1.kube-system namespace에 nginx-ingress-controller 설치

2. Deployment 배포 -> Replicaset에서 pod의 생성 갯수를 파악하고, Pod template을 활용하여 -> Pod 배포됨

3. Service 배포 -> Service 명세에 있는 Selector와 배포된 같은 네임스페이스 Pod의 label이 찾아 지면, Endpoint가 배포됨

   • Service IP와 Endpoint에 적혀 있는 pod들의 IP는 Node에 있는 Kube-proxy를 통해 IPtables에 기록됨 (요즘은 IPVS로 대체되고 있음)
   • iptable 보는 방법 : sudo iptables-save

4. Service로 들어오게하는 ingress를 생성한다.

5. ingress 배포 -> nginx-ingress-controller에서 ingress들을 watch하고 있다.

   • 새로생긴 ingress의 내용을 보고, nginx-ingress-controller는 config 파일에 hostname, port, 인증등의 정보와 Service 정보를 맵핑하여 적어둔다.

Request Flow

1. 외부에서 hostname으로 request 요청을 한다. http://www.xxx.com/xxxx

2. nginx-Ingress-Controller에서 요청을 받으면, config파일에 기술된 hostname - ingress맵핑 정보를 보고 Service로 routing 한다.

   • 참고 : nginx-Ingress-Controller는 외부에서 port 80으로 받을수 있게 hostPort가 설정되어 있다.

3. Service로 받는 요청은, 커널에서 IPtable에 적힌 Service IP - Endpoint의 Pod IPs맵핑된 정보를 보고 Random하게 Pod로 요청을 보낸다.

---

2. Istio-ingress-gateway를 사용하여 Deploy, Request 하는 방법

Deploy Flow

• Deployment, Replicaset, pod, service, istio, gateway, virtual service, destination rule

1. Istio 설치

2. Istio-ingress-gateway Service에 master IP를 External IP에 넣어준다.

   • patch 또는 edit

3. Deployment 배포 -> Replicaset에서 pod의 생성 갯수를 파악하고, Pod template을 활용하여 -> Pod 배포됨

4. Service 배포 -> Service 명세에 있는 Selector와 배포된 같은 네임스페이스 Pod의 label이 찾아 지면, Endpoint가 배포됨

   • Service IP와 Endpoint에 적혀 있는 pod들의 IP는 Node에 있는 Kube-proxy를 통해 IPtables에 기록됨 (요즘은 IPVS로 대체되고 있음)
   • iptable 보는 방법 : sudo iptables-save

5. 연결될 istio-ingress-Gateway Service와 hostname, port, 인증등의 정보를 넣어서 Gateway를 생성하여 배포한다.

6. 연결될 Gateway와 hostname, port, 연결될 destination(destinationrule or service) 정보를 넣어서 Virtual Service** 생성하여 배포한다.

7. Destination Rule에 hostname, 인증정보와 연결될 Service 정보를 생성하여 배포한다.

8. Envoy proxy가 Pod에 Sidecar로 Container가 추가 배포된다.

Request Flow

1. 외부에서 hostname으로 request 요청을 한다. http://www.xxx.com:/xxxx

2. Istio-ingress-gateway Service에서 요청을 받으면, Istio-ingress-gateway pod로 전송이된다.

3. Istio-ingress-gateway pod는 Envoy proxy와 같은 기능을 하며 Envoy Filter로 dex 인증 등의 요청을 처리한다.

4. Istio-ingress-gateway pod에는 Gateway와 Virtual Service 정보를 가지고 있는데,

   • Ingress-gateway에 연결되어 있는 Gateway에는 hostname, port, protocal, 인증정보를 체크하고,
   • Gateway에 연결된 Virtual Service에서는 Destination rule 또는 라우팅되는 Service에 대한 정보가 적혀 있다.
   • 만약 Gateway에 Destination rule 정보가 있다면, Destination rule에 Service에 대한 정보가 있다.

5. Istio-ingress-gateway -> Gateway -> Virtual Service -> Destination rule -> Service

6. Service로 받는 요청은, 커널에서 IPtable에 적힌 Service IP - Endpoint의 Pod IPs맵핑된 정보를 보고 Random하게 Pod로 요청을 보낸다.

7. Pod안에 있는 Envoy proxy가 요청을 먼저 받고, Envoy filter(dex 인증등)를 통과하고 Main Container로 보내진다.

8. Main Container에서 요청이 처리되면 Envoy proxy를 통해서 결과가 응답하게 된다.

---

2. Nginx-ingress-controller with Istio-ingress-gateway를 사용하여 Deploy, Request 하는 방법

• 목적 : nginx-ingress-controller를 통해 istio-ingress-gateway를 거쳐 가는 방법

Deploy Flow

• Deployment, Replicaset, pod, service, nginx-ingress-controller, ingress
  , istio, gateway, virtual service, destination rule

1.kube-system namespace에 nginx-ingress-controller 설치

2. Istio 설치

3. Deployment 배포 -> Replicaset에서 pod의 생성 갯수를 파악하고, Pod template을 활용하여 -> Pod 배포됨

4. Service 배포 -> Service 명세에 있는 Selector와 배포된 같은 네임스페이스 Pod의 label이 찾아 지면, Endpoint가 배포됨

   • Service IP와 Endpoint에 적혀 있는 pod들의 IP는 Node에 있는 Kube-proxy를 통해 IPtables에 기록됨 (요즘은 IPVS로 대체되고 있음)
   • iptable 보는 방법 : sudo iptables-save

5. istio-ingress-gateway service로 들어오게하는 ingress를 생성한다.

6. ingress 배포 -> nginx-ingress-controller에서 ingress들을 watch하고 있다.

   • 새로생긴 ingress의 내용을 보고, nginx-ingress-controller는 config 파일에 hostname, port, 인증등의 정보와 Service 정보를 맵핑하여 적어둔다.

7. 연결될 istio-ingress-Gateway Service와 hostname, port, 인증등의 정보를 넣어서 Gateway를 생성하여 배포한다.

8. 연결될 Gateway와 hostname, port, 연결될 destination(destinationrule or service) 정보를 넣어서 Virtual Service** 생성하여 배포한다.

9. Destination Rule에 hostname, 인증정보와 연결될 Service 정보를 생성하여 배포한다.

10. Envoy proxy가 Pod에 Sidecar로 Container가 추가 배포된다.

Request Flow

1. 외부에서 hostname으로 request 요청을 한다. http://www.xxx.com:/xxxx

2. nginx-Ingress-Controller에서 요청을 받으면, config파일에 기술된 hostname - ingress맵핑 정보를 보고 Istio-Ingress-Gateway Service로 routing 한다.

   • 참고 : nginx-Ingress-Controller는 외부에서 port 80으로 받을수 있게 hostPort가 설정되어 있다.

3. Istio-ingress-gateway pod는 Envoy proxy와 같은 기능을 하며 Envoy Filter로 dex 인증 등의 요청을 처리한다.

4 Istio-ingress-gateway Service에서 요청을 받으면, Istio-ingress-gateway pod로 전송이된다.

5 Istio-ingress-gateway pod에는 Gateway와 Virtual Service 정보를 가지고 있는데,
- Ingress-gateway에 연결되어 있는 Gateway에는 hostname, port, protocal, 인증정보를 체크하고,
- Gateway에 연결된 Virtual Service에서는 Destination rule 또는 라우팅되는 Service에 대한 정보가 적혀 있다.
- 만약 Gateway에 Destination rule 정보가 있다면, Destination rule에 Service에 대한 정보가 있다.

6 Istio-ingress-gateway -> Gateway -> Virtual Service -> Destination rule -> Service

7 Service로 받는 요청은, 커널에서 IPtable에 적힌 Service IP - Endpoint의 Pod IPs맵핑된 정보를 보고 Random하게 Pod로 요청을 보낸다.

8 Pod안에 있는 Envoy proxy가 요청을 먼저 받고, Envoy filter(dex 인증등)를 통과하고 Main Container로 보내진다.

9 Main Container에서 요청이 처리되면 Envoy proxy를 통해서 결과가 응답하게 된다.