[k8s] Kubernetes란?

 

쿠버네티스 완벽 가이드:입문부터 실제 운용까지 필요한 기술 총망라!

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

 

 

 

🚀 [k8s] Kubernetes

    🔽 개요

        📦 소개

K8s는 Container화된 Workload와 Service를 관리하기 위한 이식성이 있고, 확장 가능한 오픈 소스 플랫폼을 이야기 합니다.

k8s는 선언적 구성과 자동화를 모두 용이하게 해준다고 해요.

k8s의 명칭은 키잡이(helmsman) 즉, 파일럿을 뜻을 가진 그리스어에서 유래 했다고 해요.
K8s라는 표기는 K와 s 사이에 8글자가 있기 때문에 이를 줄여서 표현하는 것이에요.

k8s는 Google이 2014년 해당 프로젝트를 오픈소스화 하였어요. 즉, 무료로 사용할 수 있게 하였다는 뜻이죠.

 

 

 

    🔽 Kubernetes

        📦 Application 구동 방식의 변천사

이 이야기를 하기 전에 먼저 용어부터 정리해 보고 갈게요.

용    어	내     용
Container	Application이 구동되는 환경까지 감싸 실행할 수 있도록 하는 격리 기술
Container Runtime	Container를 다루는 도구
Docker	Container를 다루는 도구 중 가장 많이 사용되는 도구
Kubernetes	Container Runtime을 통해 Container를 Orchestration하는 도구
Orchestration	여러 서버에 걸친 Container 및 사용하는 환경 설정을 관리하는 작업

Container는 사용자가 구동하려는 Application을 실행할 수 있는 환경까지 감싸 어디서든 쉽게 실행할 수 있도록 해 주는 기술을 말해요.

예를 하나 들자면 PC에 Program을 설치할 때, 특정 Path(경로)를 맞춰 설치하거나, PC Option에 필요한 것들을 하나하나 맞춰가면서 설치하는 과정이 있다면 매우 번잡스러울 거에요.

Container는 이러한 환경까지 모두 포함하여 Host 혹은 다른 Container와 독립적으로 Program 실행을 가능하게 해주는 기술이에요.

Container 환경을 묶어 배포한 Container Image를 내려 받아 구동하면 실행되기 때문에, 각종 설정 과정이 줄어 들어 보다 편리하게 이용할 수 있답니다.

 또한, Container를 사용할 때, 필요한 도구가 Container Runtime이라는 건데, 이것은 Container를 쉽게 내려 받거나, 공유하고, 구동할 수 있도록 해주는 도구를 말해요.

종류 또한 여러가지가 있는걸 혹시 알고 계셨나요? 그 중 가장 유명하고, 많이 이용되는 것이 바로 Docker에요. Docker가 사용하는 Container 규격은 표준화 되어 있기 때문에 Docker가 아닌 다른 Container Runtime들도 Docker로 만든 Container를 사용할 수 있답니다.

k8s는 Container Runtime을 통해 Container를 다루는 도구를 말해요. k8s가 해주는 일은 여러 Server(Node 라고 칭함)에 Container를 분산 배치하거나, 문제가 생긴 Container를 교체하거나, Container가 사용할 비밀번호나, 환경 설정을 관리하고, 주입해 주는 일 등을 한답니다. 이러한 작업들을 Container Orchestration이라고 해요.

또한, k8s는 Docker를 다루는 기술은 아니에요. 위에서 이야기 했 듯 k8s는 Container 분산 배치, 상태 관리 및 Container 구동 환경까지만 관리하는 도구이고, Docker는 Container를 다루는 도구(Container Runtime)도구 중 하나에요.

k8s는 Container를 다루기 위해 Docker 외에 다양한 Container Runtime Software와 연동할 수 있어요.

출처: https://kubernetes.io/ko/docs/concepts/overview/

 

k8s나, Docker를 검색하면 많이 보았을 그림이에요.

Virtualized Deployment에서 Hypervisor와 Container Deplyment에 Container Runtime 그리고, VM, Bin/Library, App이라는 용어는 과연 무엇일까요?

최초 Traditional Deployment은 가상화 이전 상황을 말하는데, 우리가 PC를 구매해서 OS를 설치하고, 그 곳에 Program을 설치하는 방식을 이야기 해요.

가상화가 나오기 이 전에는 한 대의 물리 Server에 OS를 올리고, 여러 Application을 설치하는 방식으로 Server를 도입했고, 또 다른 Server가 필요하면 물리 Server를 추가 구매하는 방식으로 운영을 했었어요.

하지만, Server의 비용이 고가이고, 여러 Server를 보유할 Rack과 그 Rack을 보관할 장소를 만든다는 건 Service 주체 입장에선 굉장히 부담스러운 일이 아닐 수 없어요.

