쇼핑 페이지, 고객센터, 주문서비스를 Pod별로 나누었다고 가정했을 때 쇼핑 페이지가 문제가 생겨도 고객센터나 주문서비스는 가능할 수 있다는 장점이 있다.
그리고 외부에서 연결할 수 있도록 각각 Service를 달아주고 사용자들로 하여금 각각 다른 도메인 path를 주고 싶을 때 Ingress라는 Object를 사용하면 된다.
V1의 App이 구동되고 있는 상태에서 테스트할 V2의 App을 구동시키고 Ingress를 만들어서 두 버전의 Service를 만들어서 사용자들이 접속을 했을 때 10%만 V2의 App만 가도록 설정할 수 있다.
Ingress는 쿠버네티스가 설치가 되어있으면 바로 만들 수 있다.
Ingress에는 Host로 도메인 이름을 넣을 수 있고 Path에 따라 원하는 Service로 연결을 하라는 내용이 주 설정 내용이다.
하지만 이렇게 만들었다고 해서 Ingress가 작동되는 것이 아니고 Ingress를 실현할 구현체를 만들어줘야한다.
쿠버네티스에서는 Ingress 구현체를 만들기 위해 별도의 플러그인을 설치해야 한다. 그 플러그인들을 Ingress Controller라고 하고 대표적으로 Nginx가 있다.
만약 Nginx를 설치했다고 가정하면 Nginx라는 Namespace가 생기고 이 안에 Deployment와 ReplicaSet이 만들어지면서 실제 Ingress 구현체인 Nginx Pod가 만들어진다.
Nginx Pod는 Ingress Rule이 있는지 체크하고 Ingress Rule이 있다면 그 Rule대로 Service에 연결해주는 역할을 한다.
외부에서 Ingress Rule에 따라 트래픽이 전달이 되려면 외부에서 접근해서 사용하는 트래픽은 Nginx를 지나야하기 때문에 외부에서 접근할 수 있는 Service를 하나 만들어서 Nginx Pod에 연결을 해줘야 한다.
직접 쿠버네티스를 만들었다면 NodePort를 이용해서 외부와 연결할 수 있을 것이고 Cloud 서비스를 이용하고 있다면 LoadBalancer를 만들어서 외부와 연결을 할 수 있다.
그래서 Ingress Rule에 대한 접근이 오면 이 Service를 통해서 Nginx Pod로 트래픽이 들어와서 Ingress Rule에 따라 지정된 Service와 Pod에 접근할 수 있게 된다.
그리고 Ingress를 더 추가할 수 있는데 path 없이 바로 서비스로 연결할 수 도 있고 현재 Nginx가 설치되어 있기 때문에 추가한 Ingress가 바로 적용된다.
위의 사진을 보면 각각의 업무별로 Pod와 Service가 구성되어 있고 사전에 Nginx Controller가 설치되어 있고 이 Pod에 외부에서 연결이 가능하도록 NodePort Service도 연결이 되어있기 때문에 Master에 HostIP:nodePort로 접속하는 Nginx Pod에 트래픽이 전송된다.
이렇게 환경이 구성된 상태에서 Ingress를 만들고 Rule을 각 Service에 매칭해주면 된다.
위의 사진을 보면 도메인 이름으로 사용자가 접근하면 Nginx Pod가 Service에 연결해주는 상태고 현재 사용자들에게 App이 운영되고 있는 상황이다.
이 상태에서 Canary Upgrade할 Pod와 Service를 띄우고 Ingress를 하나 더 만드는데 host 이름은 처음 만들었던 Ingress의 host 이름과 똑같고 V2 버전의 서비스를 주면
Nginx Pod와 연결고리가 만들어진다.
새로 만든 Ingress에 @weight10% 라는 애노테이션을 주면 이 도메인으로 접근하는 트래픽의 10%는 V2 Pod로 들어가서 서비스를 테스팅하게 된다.
Ingress를 통해서 Https로 연결할 수 있도록 인증서 관리 또한 가능하다.
Nginx Pod에서 Https를 사용하려면 443 포트로 연결해야 한다.
그리고 Ingress를 만들 때 host 도메인 이름과 Service를 연결하고 tls이라는 옵션이 있는데 tls의 secretName으로 실제 Secret Object를 연결하는데 이 Secret 안에는 데이터 값으로 인증서를 담고 있다.
이렇게 구성하면 사용자가 도메인 이름앞에 https를 붙여야만 접근할 수 있다.