쿠버네티스
- 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
- 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있음.
- 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있음.
- 이름의 유래 : 파일럿
전통적인 배포 시대
- 초기 조직에선 애플리케이션을 물리 서버에 실행함.
- 한 물리 서버에서 여러 애플리케이션 리소스 한계를 정의할 방법이 없어, 소스 할당 문제가 발생하게 됨.
- 예를 들어, 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있음.
- 해결책 : 서로 다른 여러 물러 서버에서 각 애플리케이션을 실행하는 것.
- 그러나, 리소스가 충분히 활용되지 않는다는 점에서 확장 불가능.
- 물리 서버를 많이 유지하기 위해 조직에게 많은 비용 소모.
가상화된 배포 시대
- 전통적인 배포시대의 해결책으로 가상화 도입.
- 단일 물리 서버의 CPU에서 여러 가상 시스템(VM)을 실행할 수 있게 함.
- 가상화를 사용하면 VM간 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성 제공.
- 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트 가능.
- 하드웨어 비용 절감, 확장성 제공.
- 가상화를 통해 일련의 물리 리소스를 폐기 가능한 가상 머신으로 구성된 클러스터 만들 수 있음.
- 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신.
컨테이너 개발 시대
- 컨테이너는 VM과 유사하나, 격리 속성을 완화하여 애플리케이션 간 운영체제(OS)를 공유.
- 그러므로, 컨테이너는 가볍다고 여겨짐.
- VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 존재.
- 기본 인프라와의 종속성을 끊었기 때문에 클라우드나 OS 배포본에 모두 이식할 수 있음.
컨테이너가 제공하는 추가적인 혜택
-
기민한 애플리케이션 생성과 배포: VM이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적. -
지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포 가능(이미지 불변성), 바르고 효율적으로 롤백 가능. -
개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리됨. - 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있음.
-
개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동됨. -
클라우드 및 OS 배포판 간 이식성: ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동. -
애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS상에서 애플리케이션을 실행하는 수준으로 추상화 수준 높아짐. -
느슨하게 결합되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있음. -
리소스 격리: 애플리케이션 성능을 예측할 수 있음. -
자원 사용량: 리소스 사용량. 고효율 고집적.쿠버네티스가 왜 필요하고 무엇을 할 수 있나?
- 컨테이너 : 애플리케이션을 포장하고 실행하는 좋은 방법.
- 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 함.
- 예를 들어, 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 하는데, 이 문제를 시스템에 의해 처리한다면? ⇒ 쿠버네티스가 필요한 이유.
- 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크 제공.
- 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공. (시스템의 카나리아 배포를 쉽게 관리할 수 있다)
쿠버네티스가 제공하는 항목들
- 서비스 디스커버리와 로드 밸런싱
- DNS이름을 사용하거나 자체 IP 주소를 사용해 컨테이너 노출 가능.
- 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 안전적인 배포가 이루어질 수 있도록 함.
- 스토리지 오케스트레이션
- 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템 자동 탑재 가능.
- 자동화된 롤아웃과 롤백
- 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경 가능.
- 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용 가능.
- 자동화된 빈 패킹
- 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공.
- 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에게 지시.
- 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해줌.
- 자동화된 복구
- 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, ‘사용자 정의 상태 검사’ 에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않음.
- 시크릿과 구성 관리
- 전통적인, 모든 것이 포함된 Platform as a Service(PaaS) 가 아님.
- 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영.
- 모놀리식이 아니며, 기본 솔루션은 선택적이며 추가, 제거 용이.
- 개발자 플랫폼을 만드는 구성 요소를 제공하나, 필요한 경우 사용자의 선택권과 유연성 존중.
- 지원하는 애플리케이션의 유형을 제약하지 않음. (애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것)
- 소스 코드 배포 없음, 애플리케이션 빌드하지 않음.
- 지속적 통합, 전달, 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 다를 뿐만 아니라 기술적인 요구사항으로 결정됨.
- 애플리케이션 레벨의 서비스를 제공하지 않음. 애플리케이션 레벨의 서비스에는 미들웨어(메세지 버스), 데이터 처리 프레임워크(Spark), 데이터베이스(MySQL), 캐시 또는 클러스터 스토리지 시스템(Ceph)등이 있음. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 매커니즘을 통해 접근할 수도 있다.
- 로깅, 모니터링 도는 경보 솔루션을 포함하지 않음. 개념 증명을 위한 일부 통합, 메트릭을 수집하고 노출하는 메커니즘 제공.
💡 메트릭
라우팅 프로토콜들이 최적경로를 선택하는 기준
- 기본 설정/언어 시스템을 제공하거나 요구하지 않음. 선언적 명세의 임의적 형식을 목적으로 하는 선언적 API 제공.
- 포괄적 모신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않음.
- 쿠버네티스는 단순 오케스트레이션 시스템이 아님. 오케스트레이션의 필요성을 없애는 데 중점을 두고 잇음.
💡 오케스트레이션
A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것.
- 반면, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성됨. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 함.
A에서 C로 어떻게 갔는지는 상관 없음. 중앙화된 제어도 필요치 않음. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해짐.색인과 출처
- 쿠버네티스 기초~중급 : https://www.youtube.com/watch?v=l42GttmnnZ4
- 개념 : https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
- https://boying-blog.tistory.com/8