Ingress

• k8s에는 기본적으로 Ingress Controller가 없다. 
• 그래서 배포해야하는데, 종류로는 GCE, Nginx, Contour, HAPROXY 등이 있다. 
• Ingress Controller는 Load Balancer가 아니다. 
• 예를 들어 Nginx를 사용하면 
  • 새로운 정의나 새로운 Ingress 리소스를 위한 쿠버네티스 클러스터를 모니터링하고 그에 따라 Nginx 서버를 구성한다. 
    • 이것을 위해서는 Service Account가 필요하다.
  • Nginx Controller는 쿠버네티스에서 또 다른 Deployment로서 배포된다. 그래서 nginx 이미지를 사용하여 Deployment를 배포하는 것으로 시작한다. 
    • err-log-path, keep-alive, ssl-protocols를 ConfigMap에 설정해주어야 한다. 
    • Deployment에 환경 변수로 POD_NAME, POD_NAMESPACE를 넘겨주어야 한다. 
    • http포트인 80과, https 포트인 443을 알려주어야 한다. 
  • 추가적으로 NodePort 타입의 서비스를 만들어주어야 한다. 
  • Service Account, Roles, ClusterRoles, RoleBindings도 만들어주어야 한다. 

 

Ingress Resources

• Ingress Resource는 Ingress Controller에 적용되는 Rules와 Configurations의 설정이다. 
• 어떤 애플리케이션으로 들어가는 모든 트래픽의 규칙을 구성할 수 있고 URL을 기반으로 다양한 애플리케이션으로 가는 트래픽을 라우팅할 수 있다. 
  • 도메인 이름을 기으로도 라우팅이 가능하다. 
• Ingress 리소스는 K8S Definition 파일로 생성이 가능하다. 
  • backend 섹션은 어디로 트래픽이 라우팅될지 설정하는 것이다. 

 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-wear-watch
spec:
  rules:
  - http:
      paths:
      - path: /wear
        backend:
          serviceName: wear-service
          servicePort: 80
      - path: /watch
        backend:
          serviceName: watch-service
          servicePort: 80

• 도메인 이름으로 라우팅
  • host 필드를 설정하지 않으면, 모든 들어오는 요청들이 매칭된다. 

 

Ingress Update 사항

• apiVersion: networking.k8s.io/v1 으로 바뀜

...
	backend:
      service:
        name: wear-service
        port:
          number: 80

• d위와 같은 형식으로 바뀜

kubectl create ingress <ingress name> --rule="host/path=service:port"

//예시
kubectl create ingress ingress-test --rule="wear.my-online-store.com/wear*=wear-service:80"