또한, 한 대의 PC에서 모든 것을 처리하려고 할 때, A라는 Program이 다른 Program 동작을 간섭하거나, 특정 Program이 자원을 독점할 경우 또 다른 Program의 성능이 떨어지는 등의 단점이 있을 수 있어요.

이러한 문제를 해결하기 위해 나온 방안이 있었으니 바로 Virtualized Deployment 방식이에요.

이는 가상 머신을 기반으로 Server를 구축하는 방법인데, 주니쓰가 Server 구축을 위해 이 전에 작성했던 글들을 보면 ESXi, VMware Workstaion, Hyper-V 등과 같은 것을 설치하고, 가상 머신을 설치하고 있다고 언급 하고 있어요.

이러한 것들은 가상화를 하기 위한 OS 혹은 Program이에요.

이 때, Hypervisor라는 용어가 나오는데, 이것은 하나의 System에 여러 가상 머신을 여러 개 구동할 수 있도록 해주는 중간 계층을 의미해요. 즉, 실제 물리 장비에 OS를 올리고, 가상화를 할 수 있게 도와주는 OS나, Program안에 내장된 Hypervisor를 통해 또 다른 가상의 OS를 올려 전혀 다른 PC를 사용하는 듯한 환경을 구축할 수 있는 것이에요.

Virtualized Deployment 방식은 가상 컴퓨터를 만드는 방식이기 때문에 실제 물리 PC에도 CPU, RAM, SSD와 같은 부품들을 조립해 주듯 가상 머신에도 CPU, RAM, 저장 장치들을 가상으로 분배해서 할당해 줄 수 있어요.

이런 방식을 통해 Traditional Deployment 방식에서 오는 여러 물리 Server 구매 혹은 다른 Program과의 문제 등을 어느 정도 해결은 했지만, 여전히 물리 Server를 구매해야 하고, 자원 관리를 해야 한다는 단점과 함께 추가적으로 OS가 올라가기 때문에 무겁다는 단점을 가지고 있어요.

이러한 단점들을 극복하고자 나온 것이 바로 Container Deployment 방식이에요.

Hypervisor 대신 Container Runtime을 쓰고 있는걸 확인할 수 있는데, Container는 가상 머신과 달리 Program 구동을 위한 가상 OS 설치가 필요없는 장점이 있어요.

즉, Host OS 하나만 설치하면 된다는 의미에요.

Container 기반 방식은 전통적 방식 위에 Container Runtime이 올라가 구동이 되는데, Container는 OS 밑에 작업들이 어떻게 구동되는지 직접적으로 연관 지어 구동되지 않아서 그렇기 때문에 가상 머신 위에 올라간 OS에서 추가로 Container 방식을 사용할 수 있고, 주니쓰는 그렇게 Server 구축을 하려고 하고 있어요.

다만, 주의할 점은 Container 방식은 Host OS를 공유하기 때문에 어떤 Program에 문제가 생기면 다른 Program에게 영향을 끼치진 않아요. 하지만, Program 문제가 Host OS에 문제를 야기시킬 경우 Host OS에서 구동중인 전체 Container에 문제가 발생될 수는 있어요.

Container 방식은 Linux 기준으로 각각의 Application들을 독립된 환경에서 실행되는 것처럼 격리해 주고, CPU, RAM과 같은 자원도 독립적으로 사용할 수 있도록 해주는 namespace 및 cgroup 기술이 탑재 되어 있어요.

	Traditional Deployment	Virtualized Deployment	Container Deployment
물리 장비	각각의 Application 격리 필요 시 물리 장비 N대	물리 장비 1대에 다수 가상 머신 구축이 가능하나, 자원 부족 시 추가 장비 구매 필요	물리 장비에 영향이 적음
운영체제	물리 장비에 1개 운영체제 설치	물리 장비 1대에 운영체제 설치 및 다수의 가상 머신에 각각의 OS 설치 필요	물리 장비 1대에 운영체제 설치
자원 (Resource)	물리 장비의 자원을 여러 Application이 나눠 갖는 방식	Hypervisor를 통해 가상 머신 별 개별적 자원 할당	Host 운영체제에서 Application 별 자원 할당 및 관리
격리 수준	X	가상 머신 별 자원을 나눠 독립적으로 구동하는 방식	OS 환경은 공유하나, Application 환경은 각각 격리
문제 전이 여부	특정 Application 문제 발생 시 System 전체 문제 야기	Host OS 문제 발생 시 모든 가상 머신 중단될 가능성이 있으나, 각각의 가상머신에서 발생한 문제가 다른 가상 머신에게 영향을 끼칠 가능성은 낮음	Host OS 문제 발생 시 모든 Container가 중단될 가능성이 있으며, 특정 Application 문제가 다른 Application에 영향을 끼치진 않음

728x90

 

