'Ingress'에 해당되는 글 1건

필요 요소와 서비스 구성

• Kubernetes Cluster(Local cluster, minikube or dind-cluster not in the cloud like AWS or GCP)
• Backend Service(like web or specific app server)
• 테스트 수행용 컨테이너(curl로 클러스터 내부 접속 테스트)
• Local DNS(Cluster 외부, named 서버)

예제로 사용하는 백엔드 서비스는 단순한 web server로, 앞선 포스팅(http://bryan.wiki/287) 에서 만들어 본 웹서버 컨테이너 이미지(drlee001/kubeweb)을 사용한다. 

위 그림은 본 구현에서 적용된 전체 요소들의 논리적인 구성과 관계를 나타낸 것이다. 텍스트가 작아서 잘 보이지 않을 경우, 이미지를 클릭하여 원본 크기로 자세히 들여다 보도록 하자.

테스트 수행용 컨테이너 기동

클러스터 내부의 각 서비스에 대한 접속 테스트를 curl 로 수행할 때 사용할 Pod로, 네트워크를 테스트하기 위해 많이 사용하는 drlee001/net-tester 컨테이너를 기동해 둔다.

<00-test-pod.yaml>

apiVersion: v1
kind: Pod
metadata:
  name: net-tester-for-ingress
spec:
  containers:
  - image: drlee001/net-tester
    imagePullPolicy: IfNotPresent
    name: net-tester-container
  restartPolicy: Never

Backend Service 기동

Load Balancing 의 대상이 되는 예제 서비스로, 이미 만들어진 drlee001/kubeweb 컨테이너를 deploy 하고 ClusterIP 로 service를 기동해 둔다. 여기서는 2개의 서로 다른 서비스에 대해 하나의 Ingress를 통해 Load balancing이 가능하도록 deploy-test-1(port 7777로 접속) 과 deploy-test-2(port 8888로 접속)으로 구분하여 구축해 두도록 한다.

<01-deploy-2backends.yaml>

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deploy-test-1
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: web-front-end
        department: group1
    spec:
      containers:
      - name: tiny-webserver-1
        image: drlee001/kubeweb
        env:
        - name: PORT_ARGS
          value: "--port=7777"
        ports:
        - containerPort: 7777
          name: web-port
          protocol: TCP
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deploy-test-2
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: web-front-end
        department: group2
    spec:
      containers:
      - name: tiny-webserver-2
        image: drlee001/kubeweb
        env:
        - name: PORT_ARGS
          value: "--port=8888"
        ports:
        - containerPort: 8888
          name: web-port
          protocol: TCP

다음으로, 2개의 서로 다른 deployment 에 대응하는 Cluster 내부 접속 endpoint 를 제공할 서비스를 구축한다.

<02-svc-2backends.yaml>

apiVersion: v1
kind: Service
metadata:
  name: backend-svc-1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: web-port
  selector:
    app: web-front-end
    department: group1
---
apiVersion: v1
kind: Service
metadata:
  name: backend-svc-2
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: web-port
  selector:
    app: web-front-end
    department: group2

Default backend 서비스 기동

Ingress LB를 통해서 들어온 request가, 등록된 Ingress rule(나중에 정의해서 사용할)에 매칭되지 않을 경우의 적당한 response 를 위해서, 이러한 request 를 받아줄 별도의 내부 서비스가 필요하다. 이를 default backend(일종의 랜딩페이지) 라고 하는데, port 8080으로 들어온 http 접속에 대해 하위 path가 '/' 인 경우 404(not found)를, '/healthz' 인 경우 200(ok) 를 응답하는 간단한 web server 이다. 여기서는 구글이 제공하는 defaultbackend 컨테이너를 사용한다.

<03-default-backend-for-ingress.yaml>

apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
spec:
  type: ClusterIP
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  # Matches Deployment
  selector:
    app: default-http-backend
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
spec:
  replicas: 2
  template:
    metadata:
      # Matches Deployment
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissable as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: gcr.io/google_containers/defaultbackend:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi

테스트용 컨테이너로 서비스 정상 동작 확인

Nginx Ingress Controller 설정값 저장을 위한 Configmap 등록

Nginx는 웹서버 기능과 함께 로드밸런서 역할도 수행할 수 있게 만들어져 있다. 편리하게도 kubernetes 클러스터 내에 이 설정 값을 configmap 형태로 등록해 두고, 필요에 따라 설정값을 바꿔가면서 운영할 수 있는데, 진행 과정 상 Nginx Ingress Controller를 띄우기 전에 미리 등록해 두어야 한다. 

<04-configmap-nginx-ingress-controller.yaml>

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller-conf
  labels:
    app: nginx-ingress-lb
    group: lb
data:
  # for VTS page of the Nginx load balancer
  enable-vts-status: 'true'
  enable-sticky-sessions: 'true'

Nginx Ingress Controller 실행

<05-deploy-nginx-ingress-controller.yaml>

# Add: SA, ClusterRole, ClusterRoleBinding
# Name Space: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ingress
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: system:ingress
rules:
- apiGroups:
  - ""
  resources: ["configmaps","secrets","endpoints","events","services"]
  verbs: ["list","watch","create","update","delete","get"]
- apiGroups:
  - ""
  - "extensions"
  resources: ["services","nodes","ingresses","pods","ingresses/status"]
  verbs: ["list","watch","create","update","delete","get"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:ingress
subjects:
  - kind: ServiceAccount
    name: ingress
    # Could be like 'kube-system' ...
    namespace: default
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  # Could be like 'kube-system' ...
  namespace: default
spec:
  replicas: 2
  revisionHistoryLimit: 3
  template:
    metadata:
      labels:
        app: nginx-ingress-lb
    spec:
      serviceAccountName: ingress
      terminationGracePeriodSeconds: 60
      containers:
        - name: nginx-ingress-controller
          image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.2
          imagePullPolicy: IfNotPresent
          readinessProbe:
            httpGet:
              path: /healthz
              port: 18080
              scheme: HTTP
          livenessProbe:
            httpGet:
              path: /healthz
              port: 18080
              scheme: HTTP
            initialDelaySeconds: 10
            timeoutSeconds: 5
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-ingress-controller-conf
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - containerPort: 80
            - containerPort: 18080

여기까지 진행하였다면 다음과 같은 여러 개의 pod 가 실행되고 있음을 확인할 수 있다.

이 중에서 실제로 로드밸런서 역할을 담당할 pod가 nginx-ingress-controller-*-* 같이 생긴 pod들이다(사실 하나만 띄워도 되지만, 고가용성-HA-를 위해서는 2개 이상을 사용). net-tester를 통해서 각각의 nginx-ingress-controller 에 직접 접속이 되는지 확인해 보자. 아직은 따로 Ingress Rule을 적용하지 않았기 때문에 '404' 응답이 나오면 정상적인 상태이다(실은, 이 '404' 응답은 그림에서 보이듯이 default-http-backend 에서 보내주는 것이다).

Ingress Rule 디플로이

이제 모든 준비는 끝났고, Nginx Ingress Controller 가 로드밸런서 역할을 수행할 수 있도록 Ingress Rule(Policy, 또는 Ingress Object) 를 디플로이하고 서비스로 노출(Expose)시키는 단계와, curl을 통한 접속 테스트, DNS 등록을 통한 실제 접속을 해 보는 일만 남았다. 아래 yaml을 보면 총 3개의 도메인에 대한 rule이 존재하는데, Nginx 또는 Apache httpd 등으로 웹서버를 운영해 보았다면, 하나의 웹서버에서 서로 다른 도메인에 대해 각각 특정한 웹페이지를 연결해 주는  'VirtualHost' 의 동작 방식과 유사함을 보게 될 것이다.

<06-ingress-rule.yaml>

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: default
spec:
  rules:
  - host: kubeweb-7777.bryan.local
    http:
      paths:
      - backend:
          serviceName: backend-svc-1
          servicePort: 80
  - host: kubeweb-8888.bryan.local
    http:
      paths:
      - backend:
          serviceName: backend-svc-2
          servicePort: 80
  - host: kubeweb.bryan.local
    http:
      paths:
      - path: /svc1
        backend:
          serviceName: backend-svc-1
          servicePort: 80
      - path: /svc2
        backend:
          serviceName: backend-svc-2
          servicePort: 80
      - path: /nginx_status
        backend:
          serviceName: nginx-ingress-nodeport
          servicePort: 18080

여기까지는 Kubernetes 클러스터 내부에서의 연결 통로만 설정이 완료된 상태다.

* Host Header 를 조작하여 접속을 시도하는 세션에 도메인명을 담아서 접속하면 Ingress Rule 에 따라 2개의 서비스 각각에 분기 접속되는 것을 확인할 수 있다(위의 06-ingress-rule.yaml에서 정의된 첫 번 째, 두 번 째 rule에 매칭된다)

* 위와 비슷하지만 이번에는 kubeweb,bryan.local 도메인에 대한 URL path 별로 접속이 분기됨을 확인할 수 있다(06-ingress-rule.yaml에서 정의된 세 번 째 rule에 매칭된다)

Ingress 서비스 노출(Expose)

Kubernetes Cluster 의 외부에서 웹브라우저 등을 통해서 내부에 존재하는 backend-svc-1, backend-svc-2 에 접속하기 위해서는 NodePort 방식으로 접속하면 된다(AWS나 Google Cloud Engine과 같은 퍼블릭클라우드에 Kubernetes 가 설치된 경우에는 Loadbalancer 방식으로 접속하면 된다).

<07-svc-expose-by-nodeport.yaml>

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-nodeport
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 30100
      name: http
    - port: 18080
      nodePort: 30101
      name: http-mgmt
  selector:
    app: nginx-ingress-lb

이제 클러스터 외부에서 웹브라우저를 통해 NodePort 로 접속을 시도해 보아야 할텐데, 그 전에 한 가지 더 할 일이 있다. 클러스터 외부의 DNS의 존파일에 여기서 사용할 도메인의 A 레코드들을 등록해 주어야 한다. 다음과 같이 DNS 서버에 추가로 작업해 주고 'systemctl restart named' 로 named 서비스를 재시작한다.

웹브라우저로 Ingress 접속 확인

다음 캡처 이미지는 ConfigMap 에서 enable-vts-status 로 사용하도록 하고 ingress-rule.yaml 에서 연결되도록 설정하고 NodePort로 expose시킨 Ingress Status 모니터링 화면이다.

* Reference: dasblinkenlichten.com 포스팅 내용과 아이디어를 다수 참조 하였음

* 다음 포스팅인 Part-2 에서는 Traefik Ingress를 활용한 Ingress 로드밸런서를 구현해 보고, Nginx 방식에 비해 어떤 점이 다르고 또 장점은 무엇인지 생각하는 시간을 가져보기로 한다. 구현과 테스트 방식은 이번 Part-1 과 유사하며, 양 쪽에 놓고 비교해 보는 자료로 활용되기를 기대한다.

- Barracuda -