일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- applicationset
- 위임
- kubenetes
- maven
- 피터코드의 상속규칙
- 어플리케이션셋
- 쿠버네티스
- 쿠버네티스 어노테이션
- 상속성
- 레이블
- 메이븐
- delegation
- Abstraction
- ArgoCD
- 캡슐화
- 추상화
- OOP
- kubernetes in actin
- kubernetes in action
- kubenetes architecture
- 객체지향
- 빌드
- argocd applicationset
- kube
- kubenetes in action
- kubernetes
- 피터코드
- kubernetes component
- Encapsulation
- 레이블 셀렉터
- Today
- Total
IT 끄적장
#4 kubernetes 사용의 장점 본문
모든 서버에 쿠버네티스를 설치한 경우 운영 팀이 더 이상 애플리케이션 배포를 처리할 필요가 없다.
컨테이너화 된 애플리케이션을 배포하고 실행하기 위해 아무것도 설치할 필요가 없다.
쿠버네티스가 배포된 모든 노드에서는 시스템 관리자의 도움 없이 즉시 애플리케이션을 실행할 수 있다.
애플리케이션 배포의 단순화
쿠버네티스는 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리케이션 배포를 시작할 수 있으며 클러스터를 구성하는 서버에 관해 알 필요가 없다.
본질적으로 모든 노드는 이제 애플리케이션이 해당 노드를 사용하기를 기다리는 하나의 컴퓨팅 리소스다.
서버는 애플리케이션에 적절한 시스템 리소스를 제공할 수 있는 한, 애플리케이션이 어느 서버에서 실행 중인지는 신경 쓰지 않는다.
개발자가 애플리케이션을 특정 종류의 하드웨어에서 실행해야 하는 경우가 있다. 노드가 이기종인 경우 특정 기능이 있는 노드에서 애플리케이션을 실행하고 다른 애플리케이션은 다른 노드에서 실행하는 경우가 있다.
예를 들어, 애플리케이션 중 하나가 HDD 대신 SSD가 있는 시스템에서 실행돼야 하고 다른 애플리케이션은 HDD에서 실행돼도 상관이 없을 경우 특정 애플리케이션이 항상 SSD가 있는 특정 노드를 한 선택해 애플리케이션을 배포한다. 그러나 쿠버네티스를 사용하는 경우 애플리케이션을 실행할 특정 노드를 선택하는 대신, 쿠버네티스에 SSD가 있는 노드 중 하나만 선택하도록 지시하는 것이 더 적절하다.
하드웨어 활용도 높이기
서버에 수동으로 애플리케이션을 실행하는 대신 쿠버네티스를 설정하고 애플리케이션을 실행함으로써, 인프라와 애플리케이션을 분리할 수 있다. 쿠버네티스에 애플리케이션을 실행하도록 지시하면 애플리케이션의 리소스 요구사항에 대한 디스크립션과 각 노드에서 사용 가능한 리소스에 따라 애플리케이션을 실행할 가장 적합한 노드를 선택할 수 있다.
컨테이너를 사용하고 애플리케이션을 클러스터의 특정 노드로 지정하지 않으면 언제든지 애플리케이션이 클러스터 간에 자유롭게 이동할 수 있으므로 클러스터에서 실행되는 다른 애플리케이션 구성요소를 혼합해 클러스터 노드에 배치할 수 있다. 노드의 하드웨어 리소스를 최대한 활용할 수 있다.
쿠버네티스는 언제든지 클러스터 간에 애플리케이션이 이동할 수 있으므로, 수동으로 수행하는 것보다 훨씬 더 인프라를 잘 활용할 수 있다.
사람은 최적의 조합을 찾는 데 능숙하지 않다. 특히 애플리케이션 구성 요소가 많고 배포할 서버 노드가 많은 경우와 같이, 가능한 옵션의 수가 많을 때 컴퓨터는 분명히 이 작업을 사람보다 훨씬 더 빠르고 더 잘 수행할 수 있다.
상태 확인과 자가 치유
서버 장애 발생 시 언제든지 클러스터 간에 애플리케이션을 이동할 수 있는 시스템을 갖추는 것도 중요하다. 클러스터 크기가 증가하면 컴퓨터의 구성요소의 고장을 더 자주 처리하게 된다.
쿠버네티스는 애플리케이션 구성 요소와 이 애플리케이션이 구동 중인 노드를 모니터링하다가 노드 장애 발생 시 자동으로 애플리케이션을 다는 노드로 스케줄링한다. 이로써 운영 팀은 애플리케이션 구성 요소를 수동으로 마이그레이션 할 필요가 없어지고, 애플리케이션을 재배치하는 대신 즉시 노드 자체를 수정해 사용 가능한 하드웨어 리소스 풀에 반환하는 데 집중할 수 있다.
인프라에 장애가 발생한 노드가 없어도 정상적인 시스템 작동이 가능하도록 충분한 예비 자원이 있는 경우 운영팀은 새벽 3시에 일어난 장애에 즉시 대응할 필요가 없다.
오토스케일링
쿠버네티스를 사용해 배포된 애플리케이션을 관리한다는 것은 급격한 부하 급증에 대응하기 위해 개별 애플리케이션의 부하를 운영팀이 지속적으로 모니터링할 필요가 없음을 의미한다.
앞서 언급했듯이 쿠버네티스는 각 애플리케이션에 사용하는 리소스를 모니터링하고 각 애플리케이션의 실행 중인 인스턴스 수를 계속 조정하도록 지시할 수 있다.
클라우드 인프라에서 쿠버네티스가 실행 중인 경우 클라우드 제공업체의 API로 쉽게 노드를 추가하면 배포된 애플리케이션의 부하에 따라 전체 클러스터 크기를 자동으로 확장하거나 축소할 수 있다.
애플리케이션 개발의 단순화
애플리케이션 개발과 프로덕션 환경이 모두 동일한 환경에서 실행된다는 사실로 돌아가 보면 버그가 발견됐을 때 큰 효과가 있다. 버그를 빨리 발견할수록 버그를 수정하는 것이 쉽고, 수정에 더 적은 작업이 필요하다는데 동의할 것이다. 버그를 해결하는 개발자의 작업이 줄어든다.
또한 개발자가 일반적으로 구현해야 하는 기능을 구현할 필요가 없어진다. 여기에는 클러스터 된 애플리케이션 서비스나 피어를 검새하는 기능도 포함된다. 쿠버네티스가 애플리케이션 대신 이 작업을 수행한다. 일반적으로 애플리케이션은 특정 환경 변수만 조회하거나 DNS 조회만 수행하면 된다. 충분하지 않다면 애플리케이션에서 쿠버네티스 API 서버를 직접 쿼리를 날려 해당 정보나 혹은 다른 정보를 얻을 수 있을 것이다.
새로운 버전의 애플리케이션을 출시할 때 쿠버네티스가 새로운 버전이 잘못됐는지 자동으로 감지하고 즉시 롤아웃을 중지한다는 것을 알고 있는 개발자들이 느끼는 신뢰성 또한 장점이라 할 수 있다. 이는 애플리케이션의 continuous delivery를 가속화해 조직 전체에 도움이 된다.
'Kubernetes' 카테고리의 다른 글
# 6 kubernetes 구성 요소_ Pod - 2 (0) | 2021.02.09 |
---|---|
# 5 kubernetes 구성 요소_ Pod - 1 (0) | 2021.02.09 |
# 3 kubernetes 동작 원리 (0) | 2021.02.03 |
#2 kubernetes 클러스터 컴포넌트 (0) | 2021.02.03 |
#1 쿠버네티스(Kubernetes)의 개념 (0) | 2021.02.02 |