즉, Container를 이용하게 되면 Server에서 1명의 관리자가 다양한 Application을 사용할 수 있기 때문에 각각의 Program을 Container로 구현할 필요가 거의 없다고 해요.

기업 환경에서 다수의 관리자가 수백, 수천 대 Server를 함께 관리하기 때문에 일관성이 굉장히 중요해요.

물론 기깔나는 사람들은 그 정도에 Server를 구축하진 못하겠지만, 기업과 같이 프로젝트를 해 보는 것이 컨셉인 만큼 이 부분도 굉장히 심도있게 고려하고 있어요.

이런 경우 Container Infra 환경을 구성한다면 여러 사람이 작업하여 설정의 일관성이 떨어지는 문제를 방지할 수 있어요.

또한, 가상화 환경에서 각각의 Virtual Machine이 모두 독립적인 OS Kernel을 가지고 있어야 하기 때문에 위에서 이야기 한대로 자원 낭비가 심할 수 있는데, Container Infra의 경우 OS Kernel 하나에 Container 여러 개가 격리된 형태로 실행되므로, 자원을 보다 효율적으로 사용할 수 있고, 단계 단계 거치는 것들이 적어 속도도 훨씬 빠르다는 장점을 가지고 있어요.

하지만, 한가지 참고해야 할 사항은 Container 환경에서 Window는 구동할 수 없어요.
이는 Container가 Linux Kernel 기반이기 때문이에요.

k8s는 가상화 환경 상용 솔루션을 이용해 안정적으로 System 운용이 가능했고, 관리 되었던 지난 과거가 있었고, 지금도 이를 이용해서 System을 구축하는 곳이 많지만, 시간이 지나면서 Kernel를 통해 더 많은 Application을 올릴 수 있는 Container가 도입되면서 늘어난 Conatiner 관리 필요성이 생겨 버린 것이에요.

기존 Container 관리 솔루션이였던 Docker Swarm, Mesos, Nomad 등은 현업의 요구 사항을 충족 시키기엔 너무 과하거나, 부족한 점이 있었어요.
이러한 이유로 Container Infra 환경이 주는 많은 장점에도 불구하고, 보편화가 어려웠지요.

k8s는 이러한 것들을 다듬어 나온 Container 관리 솔루션이에요.

 

 

 

    🔽 k8s와 친해지기

        📦 Container Ohchestration

종  류	상세 내용
Docker Wwarm	∙ 간단한 설치, 사용 용이 ∙ 기능이 다양하지 않아 대규모 환경에 적용 시 사용자 환경 변경 필요 ∙ 소규모 환경에 유용
Mesos	∙ Apache Open Source Project로 Twitter, 에어비엔비, Apple, Uber 등에서 검증된 솔루션 ∙ 2016년 DC/OS    (Data Center OS, 대규모 환경에서 자원을 유연하게 공유하며, 하나의 자원처럼 관리하는 도구) 지원으로     매우 간결해짐 ∙ 기능을 충분히 활용하고자 한다면 분산 관리 시스템 연동 필요 ∙ 여러가지 솔루션을 유기적으로 구성해야 하는 부담
Nomad	∙ 베이그런트를 만든 해시코프사의 Container Ohchestration ∙ 간단한 구성으로 Container Ohchestration 환경 제공 ∙ 기능이 부족하여 여러 기능을 사용하는 환경이 아닌 가볍고, 간단한 기능만 필요한 환경에서 사용 권장 ∙ 해시코프의 Consul(서비스 검색, 구성 및 분할 기능 제공)과 Vault(암호화 저장소)와의 연동이 원할하여    이런 도구에 대한 사용 성숙도가 높은 기업 혹은 조직인 경우 도입해도 좋음
Kubernetes	∙ 다른 솔루션에 비해 러닝 커브가 다소 있으나, 쉽게 사용할 수 있는 도구들이 있어 설치가 쉬워지는 추세 ∙ 다양한 형태로 발전하고 있으며, Container Ohchestratio을 넘어 IT Infra 자체를 Container화 하고,    Container화된 Infra 제품군을 k8s 위에서 동작할 수 있게 해줌 ∙ 많은 Vender와 Opne Source 진영에서 k8s를 지원하고, 그에 맞게 통합 개발 중

 

 

💡 용어 정리
1. Ohchestration
   복잡한 단계를 관리하고, 요소들의 유기적 관계를 미리 정의하여 손쉽게 사용하도록 서비스 제공하는 도구

2. Container Ohchestration
    다수의 Container를 유기적으로 연결, 실행, 종료할 뿐 아니라, 상태 추적 및 보전하는 등 Container를 안정적으로
    사용할 수 있게 해주는 도구

 

 

 

        📦 k8s 구성 방법

