msa구조 k8s 통해 백엔드 배포해보기 (1) Ingress, Spring Cloud Kubernetes

 

 

 k8s 를 사용해서 배포를 해보았다. 

다른 사람도 알기 쉽고 따라하면 바로 배포할 수 있게 그 과정을 차근차근 정리를 해보려고한다. 

 

 

 

현재 내 프로젝트 구조이다.

 

 

• Batch 
• Employee
• Eureka
• Frontend 
• Gateway
• Login
• Salary
• Total

Uereka 는 Spring Cloud Kubernetes 를 사용하면서 필요 없어진다. 그럼 6개 남았다. 처음은 게이트웨이 쪽을 만져보도록 하겠다.

 

그리고 Redis, 카프카, MariaDB 가 있다.

다 차근차근 배포 해보겠다

 

 

 

이렇게 총 8개의 프로젝트로 나뉜다.

프론트엔드는 이전 글에서 배포를 완료했다. 따라하실분은 따라해보고 안되면 댓글 달아주면 도와드리겠다.

https://windy7271.tistory.com/entry/MSA-%EA%B5%AC%EC%A1%B0-k8s-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-Vue-TypeScript

MSA 구조 k8s 프론트엔드 배포하기 Vue + TypeScript

 

 

 msa 구조를 배포하는 방법에는 여러 방법 이있다 

 

1. Ingress-Controller 를 사용한 배포

 

저번 프로젝트때 Ingress-Controller 를 사용해 배포를 하였는데 그때의 아키텍쳐 이다.

 

1. ingress - controller 를 사용한 방식이다.

 

이 방식은 

ingress-controller → containers  각각을 ingress-controller 가 직접적으로  routing을 해주는 방법이다.

코드로 보여주자면

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: som-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1 #첫번째 prefix제거 /jang 제거
    cert-manager.io/cluster-issuer: letsencrypt-prod

spec:
  tls:
  - hosts:
    - "server.greatjang.shop" #수정 필요
    secretName: som-com-tls
  rules:
    - host: server.greatjang.shop # 수정 필요
      http:
        paths:
          - path: /admin/(.*) #모든 url요청을 nginx-service로 라우팅 # 수정 필요
            pathType: Prefix
            backend:
              service:
                name: admin-service
                port:
                  number: 80

          - path: /board/(.*) #모든 url요청을 nginx-service로 라우팅 # 수정필요
            pathType: Prefix
            backend:
              service:
                name: board-service
                port:
                  number: 80
                  
          - path: /batch/(.*) #모든 url요청을 nginx-service로 라우팅 # 수정필요
            pathType: Prefix
            backend:
              service:
                name: batch-service
                port:
                  number: 80

그렇게 되면 게이트웨이 와, 유레카 가 필요없어지게 되면서

단순히 batch, board 이런 path만 보고 그쪽 서버로 던져주게 되는 것이다.

 

이렇게 되면 문제점 이 생긴다 .게이트웨이에서 해주던 globalfilter도 사라지면서 각각의 employee, total 등 각각의 서비스 안에서 각 컨테이너에서 인증처리(cors, token filter 등) 을 구현해줘야하는 단점이 있고, 개인적으로 이게 진짜 msa구조라고 할 수 있을까?

라는 의문을 가지게된다.

 

하지만 라우팅 과정의 단순함과 독립적 서비스로 인해 고가용성 확보가 이루어 진다.

 

Ingress와 , Ingress-Controller 에 대해 더 궁금하다면 저번에 정리를 해두었던 글을 남기겠다.

 

https://windy7271.tistory.com/entry/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%A0%95%EB%A6%AC-2-Ingress

쿠버네티스 정리 (2) Ingress

 

링크 타고 가기 귀찮은 사람들을 위해 간단히 정리를 해주자면

 

Ingress는 클러스터 외부에서 클러스터 내의 서비스로 HTTP와 HTTPS 트래픽을 라우팅하기 위한 규칙의 모음이고

Ingress-Controller 는 실질적인 라우팅을 수행 한다. 즉 내가 이번에 배포한 spring cloud의 api-gateway 와 같다.

 

 

2. spring cloud kubernetes 를 사용한 방법

 

이 방식은 게이트웨이로 라우팅이 되고 서비스 디스커버리를 이용해 로드밸런싱 을 할 수 있다. 단점으로는 소스코드의 복잡도가 증대, 라우팅 과정이 길어짐, 스프링의 의존적으로 된다.

 

아키텍쳐로 보면 이렇게 나온다.

 

모든 트래픽은 Ingress 게이트웨이를 통해 백엔드 정적 웹사이트와 마이크로서비스 게이트웨이(Spring Cloud Gateway)로 들어온다.

 

지금 배포한 프로젝트의 전체 서비스의 k8s ingress를 보면

 

# ingress-controller 설치
# kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/aws/deploy.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: harbor-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: 
    cert-manager.io/cluster-issuer: letsencrypt-prod

spec:
  tls:
  - hosts:
    - "도메인" #수정 필요
    secretName: harbor-com-tls
  rules:
    - host: 도메인 # 수정 필요
      http:
        paths:
          - path: /(.*) #모든 url요청을 gateway 보냄
            pathType: Prefix
            backend:
              service:
                name: gateway-service # gateway 서비스 네임
                port:
                  number: 80

 

이렇게 된다.

 

다음 장 에서는

 

Spring Cloud Kubernetes 에 대한 간략한 내용과 바로 배포 출발해보겠다.