[제3회 스포카콘] Kubernetes in Spoqa
0 likes•334 views
스포카에서는 쿠버네티스를 왜 도입하고, 어떻게 도입하고, 어떻게 사용하고 있는지 공유합니다.
![[제3회 스포카콘] Kubernetes in Spoqa](https://image.slidesharecdn.com/kubernetesinspoqa-210223072217/85/3-Kubernetes-in-Spoqa-36-320.jpg)
[제3회 스포카콘] Kubernetes in Spoqa
- 1. Kubernetes in Spoqa 스포카에서는 쿠버네티스를 왜 도입하고, 어떻게 도입하고, 어떻게 사용하고 있을까? Rusty 이강욱 Full Stack Programmer
- 2. Rusty • 풀 스택 프로그래머 • 러스테이션 • 가볍고, 빠르고, 튼튼한 인프라를 만들고 싶다
- 3. Kubernetes a.k.a. K8s • 구글에서 개발된 Borg 기반 • 오픈소스 • 컨테이너 오케스트레이션 시스템
- 4. Spoqa에서는… • Service Oriented Architecture • 20+개의 서비스 운영 중 • 컨테이너 오케스트레이션이 매우 필요
- 5. 1. 왜 쿠버네티스를 도입했는가?
- 6. 태초에 ECS가 있었다 Amazon Elastic Container Service • 쿠버네티스가 아직 없던 (유명해지지 않았던) 시절 도입 • EC2 위에서 컨테이너 오케스트레이션 • EC2 비용을 제외하면 ECS는 무료!
- 7. ECS Web Console • 오퍼레이션 하기 매우 불편함 • 장애 대응 등…
- 8. ECS 자동화 • 자동화 하기 불편함 • 자동 배포 등을 하려면 새 서비스를 개발하는 수준의 복잡도 필요
- 9. ECS 기타 등등… • 동작이 궁금하면 매뉴얼만 열심히 뒤져봐야 함 • 서비스, 클러스터 설정 등을 코드로 명시화 하기 힘듦 • … • 그러던 중…
- 10. QA 환경을 만들어야 한다! 실섭과 동일한 환경의 QA 환경을 만들자!
- 11. QA 환경 그럼 기존에는…? • 프로그래머가 QA 해야 할 서비스를 자기의 머신 위에서 실행 • 의존하는 서비스가 있으면 다 같이 띄워야 함 • 프로그래머의 각자의 머신 상태에 따라서 QA 환경이 들쭉날쭉… • “쿠폰 사용 기능이 작동을 안 하는데 이번 변경사항 버그인가요?” • “아 제가 쿠폰 서비스를 안 띄웠네요 잠시만요…”
- 12. QA 환경의 목표 • 실섭과 동일한 환경이어야 한다! • 모든 필요한 서비스, 자원 (예: AWS SQS)이 있고 • 서비스 간 통신 방식 등이 실섭과 동일하고 • 빠르게 배포하고 수정할 수 있어야한다! • QA 준비에 걸리는 시간 단축 • 실섭과 분리되어 있어야한다!
- 13. 실섭과 동일한 환경 • 현재 실섭은 손으로 구성된 ECS • 동일한 클러스터를 새로 띄우는 것은 매우 힘듦 • 아예 새로운 클러스터를 구축하고 실섭을 바꾸자 Kubernetes + Terraform
- 14. Kubernetes + Terraform 왜 쿠버네티스인가? • 선언적으로 구축할 수 있다 • kubectl 등 CLI를 통해 자동화하기 쉽다 • kubectl 등 CLI를 통해 관리하기 편하다 • 오픈소스 • 사용자가 많아 사용 경험도 풍부하고 어느정도 검증되었다
- 15. Kubernetes + Terraform 왜 테라폼인가? • 역시 선언적으로 관리할 수 있다 • 역시 사용 경험이 풍부하다 • AWS 이외에 다른 자원도 한꺼번에 관리할 수 있다
- 16. 2. 어떻게 쿠버네티스를 도입했는가?
- 17. AWS EKS Elastic Kubernetes Service • 컨트롤 플레인을 AWS에서 직접 관리 • -> 고가용성 • 쿠버네티스 업데이트를 쉽게 할 수 있음 • EC2, ASG 등과 쉽게 통합 가능
- 18. 모두 다 테라폼으로! • 실섭에서 사용하는 거의 모든 AWS 자원을 테라폼으로 작성 • 1개월 정도의 시간 동안 1만+줄의 HCL 코드 작성 • 이 코드를 이용해 QA 환경에 그대로 띄움 • 그 후 쿠버네티스 클러스터도 테라폼으로 작성하여 새로 띄움
- 19. 쿠버네티스를 띄우자! • ECS 작업 정의를 쿠버네티스 구성 파일로 작성 • QA 환경에 배포 • 잘 작동하는지 테스트 • 수정 • QA 환경에 배포 • …
- 20. 쿠버네티스 어떻게 쓰는 거지 시행착오의 연속 • 그래서 요청은 어떻게 받는 거죠? • -> 인그레스 컨트롤러, 서비스, … • 스케일링은 어떻게? • -> 수평적 팟 스케일러, 클러스터 오토스케일러, … • 다음 챕터에서 자세히!
- 21. FULL QA 모든 서비스를 처음부터 끝까지 QA! • QA 환경에서 모든 서비스를 대상으로 테스트 OK! 배포합시다!
- 22. 배포 • BIG RED BUTTON을 누르면 배포!...는 아니고 • Route53을 이용한 점진 배포 spoqa.com 등의 도메인 ECS ALB 쿠버네티스 인그레스
- 23. 3. 어떻게 쿠버네티스를 사용하고 있는가?
- 24. alb-ingress-controller • AWS ALB를 쿠버네티스 인그레스로 사용 • ALB에서 각 팟의 아이피로 직접 라우팅해주거나 (ip type) • ALB에서 노드로 라우팅 후 노드 안에서 kube-proxy가 라우팅하게 할 수 있다 (instance type)
- 25. Prometheus 지표 수집 • 팟의 CPU, 메모리 사용량 등을 수집 • CloudWatch Adapter를 통해 인그레스의 요청량도 수집 • prometheus-operator를 통해 셋업 • https://github.com/prometheus-operator/prometheus-operator
- 26. Grafana 모니터링 대시보드 • 프로메테우스에서 수집한 지표를 시각화 및 알람
- 27. Cluster Autoscaler • 노드의 사용량에 맞춰서 • 새 노드를 추가하거나 • 필요 없는 노드를 종료 • AWS EKS를 사용한다면 엄청나게 쉽게 세팅 가능 • https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
- 28. Horizontal Pod Autoscaler • 팟의 지표에 따라서 • 새 팟을 띄우거나 • 필요 없는 팟을 종료 • 쿠버네티스에 내장된 metrics server나 prometheus 등의 지표 수집기가 필요
- 29. AWS Fargate 서버리스 컴퓨팅 엔진 • AWS EKS에서는 EC2 인스턴스 뿐만이 아니라 파게이트도 노드로 사용할 수 있다 • 사용한 만큼 청구되어 경제적 • 한 팟이 하나의 노드에만 할당되므로 노드의 장애가 여러 서비스의 장애로 이어지지 않는다 • 스포카에서는 선택적으로 사용 중
- 30. Helm 쿠버네티스 패키지 매니저 • 쿠버네티스의 여러 리소스를 묶어서 관리할 수 있는 툴 • 차트 버전 관리 등을 통해 형상관리도 가능 • 스포카에서는 빠른 배포를 위한 템플릿 엔진과 • 배포 기록 관리 및 롤백을 위해서만 사용 중
- 31. 배포 CircleCI + Helm • 써클씨아이에서 헬름을 통해 배포 • helm-diff 플러그인으로 변경사항도 미리 볼 수 있음
- 32. 4. 쿠버네티스, 사용해보니…
- 33. 달라진 점 • kubectl, Lens, Grafana 등을 통한 편리한 모니터링과 관리 • 훨씬 빠른 배포, 롤백 • 줄어든 장애와 빠른 장애 대응 • 쉽고 빠른 인프라 업데이트 • 빠르고 간편한 QA
- 34. 장애 경험 • ALB 인그레스 컨트롤러로 인한 장애 • IP 타입을 사용할 때 팟의 업데이트를 컨트롤러가 충분히 빠르게 반영하지 못하여 에러 레이트가 올라감 • 인스턴스 타입으로 변경하여 해결
- 35. 감사합니다