Ingress

1. Ingress

 

온라인 스토어를 k8s 클러스터에 배포 하는 상황을 가정해보자

 

my-sql service를 만들어서 Cluster ip 형태로 배포하면 백앤드 서버(Pod)가 연결 할 것이고 이것을 바깥에서 접속하려면 노드 포드 서비스를 통해 접근이 가능하다. http://<node-ip>:<nodeport>이런 식으로

 

그런데 새로운 api 서버를 같은 클러스터 내에서 추가하고 싶다면 LoadBalancer 형태로 서비스를 배포하여야 한다.

 

http 세팅은..?

 

이러한 것들을 한 번에 할 수 있는 것이 INGRESS이다.

 

 

Ingress Controller가 LB, Proxy 서버, HTTPS 세팅과 같은 솔루션을 구현

 

Ingress Resource : 설정할 서비스와의 연결등을 구현

 

허나 Ingress Controller는 K8S의 기본 구성이 아니기 때문에 개발자가 일일이 구현해야 한다.

 

IngressController - NGINX SETTING

---

NGINX Controller.yaml (Deployment)

apiVersion: v1
kind: Deployment
metadata: 
  name: nginx-ingress-controller
spec:
  replicas: 1
  selector: 
    matchLabels:
      name: nginx-controller
  template:
    metadata:
      labels:
        name: nginx-ingress
    spec:
      containers:
        - name: nginx-ingress-controller
          image: query.io/kubernates-ingress-controller/nginx-ingress-controller:0.21.0
      args:
        - /nginx-ingress-controller #특정 명령어 nginx 내부 정의 된 것
        - --configmap=$(POD_NAMESPACE)/nginx-configuration #추후 configMap으로 Nginx 셋팅을 수정 할 수 있으므로
        # 콘피그 맵은 빼두는 것이 좋다.
      env:
        - name: POD_NAME #어느 POD인지 알 수 없으므로 명시한다.
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
      ports:
        - name: http
          containerPort: 80
        - name: https
          containerPort: 443

 

NGINX - SERVICE (to deploy outside world) (Service)

 

apiVersion: v1
kind: Service
metadata: 
  name: nginx-ingress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  - port: 443
    targetPort: 80
    protocol: TCP
    name: https
  selector:
    name: nginx-ingress

NGINX ConfigMap (ConfigMap)

 

apiVersion: v1
kind: ConfigMap
metadata: 
  name: nginx-configuration # Deployment와 연결됨

 

NGINX Auth (ServiceAccount)

 

apiVersion: v1
kind: ServiceAccount
metadata: 
  name: nginx-ingress-serviceaccount

 

Ingress Resource

---

NGINX - INGRESS

apiVersion: extensions/v1beta1 #공식문서 참조
kind: Ingress
metadata:
  name: ingress-wear
spec:
  backend:
    serviceName: wear-service
    servicePort: 80

 

NGINX - PATH 마다 다른 설정

 

apiVersion: extensions/v1beta1 #공식문서 참조
kind: Ingress
metadata:
  name: ingress-wear
spec:
  rules:
  - http:
      paths:
        - path: /wear
          backend:
            serviceName: wear-service #내가 연결할 APPLICATION POD 서비스
            servicePort: 80
        - path: /watch
          backend:
            serviceName: wear-service #내가 연결할 APPLICATION POD 서비스
            servicePort: 80

 

NGINX - DOMAIN NAME 마다 다른 설정

 

apiVersion: extensions/v1beta1 #공식문서 참조
kind: Ingress
metadata:
  name: ingress-wear
spec:
  rules:
  - host: wear.my-online.com
  	http:
      paths:
      - backend:
          serviceName: wear-service #내가 연결할 APPLICATION POD 서비스
          servicePort: 80
   - host: watch.my-online.com
     http:
      paths:
      - backend:
          serviceName: wear-service #내가 연결할 APPLICATION POD 서비스
          servicePort: 80

명령어가 위 이미지와 같이 변했다고 한다 참고하자.

NGINX REWRITE

---

  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /

하부 Path 블럭이 저장된 path로 가게 되므로 해당 path를 무시하고 처음 루트 포인트로 부터 시작하게끔한다.

 

이게 무슨 말인가 싶어 보았더니

 

실제로 ingress를 통해서 들어오는 값은

http://<ingress-service>:<ingress-port>/watch --> http://<watch-service>:<port>/

http://<ingress-service>:<ingress-port>/wear --> http://<wear-service>:<port>/

 

위와 같이 행동하지 않는가 그러면 rewrite-target option이 존재 하지 않는다면

 

http://<ingress-service>:<ingress-port>/watch --> http://<watch-service>:<port>/watch

http://<ingress-service>:<ingress-port>/wear --> http://<wear-service>:<port>/wear

 

서비스 path를 잡기 위한 path 값이 실제 들어가는 api path 값으로 잡혀버리기 때문에 rewrite를 사용한다.