브렌쏭의 Veritas_Garage

Kubernetes :: 쿠버네티스 :: K8s 본문

[Project_하다]/[Project_공부]

Kubernetes :: 쿠버네티스 :: K8s

브렌쏭 2022. 5. 3. 16:45

```K8s```

- container orchestration -

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다.
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 
쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 

가상인듯 가상아닌 가상 같은 배포가 대세다

1. 전통적인 배포 시대: 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 애초에 컴퓨팅 성능이 후달리는 시대이기도 했다.

 

2. 가상화된 배포 시대: 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다. 샌드박스의 시대가 열렸노라.

 

3. 컨테이너 개발 시대: 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. 도커의 시대다.

 

4. 쿠버네티스의 시대 ( 자칭 )

그런 시대가 왔다고 주장하는 녀석은 매년 있어왔지만 이놈은 다르다

본래 쿠버네티스는 구글에서 개발되고 사용되던 Borg의 후속이라고 볼 수 있다.

온갖 서비스와 기능을 컨테이너화 시켜서 15년 이상 써먹던 구글이 오픈소스로 풀어버린 녀석인 것이다. 

https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/

 

Borg: The Predecessor to Kubernetes

Google has been running containerized workloads in production for more than a decade. Whether it's service jobs like web front-ends and stateful servers, infrastructure systems like Bigtable and Spanner, or batch frameworks like MapReduce and Millwheel, vi

kubernetes.io

쿠버네티스는 무엇인가? 혹은 무엇이 아닌가.

재밌게도, 쿠버네티스를 정의하는 방법은 이 물건이 어떤 기능이 있는지가 아니라, 이 기술이 아닌 것을 서술하는 방식이다. 꽤 훌륭하군

  • 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
  • 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
  • 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
  • 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
  • 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
  • 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
  • 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

이거 완전 결과적으로 되기만 하면 장땡이라는 건데, 뭐 맞는 말이긴 하지.

 

K8s의 구성

뭐가 많이 복잡해 보이는데, 복잡한거 맞다

1. 컨트롤 플레인 컴포넌트 :: 마스터노드

  • kube-apiserver : API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드
  • etcd : 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소
  • kube-scheduler : 노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택
  • kube-controller-manager : 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트
  • cloud-controller-manager : 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 

어 좀 아찔해지는데....

 

2. 노드 컴포넌트 :: 워커노드

  • kubelet : 클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.
  • kube-proxy : 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.
  • 컨테이너 런타임 : 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어

하여튼 많은 곳을 알아서 관리해준다는 점이 요인 것 같다.

 

다른 것들과의 차이

전부 다 그럭저럭 비슷해 보이는데, 왜 쿠버네티스를 쓰는가?

일단 하나에 이 집약된 덩어리들을 설치하는 것이 아니다. 여러대의 컴퓨터에 분산해서 네트워크로 연결하고, 구현 해내야 하는데, 이게 물리적으로 쉽지가 않다. 그리하여 이 과정들을 클라우드에서 진행하게 되는데, 대부분의 클라우드는 쿠버네티스를 사용한다.

이런 난장판을 관리해주는 것이 쿠버네티스다

클라우드에서 밀어주는 놈이 쿠버네티스이므로, 자연스레 이것만 쓰게 되는 것이다. 그리고 다들 이것을 쓰니, 쿠버네티스 위주로 문서를 찾기도 쉽고 이슈 해결도 용이하다.

클러스터 : {  마스터노드 > 워커노드 > 파드 > 도커컨테이너  }

물론 팟 안에 도커를 와장창 넣어두는 것은 아니고, 보통 의존성이 높은 것들을 몰아넣거나, 아니면 팟 하나당 컨테이너는 하나정도다.

순식간에 어지러워진다

결국 아까의 사진과 동일한 구조다. 여기에 추가적으로 애드온들이 더해져서 웹UI 라던가.. 같은게 붙는다.

로드밸런서와의 차이?

로-드 밸런서
쿠-버네티스

무중단 배포를 하기에 편하다는 점이다. 기존의 방식도 무중단 배포를 할 수 있지만 수동적으로다가 노가다를 해야한다.

로드밸런서의 경우 :
새로운 버전 api를 새로운 컴퓨터를 놓고 설치한뒤, git clone하고 머지해서 올린다.
그리고 아무도 모르게 도메인을 새로운 컴퓨터로 스무스하게 옮겨야한다. 
요청이 끊기지 않게 잘 보내주고 다시 요청이 오면 응답전에 새로운 컴퓨터를 돌리는 것이다.

근데 새로운 기능에 버그가 있어서 롤백을 해야한다? 그럼 창고에 넣으려던 이전 컴퓨터를 다시 들고와서 도메인을 재연결하고 되돌리는 것이다.

  • 아니라면, 퍼센트를 할당하고 조금씩 조금씩 이전을 하는 롤링 배포를 한다.
  • 혹은 소수를 할당해서 테스트가 완료되면 한방에 옮기는 카나리 배포.
  • 또는 반반으로 나눠서 진행하는 블루/그린 배포가 있다. 

근데 이게 만만치 않은 작업이다. 도메인부터 일단 어떻게 나눌 것이며.. 답답한 속도도 문제다. Load balncer는 가상 컴퓨터(instance) 위에서 docker container가 실행되는데 이때 인스터스가 실행되는 속도가 ....

쿠버네티스는 : 자동으로 롤링배포 기본설정이다. 카나리도 블루/그린도 옵션으로 제공한다

아니 너무 편하잖아; + 오토 스케일링도 지원한다. 안쓸수가 없다

https://kubernetes.io/ko/docs/concepts/overview/components/

 

쿠버네티스 컴포넌트

쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.

kubernetes.io

https://kubernetes.io/ko/docs/tasks/

 

태스크

운영 수준의 컨테이너 오케스트레이션

kubernetes.io

 

Comments