종    류	상세 내용
관리형 k8s	Public Cloud 업체에서 제공하는 관리형 k8s인 EKS(Amazon Elastic Kubernetes Service), AKS(Azure Kubernetes Service), GKE(Google Kubernetes Service) 등 구성이 이미 다 갖춰져 있고, Master Node를 Cloud 업체에서 관리하기 때문에 초보자가 학습용으로 이용하기엔 부적절
설치형 k8s	Suse의 Rancher, Red Hat의 OpenShift와 같은 Platform에서 제공하는 설치형 k8s 유료이기 때문에 쉽게 접근이 어려움
구성형 k8s	사용하는 System에 k8s Cluster를 자동으로 구성해주는 솔루션 사용 주요 솔루션: kubeadm, kops(Kubernetes Operation), KRID(Kubernetes Rebar Integrated Bootstrap), Kuberspray (kubeadm이 가장 보편화됨.) kubeadm은 사용자가 변경하기 수월하며, On-premises와 Cloud를 모두 지원하며, 러닝 커브가 약한 편

반응형

 

Cloud Native Landscape

 

 

k8s는 오픈 소스 기반의 Container화 된 Application(Work load & Service)의 자동 배포, 스케일링 등을 제공하는 관리 Platform이에요.

K8s와 Docker는 엄연히 다른 솔루션이에요. K8s와 Docker는 상호 대체할 수 없어요.

K8s는 Container 가상화 기술을 이용한 Service, Packaging된 Serivce의 자동 배포, Scaling 작업을 도와주는 도구에요.





K8s의 장/ 단점

장       점	단       점
Container화 된 Application 구동	Source Code 배포 불가, Build 불가
Service Discovery & Load balancing	Application Level Service 지원 없음
Storage orchestration	Logging, Monitoring Solution 지원 없음
자동화된 Roll Out, Roll Back	포괄적 Machine Setting, 유지보수, 관리, 자동 복구 시스템 제공 없음
자동화된 Bin Packing
자동화된 Self-Healing (복구)
Secret & composition Management (구성 관리)

K8s Cluster란?

K8s는 Master Node(각각의 Work Node 관리)와 실제 Container 자체 운영, 스케쥴링을 담당하는 것이 Work Node이고, 이 두가지를 합쳐서 부르는 것이 K8s Cluster에요.

Master Node 안에는 설정 정보(etcd), 사용자 스케쥴 관리(sched), api 등을 처리할 수 있도록 구성이 되어 있어요.

Work Node 안에는 실제로 운영하고자 하는 Container들을 관리하기 위한 pod라는 개념, 이 pod를 운영하기 위한 kubelet이라는 개념이 포함되어 있어요.

 
개발자나, 관리자가 각각의 접근 Tool(UI를 가진 Web Service Tool 혹은 CLI Tool)로 K8s Master Node API에 명령어를 전달하면 API는 자기가 가용할 수 있는 Work Node들에게 개발자나, 관리자가 보낸 명령어를 전달하게 되요.

API가 전달한 명령어는 Cube(K8s) Proxy가 받는 역할을 하는데,  Cube(K8s) Proxy는 Cluster의 각 Work Node에서 실행되고 있는 Network Proxy에요.
즉, K8s에서 Service의 개념으로 보면 좋을 거 같아요. 이 친구는 Network에 유지, 관리를 담당하고 있어요.

Master Node에서 각각 가용할 수 있는 Work Node에 어떤 명령어를 전달하면 사용 가능한 Container를 Pod 형태로 묶어서 사용 가능하는 것이 일반적인 형태에요.

K8s는 사용할 수 있는 최소한의 단위인 Pod라는 형태로 묶어 배포를 하게 되고, 이 Pod안에는 여러 Container가 존재할 수 있어요.

각각의 Work Node는 Container를 운영하기 위한 Container Engine을 가지고 있어야 해요.

Work Node를 단일 Node로 구성할 수도 있지만, 안정적인 Service를 위해 Multi Node를 가지고, K8s Cluster를 구성하는게 좋아요.

Pod안에 포함되어 있는 즉, Work Node안에 포함되어 있는 Service를 확대해서 살펴볼게요.

일단, Service와 Pod 개념이 존재하는데, 이 두 친구는 K8s가 사용할 수 있는 Object 또는 자원(Resource)라고 불리는 개념이고, Service는 각각의 Pod 간에 Data를 주고 받을 수 있도록 Network 관련 작업을 처리하는 친구에요.

Pod는 Container들이 Packaging 되어 있는 최소한의 단위이고, Application들이 묶여 있는 것이라고 보면 될 거 같아요.

🧐 참고 자료

[DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Jenkins + Ansible + Kubernetes 와의 연동

 

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

 

 

 

 

쿠버네티스 완벽 가이드:입문부터 실제 운용까지 필요한 기술 총망라!

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."