Cloud Native application 및 기술을 조사했다면 CNCF에서 제공하는 Cloud Native 환경을 많이 접했을 것입니다.
CNCF Landscape 가이드는 이러한 많은 범주의 기술들을 기능 별로 깔금하게 구성하여 쉽게 탐색할 수 있게 해 줍니다.
1. Provisioning
프로비저닝은 클라우드 네이티브 환경의 첫 번째 계층입니다.
이 범주에는 클라우드 네이티브 앱이 구축되는 기반을 만들고 강화하는 데 사용되는 제품들이 포함됩니다.
| • 인프라를 자동으로 구성, 생성 및 관리하고 컨테이너 이미지를 스캔, 서명 및 저장하는 도구를 찾을 수 있습니다. • 정책 설정 및 시행, 내장된 인증 및 권한 부여, secret 배포 처리를 가능하게 하는 도구를 사용하여 보안으로 확장됩니다. |
프로비저닝 계층은 인프라 프로비저닝에서 컨테이너 레지스트리, 보안에 이르기까지 모든 것을 처리하는 도구를 사용하여 클라우드 네이티브 플랫폼 및 애플리케이션의 기반을 구축하는 데 중점을 둡니다.
1) Automation & Configuration
자동화 및 구성 도구는 컴퓨팅 리소스(가상 머신, 네트워크, 방화벽 규칙, 로드 밸런서 등)의 생성 및 구성 속도를 높입니다.
이 범주의 제품은 프로비저닝 프로세스의 다른 부분을 처리하거나 모든 것을 종단 간 제어하는 기능을 제공합니다.
전통적으로 IT 프로세스는 일반적으로 3개월에서 6개월 사이의 길고 노동 집약적인 수동 릴리스 주기에 의존했습니다.
이 범주의 제품을 사용하면 자동화를 통해 컴퓨팅 환경을 구축할 수 있습니다.
Terraform과 같은 자동화된 도구는 수백 개의 방화벽 규칙으로 수십 개의 서버와 네트워크를 확장하는 데 필요한 노력을 줄여줍니다.
Puppet, Chef 및 Ansible과 같은 도구는 신규 서버와 애플리케이션을 프로그래밍 방식으로 프로비저닝 및 구성하여 개발자가 사용할 수 있도록 합니다.
Kubernetes 클러스터를 위한 컴퓨팅 환경, CPU, 메모리, 스토리지 및 네트워킹을 배치하는 과정의 일부로 하나 이상의 자동화 도구가 필요합니다.
| 범주 | CNCF Projects |
| Infrastructure-as-Code (IaC) Automation Declarative Configuration |
● Akri (sandbox) ● CDK for Kubernetes (CDK8s) (sandbox) ● Cloud Custodian (incubating) ● DevStream (sandbox) ● KubeDL (sandbox) ● KubeEdge (incubating) ● Metal (sandbox) ● OpenYurt (sandbox) ● SuperEdge (sandbox) ● Tinkerbell (sandbox) |
2) Container Registry
클라우드 네이티브 애플리케이션은 패키징되어 컨테이너로 실행됩니다.
컨테이너 레지스트리는 이러한 앱을 실행하는 데 필요한 컨테이너 이미지를 저장하고 제공합니다.
모든 컨테이너 이미지를 한 곳에 중앙 집중식으로 저장하면 해당 앱에서 작업하는 모든 개발자가 쉽게 액세스할 수 있습니다.
기본적으로 레지스트리는 컨테이너 런타임이 이미지를 저장하고 검색할 수 있도록 하는 웹 API입니다.
이 범주의 제품들은 저장하는 이미지를 스캔, 서명 및 검사하기 위한 통합을 제공합니다.
Dragonfly와 Harbor는 CNCF 프로젝트이며 Harbor는 최근 최초의 OCI 준수 레지스트리라는 명성을 얻었습니다.
| 범주 | CNCF Projects |
| Container OCI Image Registry |
● Distribution (sandbox) ● Dragonfly (incubating) ● Harbor (graduated) ● zot (sandbox) |
3) Security & Compliance
보안 및 규정 준수 도구는 플랫폼 및 애플리케이션 보안을 강화, 모니터링 및 적용하는 데 도움이 됩니다
컨테이너에서 Kubernetes 환경에 이르기까지 이러한 도구를 사용하면 규정 준수를 위한 정책을 설정하고, 기존 취약성에 대한 통찰력을 얻고, 잘못된 구성을 포착하고, 컨테이너 및 클러스터를 강화할 수 있습니다.
컨테이너를 안전하게 실행하려면 알려진 취약점이 있는지 컨테이너를 스캔하고 변조되지 않았는지 확인하기 위해 서명해야 합니다.
이 범주의 제품과 프로젝트는 클러스터를 강화하고 시스템이 비정상적으로 작동하는 시기를 감지하는 데 도움이 됩니다.
| 범주 | CNCF Projects |
| Image scanning Image signing Policy enforcement Audit Certificate Management |
● cert-manager (incubating) ● Confidential Containers (sandbox) ● ContainerSSH (sandbox) ● Curiefense (sandbox) ● Dex (sandbox) ● external-secrets (sandbox) ● Falco (incubating) ● Hexa (sandbox) ● in-toto (incubating) ● Keylime (sandbox) ● KubeArmor (sandbox) ● Kubescape (sandbox) ● Kubewarden (sandbox) ● Kyverno (incubating) ● Notary (incubating) ● Open Policy Agent (OPA) (graduated) ● Open Policy Containers (sandbox) ● OpenFGA (sandbox) ● Paralus (sandbox) ● Parsec (sandbox) ● The Update Framework (TUF) (graduated) ● Keycloak (incubating) |
4) Key Management
애플리케이션과 운영이 새로운 클라우드 네이티브 환경에 적응함에 따라 보안 도구는 새로운 보안 요구 사항을 충족하도록 진화하고 있습니다.
이 범주의 제품 및 프로젝트는 암호 및 기타 Secret(API 키, 암호화 키 등과 같은 민감한 데이터)을 안전하게 저장하는 방법부터 마이크로 서비스 환경에서 암호 및 Secret을 안전하게 제거하는 방법에 이르기까지 모든 것을 다룹니다.
또한 Secret 및 key 또는 인증, 권한 부여와 관련된 서비스 또는 사양을 안전하게 배포하는 방법을 제공합니다.
| 범주 | CNCF Projects |
| AuthN and AuthZ Identity Access Secrets |
● Athenz (sandbox) ● SPIFFE (graduated) ● SPIRE (graduated) ● Teller (sandbox) |
2. Runtime
이제 클라우드 네이티브 환경의 기반을 구축했으므로 하나의 인프라 계층을 위로 이동하여 런타임 계층으로 확대합니다.
런타임은 컨테이너가 클라우드 네이티브 환경에서 실행되는 데 필요한 모든 것을 포함합니다.
여기에는 컨테이너 런타임이라고 하는 컨테이너를 시작하는 데 사용되는 코드가 포함됩니다.
컨테이너 런타임은 컨테이너에서 영구 스토리지를 사용할 수 있도록 하고 컨테이너 환경의 네트워크 관리 기능을 제공합니다.
이 범주의 제품은 컨테이너를 시작 및 중지하고, 데이터를 저장하고, 서로 통신할 수 있도록 하는 데 사용됩니다.
1) Cloud Native Storage
Storage는 앱의 영구 데이터가 저장되는 곳으로 종종 persistent volume이라고 합니다.
애플리케이션이 안정적으로 작동하려면 스토리지에 쉽게 액세스할 수 있어야 합니다.
수동 프로비저닝과 자동 크기 조정은 호환되지 않으므로 클라우드의 탄력성을 활용하려면 스토리지를 자동으로 프로비저닝해야 합니다.
이 범주의 제품은 다음과 같은 기능을 제공합니다.
| • 컨테이너용 클라우드 네이티브 스토리지 옵션 제공 • 컨테이너와 스토리지 공급자 간의 인터페이스를 표준화 • 백업 및 복원 작업을 통해 데이터 보호를 제공 |
클라우드 네이티브 스토리지는 컨테이너에 파일 및 블록 스토리지를 제공하기 위한 표준 API를 제공하는 컨테이너 스토리지 인터페이스(CSI)에 의해 크게 가능해졌습니다.
이 범주에는 CSI를 활용하여 컨테이너용 on-demand 스토리지를 제공하는 오픈 소스 및 벤더 제공 도구가 많이 있습니다.
Minio는 객체 스토리지를 위한 S3 호환 API를 제공하는 인기 있는 프로젝트입니다.
Velero는 Kubernetes 클러스터 자체와 애플리케이션에서 사용하는 영구 데이터의 백업 및 복원 프로세스를 단순화하는 데 도움이 됩니다.
| 범주 | CNCF Projects |
| Persistent volume CSI Storage API Backup and restore |
● Carina (sandbox) ● CubeFS (incubating) ● Curve (sandbox) ● K8up (sandbox) ● Longhorn (incubating) ● OpenEBS (sandbox) ● ORAS (sandbox) ● Piraeus Datastore (sandbox) ● Rook (graduated) ● Vineyard (sandbox) |
2) Container Runtime
컨테이너 런타임은 컨테이너화된 애플리케이션을 실행하는 소프트웨어입니다.
런타임이 없으면 컨테이너화된 앱의 모양을 지정하는 저장 파일인 컨테이너 이미지만 갖게 됩니다.
런타임은 컨테이너 내에서 앱을 시작하고 필요한 리소스를 제공합니다.
이 범주의 제품은 다음과 같은 기능을 제공합니다.
| • 컨테이너 이미지는 표준화되고 안전하며 격리된 방식으로 실행 • 모든 환경에서 표준화된 방식으로 앱을 시작하고 보안 경계를 설정 • 앱 간에 영향을 미치거나 받지 않도록 격리 • application에 CPU, 스토리지 및 메모리와 같은 리소스 제한 설정 |
| 범주 | CNCF Projects |
| Container MicroVM |
● containerd (graduated) ● CRI-O (incubating) ● Inclavare Containers (sandbox) ● Lima (sandbox) ● rkt (archived) ● WasmEdge Runtime (sandbox) |
3) Cloud Native Network
컨테이너는 클라우드 네이티브 네트워크를 통해 서로 통신하고 인프라 계층과 통신합니다.
분산 응용 프로그램에는 다양한 목적으로 네트워크를 사용하는 여러 구성 요소가 있습니다.
이 범주의 도구는 앱이 통신할 수 있도록 특별히 기존 네트워크 위에 가상 네트워크를 만듭니다. 이를 overlay network라고 합니다.
클라우드 네이티브 네트워킹은 데이터 흐름을 제어, 검사 및 수정하기 위해 소프트웨어를 사용하기 때문에 컨테이너 간의 연결을 관리, 보호 및 격리하는 것이 훨씬 쉽습니다.
경우에 따라 방화벽 및 액세스 규칙과 같은 컨테이너 네트워크 및 네트워크 정책을 확장하여 앱이 컨테이너 네트워크 외부에서 실행되는 가상 머신 또는 서비스에 연결할 수 있도록 할 수 있습니다.
클라우드 네이티브 네트워킹의 프로그래밍 가능하고 종종 선언적인 특성이 이를 가능하게 합니다.
이 범주의 프로젝트 및 제품은 CNCF 프로젝트인 CNI(컨테이너 네트워크 인터페이스)를 사용하여 컨테이너화된 애플리케이션에 네트워킹 기능을 제공합니다.
Flannel과 같은 일부 도구는 다소 미니멀하여 컨테이너에 기본 연결을 제공합니다.
NSX-T와 같은 기타 제품은 모든 Kubernetes 네임스페이스에 대해 격리된 가상 네트워크를 생성하는 전체 소프트웨어 정의 네트워킹 계층을 제공합니다.
이 공간의 다양성과 혁신은 주로 CNI(위에서 언급한 스토리지 및 컨테이너 스토리지 인터페이스와 유사)에 의해 가능해졌습니다.
CNI는 네트워크 계층이 포드에 기능을 제공하는 방식을 표준화합니다.
Kubernetes 환경에 적합한 컨테이너 네트워크를 선택하는 것이 중요하며 선택할 수 있는 도구가 많이 있습니다.
Weave Net, Antrea, Calico 및 Flannel은 모두 효과적인 오픈 소스 네트워킹 계층을 제공합니다.
| 범주 | CNCF Projects |
| SDN Network Overlay CNI |
● Antrea (sandbox) ● Cilium (incubating) ● CNI-Genie (sandbox) ● Container Network Interface (CNI) (incubating) ● FabEdge (sandbox) ● Kube-OVN (sandbox) ● Network Service Mesh (sandbox) ● Submariner (sandbox) |
3. Orchestration & Management
프로비저닝 및 런타임 레이어를 모두 다루었으므로 이제 오케스트레이션 및 관리에 대해 자세히 알아볼 수 있습니다.
여기에서 클라우드 네이티브 애플리케이션 실행 및 연결을 처리하는 도구를 찾을 수 있습니다.
이 섹션에서는 클라우드 네이티브 개발의 핵심 인에이블러 중 하나인 쿠버네티스 자체부터 앱 간 및 외부 통신을 담당하는 인프라 계층에 이르기까지 모든 것을 다룹니다.
1) Scheduling & Orchestration
오케스트레이션 및 스케줄링은 클러스터 전체에서 컨테이너를 실행하고 관리하는 것을 의미합니다.
클러스터는 네트워크를 통해 연결된 물리적 또는 가상 머신 그룹입니다.
클라우드 네이티브 아키텍처에서 애플리케이션은 각각 컨테이너에 배치되는 마이크로 서비스로 나뉩니다.
이러한 각 서비스에는 문제가 발생하면 리소스, 모니터링 및 수정이 필요합니다.
단일 서비스에 대해 이러한 모든 작업을 수동으로 수행하는 것이 가능할 수 있지만 각각 자체 컨테이너가 있는 여러 서비스를 처리할 때는 자동화된 프로세스가 필요합니다.
Kubernetes는 가장 일반적으로 사용되고 적극적으로 유지 관리되는 오케스트레이터입니다.
| 범주 | CNCF Projects |
| Cluster Scheduler Orchestration |
● Armada (sandbox) ● Clusternet (sandbox) ● Clusterpedia (sandbox) ● Crossplane (incubating) ● Fluid (sandbox) ● Karmada (sandbox) ● kube-rs (sandbox) ● Kubernetes (graduated) ● Kured (sandbox) ● Open Cluster Management (sandbox) ● Volcano (incubating) ● wasmCloud (sandbox) |
2) Coordination & Service Discovery
클라우드 네이티브 아키텍처는 동적이고 유동적이므로 끊임없이 변화합니다.
컨테이너가 한 노드에서 충돌하면 이를 대체하기 위해 새 컨테이너가 다른 노드에서 가동됩니다. 또는 앱이 확장되면 복제본이 네트워크 전체에 분산됩니다.
특정 서비스가 있는 곳은 없습니다. 모든 것의 위치는 끊임없이 변화합니다.
이 범주의 도구는 필요할 때 서비스가 서로를 찾을 수 있도록 네트워크 내의 서비스를 추적합니다.
서비스 검색 도구는 개별 서비스를 찾고 잠재적으로 식별할 수 있는 공통 위치를 제공하여 이 문제를 해결합니다.
이 범주에는 기본적으로 두 가지 유형의 도구가 있습니다.
| • Service discovery engine: 모든 서비스에 대한 정보와 이를 찾는 방법을 저장하는 데이터베이스와 같은 도구 • Name resolution tool: 서비스 위치 요청을 수신하고 네트워크 주소 정보를 반환하는 도구 (예: CoreDNS) |
분산 시스템이 점점 더 보편화됨에 따라 기존 DNS 프로세스와 로드 밸런서는 변화하는 엔드포인트 정보를 따라잡지 못하는 경우가 많았습니다.
이러한 단점을 보완하기 위해 서비스 검색 도구는 개별 응용 프로그램 인스턴스를 신속하게 등록 및 등록 취소합니다.
CoreDNS 및 etcd와 같은 일부 옵션은 CNCF 프로젝트이며 Kubernetes에 내장되어 있습니다.
| 범주 | CNCF Projects |
| DNS Service Discovery |
● CoreDNS (graduated) ● etcd (graduated) ● k8gb (sandbox) |
3) Remote Procedure Call
RPC(원격 프로시저 호출)는 응용 프로그램이 서로 통신할 수 있도록 하는 특정 기술입니다.
앱 커뮤니케이션을 구성하는 한 가지 방법입니다.
최신 앱은 협업을 위해 통신해야 하는 수많은 개별 서비스로 구성됩니다.
RPC는 응용 프로그램 간의 통신을 처리하기 위한 옵션 중 하나입니다.
RPC는 서비스 간의 통신을 처리하는 긴밀하게 결합되고 독단적인 방식을 제공합니다.
대역폭 효율적인 통신이 가능하고 많은 프로그래밍 언어로 RPC 인터페이스 구현이 가능합니다.
RPC는 코딩 연결을 더 쉽게 만들고 네트워크 계층을 매우 효율적으로 사용하고 서비스 간에 잘 구성된 통신을 허용합니다.
gRPC는 특히 널리 사용되는 RPC 구현이며 CNCF에서 채택했습니다.
| 범주 | CNCF Projects |
| gRPC | ● gRPC (incubating) |
4) Service Proxy
서비스 프록시는 지정된 서비스에서 들어오고 나가는 트래픽을 가로채고 일부 논리를 적용한 다음 해당 트래픽을 다른 서비스로 전달하는 도구입니다.
기본적으로 네트워크 트래픽에 대한 정보를 수집하고 규칙을 적용할 수 있는 "중개자" 역할을 합니다.
이는 트래픽을 개별 애플리케이션으로 전달하는 로드 밸런서 역할을 하는 것처럼 간단할 수도 있고, 모든 네트워크 연결을 처리하는 컨테이너화된 개별 애플리케이션과 나란히 실행되는 프록시의 상호 연결된 메시처럼 복잡할 수도 있습니다.
서비스 프록시는 데이터 수집 및 네트워크 트래픽 관리 기능을 "외부화"합니다.
서비스 프록시 위치는 앱 내에 있지 않고 플랫폼 계층에 포함됩니다.
이는 개발자가 애플리케이션 코드를 작성하는 데 전적으로 집중할 수 있도록 하여 트래픽을 처리하는 보편적인 작업을 플랫폼 팀이 관리할 수 있도록 해줍니다.
하나의 공통 위치에서 Routing 또는 TLS termination와 같이 필요한 서비스 기능의 배포 및 관리를 중앙 집중화하면 서비스 간의 통신이 보다 안정적이고 안전하며 성능이 향상될 수 있습니다.
프록시는 중요한 데이터를 수집하고 서비스 간에 트래픽을 고르게 분산하거나 서비스 중단 시 재 라우팅하는 등의 라우팅 관리 기능을 하고, 연결을 암호화하고 콘텐츠를 캐시합니다.
| 범주 | CNCF Projects |
| Service Proxy Ingress |
● BFE (sandbox) ● Contour (incubating) ● Envoy (graduated) ● OpenELB (sandbox) |
5) API Gateway
API 게이트웨이를 사용하면 조직에서 애플리케이션 간의 요청 수를 승인하거나 제한하는 것과 같은 주요 기능을 중앙에서 관리되는 위치로 이동할 수 있습니다.
또한 API 소비자에 대한 공통 인터페이스 기능을 합니다.
API 게이트웨이를 사용하면 개발자가 더 적은 사용자 정의 코드를 작성하고 유지할 수 있습니다.
API 게이트웨이는 사용자와 애플리케이션 사이에 있습니다.
사용자의 메시지(요청)를 받아 적절한 서비스로 전달하는 중개자 역할을 합니다.
요청을 전달하기 전에 사용자가 하려는 작업을 수행할 수 있는지 여부를 평가하고 요청한 사람과 요청한 횟수에 대한 세부 정보를 기록합니다.
API 게이트웨이는 일련의 다운스트림 애플리케이션에 대한 공통 진입점 역할을 하는 동시에 팀이 비즈니스 로직을 추가하여 승인, 속도 제한 및 지불 거절을 처리할 수 있는 장소를 제공합니다.
이를 통해 애플리케이션 개발자는 고객의 다운스트림 API에 대한 변경 사항을 추상화하고 신규 고객 온보딩과 같은 작업을 게이트웨이로 오프로드할 수 있습니다.
| 범주 | CNCF Projects |
| API Gateway | ● Emissary-Ingress (incubating) |
6) Service Mesh
서비스 메시는 서비스 간의 트래픽을 관리합니다.
이를 통해 플랫폼 팀은 코드를 변경할 필요 없이 클러스터 내에서 실행되는 모든 서비스에 걸쳐 안정성, 관찰 가능성 및 보안 기능을 균일하게 추가할 수 있습니다.
Kubernetes와 함께 서비스 메시는 클라우드 네이티브 스택의 가장 중요한 인프라 구성 요소 중 일부가 되었습니다.
서비스 메시는 앱 코드를 건드리지 않고 플랫폼 계층의 모든 서비스에 걸쳐 안정성, 관찰 가능성 및 보안 기능을 균일하게 추가합니다.
모든 프로그래밍 언어와 호환되므로 개발 팀이 비즈니스 로직 작성에 집중할 수 있습니다.
명령 및 제어 신호를 서비스 프록시 네트워크에 제공하여 서비스 간 통신을 관리하는 인프라 계층입니다.
| 범주 | CNCF Projects |
| Service mesh Sidecar Data plane Control plane |
● Aeraki Mesh (sandbox) ● Istio (incubating) ● Kuma (sandbox) ● Linkerd (graduated) ● Merbridge (sandbox) ● Meshery (sandbox) ● Open Service Mesh (sandbox) ● Service Mesh Interface (SMI) (sandbox) ● Service Mesh Performance (sandbox) |
4. App Definition and Development
CNCF 환경의 마지막 계층인 애플리케이션 정의 및 개발 계층에 대해 설명합니다.
database, streaming 및 messaging, 애플리케이션 정의, CICD(continuous integration and continuous delivery)를 다룹니다.
지금까지 다루었던 내용은 안정적이고 안전한 환경을 구축하고 필요한 모든 종속성을 제공하는 것과 관련이 있습니다.
이제 CNCF 클라우드 네이티브 환경의 최상위 계층에 도달했습니다.
응용 프로그램 정의 및 개발 계층은 엔지니어가 응용 프로그램을 구축할 수 있도록 하는 도구에 중점을 둡니다.
1) Database
데이터베이스는 다른 앱이 데이터를 효율적으로 저장하고 검색할 수 있는 애플리케이션입니다. 데이터베이스를 사용하면 데이터를 저장하고 권한이 있는 사용자만 데이터에 액세스할 수 있으며 사용자가 특수 요청을 통해 데이터를 검색할 수 있습니다.
Kubernetes의 부상과 stateful application 지원 기능으로 차세대 데이터베이스가 컨테이너화를 활용하는 것을 볼 수 있습니다.
클라우드 네이티브 데이터베이스는 Kubernetes의 확장성 및 가용성 이점을 데이터베이스에 제공하는 것을 목표로 합니다.
클라우드 네이티브 데이터베이스로 YugabyteDB 및 Couchbase 등을 들 수 있습니다만,
MySQL과 Postgres와 같은 보다 전통적인 데이터베이스도 Kubernetes 클러스터 환경에서 성공적이고도 효율적으로 실행되는 것을 볼 수 있습니다.
| 범주 | CNCF Projects |
| SQL DB Persistence |
● SchemaHero (sandbox) ● TiKV (graduated) ● Vitess (graduated) |
2) Streaming & Messaging
스트리밍 및 메시징 도구는 시스템 간에 메시지를 전송하여 서비스 간 통신을 가능하게 합니다.
스트리밍 또는 메시징 플랫폼은 시스템 내에서 발생하는 모든 이벤트를 게시하고 읽을 수 있는 중앙 위치를 제공하므로 응용 프로그램이 서로에 대해 전혀 알지 못하는 상태에서 함께 작동할 수 있습니다.
NATS 및 Cloudevents 프로젝트는 CNCF 프로젝트를 인큐베이팅하고 있습니다.
NATS는 성숙한 메시징 시스템을 제공하고 Cloudevents는 시스템 간의 메시지 형식을 표준화하려는 노력입니다.
Strimzi, Pravega 및 Tremor는 각각 스트리밍 및 메시징과 관련된 고유한 사용 사례에 맞게 조정되는 샌드박스 프로젝트입니다.
| 범주 | CNCF Projects |
| Choreography Streaming MQ Message bus |
● CloudEvents (incubating) ● NATS (incubating) ● Pravega (sandbox) ● Strimzi (sandbox) ● Tremor (sandbox) |
3) Application Definition & Image Build
애플리케이션 정의 및 이미지 빌드는 두 개의 주요 하위 그룹으로 나눌 수 있는 광범위한 범주입니다.
첫째, 컨테이너 및/또는 Kubernetes에 애플리케이션 코드를 빌드하는 데 도움이 되는 개발자 중심 도구입니다.
둘째, 표준화된 방식으로 앱을 배포하는 운영 중심 도구입니다.
개발 환경의 속도를 높이거나 단순화하거나 third-party앱을 배포하는 표준화된 방법을 제공하거나 새로운 Kubernetes 확장 작성 프로세스를 단순화하려는 경우, 이 범주는 Kubernetes 개발자 및 운영자 경험을 최적화하는 여러 프로젝트 및 제품에 대한 포괄적인 역할을 합니다.
Kubernetes 및 보다 일반적으로 컨테이너화된 환경은 매우 유연하고 강력합니다.
이러한 유연성은 주로 여러 구성 옵션의 형태와 다양한 사용 사례에 대한 여러 요구 사항의 형태로 복잡성도 수반합니다.
| • 개발자는 코드를 컨테이너화할 때 재현 가능한 이미지를 생성할 수 있는 기능이 필요합니다. • 운영자는 컨테이너 환경에 앱을 배포하는 표준화된 방법이 필요하며, • 플랫폼 팀은 사내 및 타사 애플리케이션 모두에 대해 이미지 생성 및 애플리케이션 배포를 단순화하는 도구를 제공해야 합니다. |
이 범주의 도구는 이러한 개발자 또는 운영자 문제 중 일부를 해결하는 것을 목표로 합니다.
개발자 측에는 Kubernetes를 확장하여 애플리케이션을 빌드, 배포 및 연결하는 프로세스를 간소화하는 도구가 있습니다.
Helm을 사용하면 Kubernetes 사용자가 많은 인기 있는 타사 앱을 배포하고 사용자 지정할 수 있으며 Artifact Hub(CNCF 샌드박스 프로젝트)와 같은 다른 프로젝트에서 채택되었습니다.
Bitnami와 같은 회사도 엄선된 앱 카탈로그를 제공합니다.
Operator Framework는 Operator 구축 및 배포 프로세스를 단순화하는 것을 목표로 하는 인큐베이팅 프로젝트입니다.
| 범주 | CNCF Projects |
| Package Management Charts Operators |
● Artifact Hub (sandbox) ● Backstage (incubating) ● Buildpacks (incubating) ● Carvel (sandbox) ● Devfile (sandbox) ● DevSpace (sandbox) ● Helm (graduated) ● ko (sandbox) ● Konveyor (sandbox) ● Krator (sandbox) ● KubeVela (incubating) ● KubeVirt (incubating) ● KUDO (sandbox) ● Nocalhost (sandbox) ● Operator Framework (incubating) ● Porter (sandbox) ● sealer (sandbox) ● Serverless Workflow (sandbox) ● Telepresence (sandbox) |
4) Continuous Integration & Delivery
CI(Continuous integration) 및 CD(continuous delivery) 도구를 사용하면 내장된 품질 보증을 통해 빠르고 효율적인 개발이 가능합니다.
CI는 코드를 즉시 빌드하고 테스트하여 코드 변경을 자동화하여 배포 가능한 아티팩트를 생성하도록 합니다.
CD는 한 단계 더 나아가 배포 단계를 통해 artifact를 push합니다.
성숙한 CI/CD 시스템은 소스 코드의 변경 사항을 감시하고 코드를 자동으로 빌드 및 테스트한 다음 프로세스를 계속할지 또는 실패할지 결정하기 위해 다양한 테스트 또는 유효성 검사를 통과해야 하는 개발에서 프로덕션으로 이동하기 시작합니다.
이 범주의 도구는 이러한 접근 방식을 가능하게 합니다.
시장에서 가장 많은 CI 도구인 Jenkins와 같은 일부 기존 도구는 Kubernetes 생태계에 더 잘 맞도록 조정되어 있습니다.
Flux 및 Argo는 OpenGitOps 프로젝트가 벤더 중립적 표준으로 정의하기 위해 노력하고 있는 GitOps라는 새로운 지속적 제공 방법을 개척했습니다.
| 범주 | CNCF Projects |
| CI/CD Continuous integration Continuous delivery Continuous deployment Blue/green Canary deploy |
● Argo (graduated) ● Brigade (archived) ● Flux (graduated) ● Keptn (incubating) ● OpenFeature (sandbox) ● OpenGitOps (sandbox) ● OpenKruise (incubating) ● werf (sandbox) |
5. Observability and Analysis
이제 CNCF 환경의 계층을 통해 작업했으므로 관측 가능성 및 분석으로 시작하는 열에 초점을 맞출 것입니다.
Observability은 외부 출력에서 시스템을 이해할 수 있는 정도를 설명하는 시스템 특성입니다.
CPU 시간, 메모리, 디스크 공간, 대기 시간, 오류 등으로 측정되는 컴퓨터 시스템은 어느 정도 관찰 가능할 수 있습니다.
Analysis는 관찰 가능한 데이터를 보고 이해하는 활동입니다.
서비스 중단이 발생하지 않도록 하려면 애플리케이션의 모든 측면을 관찰하고 분석하여 모든 이상 현상을 즉시 감지하고 수정해야 합니다.
이 범주의 도구는 로깅, 모니터링, 추적 및 카오스 엔지니어링으로 분류됩니다.
1) Monitoring
모니터링은 동작에 대한 이해도를 높이기 위해 로그와 메트릭을 수집, 집계 및 분석하기 위해 앱을 계측하는 것을 의미합니다.
로그는 특정 이벤트를 설명하지만 메트릭은 지정된 시점의 시스템 측정치입니다.
두 가지가 서로 다르지만 둘 다 시스템 상태를 전체적으로 파악하는 데 필요합니다.
모니터링에는 개별 노드의 디스크 공간, CPU 사용량 및 메모리 소비를 관찰하는 것부터 상세한 가상 트랜잭션을 수행하여 시스템 또는 애플리케이션이 적시에 올바르게 응답하는지 확인하는 것까지 모든 것이 포함됩니다.
시스템 및 응용 프로그램을 모니터링하는 방법에는 여러 가지가 있습니다.
| 범주 | CNCF Projects |
| Monitoring Time series Alerting Metrics |
● Cortex (incubating) ● Fonio (sandbox) ● Kuberhealthy (sandbox) ● OpenMetrics (incubating) ● Pixie (sandbox) ● Prometheus (graduated) ● Skooner (sandbox) ● Thanos (incubating) ● Trickster (sandbox) |
2) Logging
애플리케이션은 주어진 시간에 수행 중인 작업을 설명하는 꾸준한 로그 메시지 스트림을 내보냅니다.
이러한 로그 메시지는 실패하거나 성공한 작업, 감사 정보 또는 상태 이벤트와 같이 시스템에서 발생하는 다양한 이벤트를 캡처합니다.
로깅 도구는 이러한 메시지를 수집, 저장 및 분석하여 오류 보고서 및 관련 데이터를 추적합니다.
메트릭 및 추적과 함께 로깅은 관찰 가능성의 기둥 중 하나입니다.
클라우드 네이티브 환경에서 Fluentd와 같은 로그 수집 도구는 애플리케이션 컨테이너와 함께 실행되며 애플리케이션에서 직접 메시지를 수집합니다.
그런 다음 메시지는 집계 및 분석을 위해 중앙 로그 저장소로 전달됩니다.
| 범주 | CNCF Projects |
| Logging | ● Fluentd (graduated) |
3) Tracing
Logging의 전문적인 사용인 Tracing을 통해 분산 시스템을 통해 이동할 때 요청 경로를 추적할 수 있습니다.
Tracing은 응용 프로그램에서 보낸 메시지에 고유 식별자를 추가하여 이 문제를 해결합니다.
이 고유 식별자를 사용하면 개별 트랜잭션이 시스템을 통해 이동할 때 추적할 수 있습니다.
이 정보를 사용하여 애플리케이션의 상태를 확인하고 문제가 있는 마이크로 서비스 또는 활동을 디버그할 수 있습니다.
Tracing 데이터를 내보내려면 응용 프로그램 코드를 수정해야 하며 모든 범위는 응용 프로그램의 데이터 경로에서 인프라 구성 요소(예: 서비스 메시 및 해당 프록시)에 의해 전파되어야 합니다.
Jaeger 및 Open Tracing은 이 분야의 CNCF 프로젝트입니다.
| 범주 | CNCF Projects |
| Span Tracing |
● Jaeger (graduated) ● OpenTelemetry (incubating) ● OpenTracing (archived) |
4) Chaos Engineering
카오스 엔지니어링은 탄력성을 테스트하고 응용 프로그램 및 엔지니어링 팀이 예기치 않은 이벤트를 견딜 수 있도록 시스템에 의도적으로 결함을 도입하는 관행을 말합니다.
카오스 엔지니어링 도구는 애플리케이션의 특정 인스턴스에 대해 결함을 도입하고 특정 실험을 실행하는 제어된 방법을 제공합니다.
| 범주 | CNCF Projects |
| Chaos Engineering | ● Chaos Mesh (incubating) ● Chaosblade (sandbox) ● Litmus (incubating) |
6. Platform
플랫폼은 오케스트레이션 도구, 컨테이너 런타임, 서비스 검색, 네트워킹, API 게이트웨이 등의
서로 다른 계층의 서로 다른 도구를 함께 묶어 제공합니다.
소규모 엔지니어링 팀이 있는 조직의 경우 플랫폼이 클라우드 네이티브 접근 방식을 채택하는 유일한 방법입니다.
모든 플랫폼이 클라우드 네이티브 스택의 핵심인 Kubernetes를 중심으로 구성되어 가고 있습니다.
1) Certified Kubernetes - Distribution
배포판은 공급업체가 core Kubernetes를 가져와 재 배포를 위해 패키징하는 것입니다.
일반적으로 여기에는 Kubernetes 소프트웨어를 찾아 검증하고 클러스터 설치 및 업그레이드를 처리하는 메커니즘을 제공하는 것이 수반됩니다.
많은 Kubernetes 배포에는 공급업체 별 독점적이거나 오픈 소스 애플리케이션이 포함됩니다.
| 범주 | CNCF Projects |
| ● k3s (sandbox) |
2) Certified Kubernetes - Hosted
호스팅된 Kubernetes는 AWS, Digital Ocean, Azure 및 Google과 같은 인프라 공급자가 제공하는 서비스로 고객이 필요에 따라 Kubernetes 클러스터를 가동할 수 있습니다.
클라우드 공급자는 일반적으로 컨트롤 플레인이라고 하는 Kubernetes 클러스터의 일부를 관리할 책임이 있습니다.
배포판과 비슷하지만 인프라에서 클라우드 공급자가 관리합니다.
공급자가 모든 관리 세부 사항을 처리하므로 호스팅된 Kubernetes는 클라우드 네이티브를 시작하는 가장 쉬운 방법입니다.
모든 사용자는 앱을 개발하고 호스팅된 Kubernetes 서비스에 배포하기만 하면 됩니다.
오퍼링은 클라우드 공급자에 바인딩되며 Kubernetes 사용자는 컨트롤 플레인에 액세스할 수 없습니다.
3) Certified Kubernetes - Installer
Kubernetes 설치 프로그램은 컴퓨터에 Kubernetes를 설치하는 데 도움이 됩니다.
Kubernetes 설치 및 구성 프로세스를 자동화하고 업그레이드를 지원할 수도 있습니다.
Kubernetes 설치 프로그램은 종종 Kubernetes 배포 또는 호스팅된 Kubernetes 제품과 결합되거나 사용됩니다.
Kubernetes 설치 프로그램은 Kubernetes 설치 프로세스를 용이하게 합니다.
배포판과 마찬가지로 소스 코드 및 버전에 대해 검증된 소스를 제공합니다.
또한 공급업체 별 독단적인 Kubernetes 환경 구성과 함께 제공되는 경우가 많습니다.
KIND (Docker의 Kubernetes) 와 같은 Kubernetes 설치 프로그램을 사용하면 단일 명령으로 Kubernetes 클러스터를 가져올 수 있습니다.
4) PaaS/Container Service
PaaS(Platform-as-a-Service)는 사용자가 기본 컴퓨팅 리소스의 세부 정보에 신경 쓰지 않고 애플리케이션을 실행할 수 있는 환경입니다.
이 범주의 PaaS 및 컨테이너 서비스는 개발자용 PaaS를 호스팅하거나 개발자가 사용할 수 있는 서비스를 호스팅하는 메커니즘입니다.
※ 참고 URL
'PaaS > Kubernetes' 카테고리의 다른 글
| Kubernetes Off-Line Install Guide (0) | 2020.08.19 |
|---|
