Chapter 17. 쿠버네티스로 기존 인프라 대체

LOG-INFO commented 2 years ago

Spring Cloud Config -> Config Map, Secret
- Spring Cloud Config 단점
- 많은 양의 메모리 / 시작 비용
- Config Server + 다른 서버 동시에 배포하면 구성 서버 시작 시까지 다른 서버들 대기하게 됨
  - 그런데 이런 케이스가 많진 않음
- Configmap, Secret 단점
- 실시간 설정 변경은 어려울 듯
  - 그런데 이런 케이스가 많진 않음
- Config Map은 Volume mount / Secret은 환경변수 주입
Spring Cloud Gateway -> Ingress & Ingress Controller
Kubernetes에 의존하게 됨. Kubernetes 안 쓸 때는 Spring Cloud 쓰면 될 듯
- 난 그냥 Kubernetes 쓸 듯
- Kubernetes 짱짱
Cert Manager + Let's Encrypt로 TLS 인증서 자동 프로비저닝하는거 토이플젝에서 써볼만 한 듯

minkukjo commented 2 years ago

느낀점

Configmap과 Secret을 실제로 회사 내에서 작은 프로젝트(e.q. 봇)를 개발할 때는 사용하고 있다. ( 큰 프로젝트는 Vault와 사내 키 매니지먼트 서비스를 주로 사용)
Cert Manager가 굉장히 편리하다고 느껴진다. 실제로 예전에 회사에서 인증서가 만료됐는데 교체를 미리 안해서 서비스 전면 장애로 이어진 적이 있었다.
그 이후 카카오워크(사내 메신저)에서 인증서 만료가 가까워오면 교체하라고 알림을 보내긴 하는데, 이도 결국 개발자가 일일이 손으로 k8s에 인증서를 갱신하고 있다.
Cert Manager처럼 알아서 시간이 지나면 자동으로 갱신하는 서비스가 있으면 좋을 것 같음. ( 물론 클라우드팀에서 만들어야할 것 같지만 ^^; )

MinJunKweon commented 2 years ago

팀에서 Spring Cloud Config 서버를 사용하고 있는데 실제로 사용해보니 생각보다 괜찮았음
- configMap은 리소스 디스크립터(yaml)를 변경해야해서 각 컴포넌트에 변경사항을 추가해야하지만, config 서버는 config용 git repo의 내용만 변경하면 된다는 점이 더 좋았음
- 구성을 배포없이 실시간으로 변경할 수 있다는 점
- 우리팀에서는 카프카 리스너들을 config repo에 올려서 on/off를 하는중
- 다른 팀들은 베타테스터 ID 리스트 같은 걸 config repo로 관리하는 듯함
ngrok와 비슷하게 heroku에서도 같은 기능을 제공하는 걸 본 적이 있다. 로컬에 띄운걸 외부로 터널링하는 기능
Let's encrypt 매우 편리함.. 사용했었을 때는 crontab 사용해서 만료기간 전에 알아서 요청하도록 했었는데, 앞으로 Cert Manager는 사용해볼 기회가 있으면 써보고 싶음

2rohyun commented 2 years ago

이번 장도 기존의 서버들을 어떻게 k8s로 대체하는 지에 대한 개념을 공부했다. 우선 하나하나 deep dive를 해보고 싶지만, 이 책을 읽으며 현재 허락한 시간 내에서는 기존의 것들을 어떻게 k8s로 대체하고, k8s에 대한 찍먹 개념을 아는 것으로도 도움이 되고 있다고 생각한다...!
역시나 k8s 파트는 선생님들의 소중한 의견들 주섬주섬 잘 주워 담겠습니다 ㅎㅎ ( :bus: )

스프링 클라우드 컨피그 서버 대체

마이크로서비스는 구성 서버에서 구성을 가져온 후에야 시작될 수 있어서 구성 서버가 작동될 때 까지 기다려야 한다. 이로 인해 통합 테스트 실행에 상당한 지연이 발생한다. 쿠버네티스 컨피그 맵과 시크릿을 사용하면 이런 지연이 없기 때문에 더 빠르게 자동화된 통합 테스트를 실행할 수 있다.

스프링 클라우드 게이트웨이 대체

스프링 클라우드 게이트웨이가 인그레스 리소스에 비해 풍부한 라우팅 기능을 제공하긴 하지만, 인그레스는 쿠버네티스 플랫폼에서 기본 제공하는 기능이며, Cert Manager를 사용해 인증서를 자동으로 프로비저닝하도록 확장할 수 있다는 장점이 있다.
마이크로서비스를 비인증 요청으로부터 보호하려는 목적으로도 스프링 클라우드 게이트웨이를 사용했다. 즉, 마이크로서비스는 신뢰할 수 있는 OAuth 권한 부여 서버나 OIDC 공급자가 발급한 유효한 OAuth 2.0/OIDC 접근 토큰이 필요하다. 쿠버네티스 인그레스 리소스는 이를 기본 지원하지 않지만, 이를 지원하는 인그레스 컨트롤러 구현이 있다.
마지막으로 복합 상태 점검은 각 마이크로서비스의 디플로이먼트 리소스에 라이브니스 프로브와 레디니스 프로브를 정의해 대체할 수 있다.

인증서 프로비저닝 자동화

인그레스로 구성한 HTTPS 엔드포인트에서 사용하는 인증서를 Cert Manager를 사용해 자동으로 프로비저닝할 수 있다. Cert Manager는 쿠버네티스 애드온으로 동작하며, 무료 인증 기관인 Let’s Encrypt 에 인증서 발급을 요청하도록 구성돼 인증서 발급을 자동화 한다.
Let’s Encrypt 발급자 유형
- Stage environment : 많은 양의 단기 인증서가 필요한 개발 및 테스트 단계에서 사용한다. 다량의 인증서를 만들 수 있지만 신뢰할 수 없는 root CA를 사용한다. 따라서 Stage environment 인증서는 웹 브라우저에서 사용하는 API나 웹 페이지를 보호할 수 없다.
- Production environment : 신뢰할 수 있는 root CA를 사용해 인증서를 발급한다. 상용 환경은 발급할 수 있는 인증서 수에 제한이 있는데, 1주일에 50개의 새 인증서만 발급할 수 있다.
Cert Manager와 Let’s Encrypt가 인증서 프로비저닝을 위해 통신할 때는 ACME v2 기반의 표준 프로토콜을 사용한다. Let’s Encrypt가 CA 역할을 하고 Cert Manager는 ACME 클라이언트 역할을 한다.