[ Summary] Cloud Native Landscape Project Trail Map ( CNCF )

Intro

 2018년에 Cloud Native 에서 진행한 Landscape 프로젝트입니다. 오픈 소스, 클라우드 네이티브 기술을 활용하기 위해 권장되는 프로세스 안내를 제공하고 있습니다. 각 단계에서 공급업체 지원 오퍼링을 선택하거나 직접 실행할 수 있으며, #3단계 이후의 모든 것은 상황에 따라 선택할 수 있습니다.

 CNCF에서 호스팅한 프로젝트들을 나열 하고 있습니다. ( 첫번째 채택 - 쿠버네티스, 두번째 채택 - Prometheus ... 16번째 채택 - Vitess 등등 )

 

Cloud Native Landscape Trail Map

Index

1. 컨테이너화

2. CI/CD (Continuos Intergration/ Continuous Development)

3. 오케스트레이션

4. 모니터링 / 분석

5. 서비스 디스커버리

6. 네트워킹 / 보안

7. 분산 데이터베이스 / 저장소

8. 스트리밍 / 메세징

9. 컨테이너 레지스트리 / 런타임

10. 배포

---

컨테이너화

- 일반적으로 도커 컨테이너로 수행됩니다. 
- 모든 크기의 애플리케이션 및 종속성(에뮬레이터에서 실행되는 PDP-11 코드도 포함)을 컨테이너화할 수 있습니다.
- 적절한 애플리케이션으로 분할하고 마이크로서버로서 기능을 해야합니다.

---

CI/CD (Continuous Integration/ Continuous Development)

- 소스 코드를 변경하면 새로운 컨테이너가 자동으로 빌드, 테스트되고 스테이징 및 운영 환경에 배포되도록 CICD를 설정합니다.
- 자동 롤아웃, 롤백 및 테스트를 설정합니다.
- ArgoCD는 지속적이고 점진적인 제공 및 MLops와 같은 GitOps 패러다임을 사용하여 작업, 애플리케이션, 워크플로우 및 이벤트를 배포하고 실행하기 위한 쿠버네티스 네이티브 도구 집합입니다.

 

* argoCD

What? ArgoCD는 GitOps 워크플로우를 지원하는 GitOps 도구입니다. ArgoCD는 독립 실행형 도구 또는 CI/CD 워크플로우의 일부로 사용할 수 있습니다. ArgoCD는 Git과 함께 진실의 원천으로, 현재의 쿠버네티스 manifests 또는 helm charts와 함께 동작합니다.

 

Why? 다음과 같은 기능을 제공합니다.

• 선언적 및 버전 제어 애플리케이션 배포.
• GitOps 워크플로를 통한 자동화 및 추적성.
• helm, kustomize 및 jsonnet 애플리케이션 선언 지원.
• Kubernetes 리소스 시각화를 위한 웹 UI.
• 명령줄 인터페이스 응용 프로그램.
• Grafana 메트릭 대시보드.
• helm/ksonnet 선언의 매개변수 재정의(개발 배포 단순화).
• 애플리케이션 이벤트 및 API 호출에 대한 감사 추적.

---

오케스트레이션

- 쿠버네티스는 시장을 선도하는 오케스트레이션 솔루션입니다. 
- Helm Charts를 사용하면 가장 복잡한 쿠버네티스 응용 프로그램도 정의, 설치 및 업그레이드할 수 있습니다.

 

* Kubernetes

What? 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼입니다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해줍니다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있습니다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있습니다.

 

Why? 다음과 같은 강력한 기능이 있습니다.

• 작업 부하에 따라 확장 및 빠른 확장/축소가 가능.
• 애플리케이션이 여러 서비스로 구성되어 있으며 이를 확장 가능.
• 컨테이너 기반 워크로드에 대한 복원력.
• 클라우드로 이동할 워크로드 준비.
• 일관된 배포 관리.

* Helm & Helm Charts

What? 간단히 말해서 Helm은 Kubernetes용 패키지 관리자입니다. Helm은 yum 또는 apt에 해당하는 K8입니다. Helm은 패키지 애플리케이션으로 생각할 수 있는 차트를 배포합니다. 하나의 단위로 배포할 수 있는 버전이 지정되고 사전 구성된 모든 애플리케이션 리소스의 모음입니다. 그런 다음 다른 구성 집합을 사용하여 다른 버전의 차트를 배포할 수 있습니다.

Helm은 세 가지 주요 방식으로 도움을 줍니다.

• 생산성 향상
• 마이크로서비스 배포의 복잡성 감소
• 클라우드 네이티브 애플리케이션의 적응을 가능하게 합니다.

Helm Chart는 Kubernetes 클러스터에 보급할 수 있는 단일 패키지로 결합된 단순히 Kubernetes YAML 매니페스트입니다. 일단 패키지화되면 Helm 차트를 클러스터에 설치하는 것은 단일 helm install 을 실행하는 것만큼 쉽습니다 . 이는 컨테이너화 된 애플리케이션의 배포를 실제로 단순화합니다.

 

Why? 필요한 모든 Kubernetes 개체에 대한 Kubernetes YAML 매니페스트 를 작성하고 유지 관리 하는 것은 시간이 많이 걸리고 지루한 작업일 수 있습니다. 가장 간단한 배포의 경우 중복되고 하드코딩된 값이 포함된 YAML 매니페스트가 3개 이상 필요합니다. Helm은 이 프로세스를 단순화하고 클러스터에 보급할 수 있는 단일 패키지를 만듭니다.

Helm 은 클라이언트/서버 애플리케이션이며 최근까지 클러스터에 배포하기 위해 Tiller(helm 서버)에 의존했습니다. 이것은 클라이언트 시스템에 helm을 설치/초기화할 때 설치됩니다. Tiller는 단순히 클라이언트로부터 요청을 수신하고 패키지를 클러스터에 설치합니다. Helm은 Linux의 DEB 패키지 RPM과 쉽게 비교할 수 있어 개발자가 애플리케이션을 패키징하고 최종 사용자가 설치할 수 있도록 배송하는 편리한 방법을 제공합니다.

Helm을 설치 및 구성하고 나면 MongoDB , MySQL 등과 같은 소프트웨어 공급업체의 프로덕션 준비 애플리케이션을 매우 간단한 helm 설치 명령 하나로 Kubernetes 클러스터에 설치할 수 있습니다. 또한 클러스터에 설치된 애플리케이션을 제거하는 것은 설치하는 것만큼 쉽습니다.

---

모니터링 / 분석

- 모니터링, 로깅 및 추적을 위한 솔루션을 선택합니다.
- CNCF 프로젝트는 모니터링용으로 Prometheus, 로깅용으로 Fluentd 및 추적용으로 Jaeger를 고려합니다.
- 추적을 위해 Jeager와 같은 개방형 추적 호환 구현을 찾아보십시오.

 

* Prometheus

What? Prometheus 는 원래 SoundCloud 에서 구축된 오픈 소스 시스템 모니터링 및 경고 툴킷 입니다. 2012년 시작된 이래 많은 회사와 조직이 Prometheus를 채택했으며 이 프로젝트에는 매우 활발한 개발자 및 사용자 커뮤니티 가 있습니다. 이제 독립 실행형 오픈 소스 프로젝트이며 어떤 회사와도 독립적으로 유지 관리됩니다. 이를 강조하고 프로젝트의 거버넌스 구조를 명확히 하기 위해 Prometheus는 Kubernetes 에 이어 두 번째 호스팅 프로젝트로 2016년 Cloud Native Computing Foundation 에 합류했습니다 .

Prometheus는 메트릭을 시계열 데이터로 수집하고 저장합니다. 즉, 메트릭 정보는 레이블이라는 선택적 키-값 쌍과 함께 기록된 타임스탬프와 함께 저장됩니다.

 

Prometheus의 주요 기능은 다음과 같습니다.

• 메트릭 이름 및 키/값 쌍으로 식별되는 시계열 데이터가 있는 다차원 데이터 모델.
• PromQL : 이 차원을 활용 하는 유연한 쿼리 언어.
• 분산 스토리지에 의존하지 않음. 단일 서버 노드는 자율적입니다.
• 시계열 수집은 HTTP를 통한 풀 모델을 통해 발생.
• 푸시 시계열(pushing time series)은 중개 게이트웨이를 통해 지원.
• 대상은 서비스 검색 또는 정적 구성을 통해 검색.
• 여러 모드의 그래프 및 대시보드 지원.

Prometheus Architecture

Why? Prometheus는 순수하게 숫자로만 이루어진 시계열을 기록하는 데 효과적입니다. 시스템 중심의 모니터링뿐만 아니라 매우 동적인 서비스 지향 아키텍처의 모니터링에도 적합합니다. 마이크로 서비스의 세계에서, 다차원 데이터 수집과 쿼리에 대한 지원은 특별한 강점입니다.

Prometheus는 가동 중단 시 문제를 신속하게 진단할 수 있는 시스템으로, 신뢰성을 위해 설계되었습니다. 각 Prometheus 서버는 네트워크 스토리지나 다른 원격 서비스에 의존하지 않고 독립 실행형입니다. 인프라의 다른 부분이 고장 났을 때 사용할 수 있으며 광범위한 인프라를 설정할 필요가 없습니다.

 

하지만 다음을 고려해보아야 합니다.

프로메테우스는 신뢰성을 중요시합니다. 오류 조건에서도 시스템에 대해 사용 가능한 통계를 항상 볼 수 있습니다. 요청당 청구 등 100% 정확도가 필요한 경우 수집된 데이터가 충분히 상세하고 완전하지 않을 가능성이 높기 때문에 Prometheus는 좋은 선택이 아닙니다. 이러한 경우에는 다른 시스템을 사용하여 청구 데이터를 수집하고 분석하고, 나머지 모니터링은 Prometheus를 사용하는 것이 가장 좋습니다.

 

 

* fluentd

What? Fluentd는 데이터 수집과 소비를 통합하여 데이터를 더 잘 사용하고 이해할 수 있도록 하는 오픈 소스 데이터 수집기입니다.

Before and After with fluentd

Why?

- 통합 로깅 계층

Fluentd는 백엔드 시스템 사이에 통합 로깅 계층 을 제공하여 데이터 소스를 백엔드 시스템과 분리합니다.

이 계층을 통해 개발자와 데이터 분석가는 생성되는 다양한 유형의 로그를 활용할 수 있습니다. 그 못지 않게 중요한 것은 "불량 데이터"가 느려지고 조직에 잘못된 정보를 제공할 위험이 완화된다는 것입니다.

통합 로깅 계층을 통해 귀하와 귀하의 조직은 데이터를 더 잘 활용하고 소프트웨어에서 더 빠르게 반복할 수 있습니다.

- 간단하고 쉬우면서도 유연함.

Fluentd의 500개 이상의 플러그인은 수십 개의 데이터 소스 및 데이터 출력 과 호환됩니다 . 플러그인도 작성 및 배포하기 쉽습니다.

- 오픈 소스

Fluentd는 Apache 2.0 라이선스가 있는 완전 오픈 소스 소프트웨어입니다. 즉, 라이선스 제한이 없습니다.

- 입증된 안정성 및 성능

5,000개 이상의 데이터 중심 기업 이 Fluentd를 사용하여 로그 데이터를 더 잘 사용하고 이해함으로써 제품과 서비스를 차별화하고 있습니다. 실제로 Datadog 의 설문조사 에 따르면 Fluentd는 Docker 컨테이너 환경에서 실행되는 7번째 상위 기술입니다.

일부 Fluentd 사용자는 수천 대의 컴퓨터에서 실시간으로 데이터를 수집합니다. 작은 메모리 공간( 30~40MB ) 덕분 에 대규모 메모리를 많이 절약할 수 있습니다.

 

* Jaeger

What? Jaeger는 Uber Technologies 에서 오픈 소스로 출시한 분산 추적 시스템 입니다. 다음을 포함하여 마이크로 서비스 기반 분산 시스템을 모니터링하고 문제를 해결하는 데 사용됩니다.

• 분산 컨텍스트 전파
• 분산 트랜잭션 모니터링
• 근본 원인 분석
• 서비스 종속성 분석
• 성능/지연 최적화

Jaeger Architecture

 

* Open-Tracing

What? Opentracing은 분산 추적을 위해 벤더 중립적인 계측을 가능하게 하는 initiative(주도)였습니다. OpenTracing 프로젝트의 작성자는 특정 공급업체에 라이브러리나 패키지를 바인딩하지 않는 계측에 대한 표준 메커니즘을 제공하기를 원했습니다.

저자는 응용 프로그램이 사용할 수 있는 모든 미들웨어와 프레임워크에 대한 표준 도구를 만드는 것을 목표로 했습니다.

 

* Jaeger & Open-Tracing

Diff? 두 오픈소스 프로젝트의 주요 차이점은 범위입니다. Jaeger가 종단 간 분산 추적 도구인 반면 OpenTracing은 원격 측정 데이터 생성 및 관리를 위한 코드 계측 표준화를 목표로 하는 프로젝트였습니다.

따라서 분산 추적을 활성화하려는 경우 Jaeger를 구현하는 것이 더 나은 옵션입니다. SigNoz 와 같은 풀 스택 오픈 소스 도구를 사용할 수도 있습니다. Jaeger와 OpenTracing의 주요 차이점은 다음과 같이 요약할 수 있습니다.

• Jaeger는 종단 간 분산 추적 도구이고 OpenTracing은 계측 라이브러리입니다.
• Jaeger에는 웹 UI 구성 요소가 있지만 OpenTracing과 같은 계측 라이브러리를 사용하는 동안 분석 백엔드 도구를 선택해야 합니다.
• Jaeger는 활성 오픈 소스 프로젝트 이지만 OpenTelemetry를 형성하기 위해 OpenCensus 와 프로젝트가 병합됨에 따라 OpenTracing은 더 이상 적극적으로 유지 관리되지 않습니다.
• OpenTracing은 데이터 저장 옵션을 제공하지 않는 반면 Jaeger는 두 가지 인기 있는 오픈 소스 프로젝트인 Cassandra 및 ElasticSearch를 지원합니다.

Ex? Jaeger와 OpenTracing은 모두 다른 수준에서 마이크로서비스에 대한 분산 추적 문제를 해결하는 것을 목표로 합니다. 이 두 프로젝트의 주요 사용 사례를 살펴보겠습니다.

분산 추적 도구인 Jaeger의 주요 사용 사례는 다음과 같습니다.

• 분산 트랜잭션 모니터링
• 성능 및 지연 시간 최적화
• 근본 원인 분석
• 서비스 종속성 분석
• 분산 컨텍스트 전파

벤더 중립적 API 및 계측 라이브러리로서의 OpenTracing의 주요 사용 사례는 다음과 같습니다.

• 개발자가 특정 추적 공급업체에 바인딩하지 않고 자신의 코드를 계측할 수 있습니다.
• 스팬 관리 API의 표준화에 사용
• 활성 스팬 관리에 사용
• 프로세스 간 전파 API 제공

Etc? 이미 언급했듯이 OpenTracing은 OpenCensus와 병합되어 OpenTelemetry라는 단일 프로젝트로 통합되었습니다. OpenTelemetry는 원격 측정 데이터(로그, 메트릭 및 추적)의 생성, 수집 및 관리를 표준화하는 것을 목표로 하는 API, SDK, 라이브러리 및 통합 세트입니다. OpenTelemetry로 수집하는 데이터는 공급업체에 구애받지 않으며 다양한 형식으로 내보낼 수 있습니다.

OpenTelemetry로 수집된 데이터는 Jaeger의 백엔드로도 보낼 수 있습니다. 그러나 Jaeger는 UI 측면에서 제한적이며 분산 추적만 수행합니다. 강력한 모니터링 및 관찰 가능성 프레임워크의 경우 메트릭과 추적 모두에 대한 통합 UI가 필요합니다. SigNoz는 분산 추적 도구로서 Jaeger보다 훨씬 더 적합 합니다.

SigNoz는 Jaeger 대신 사용할 수 있는 풀 스택 오픈 소스 애플리케이션 성능 모니터링 및 관찰 도구입니다. SigNoz는 기본적으로 OpenTelemetry를 지원하도록 구축되었습니다. 또한 스토리지 측면에서 사용자에게 유연성을 제공합니다. SigNoz를 설치하는 동안 백엔드 스토리지로 ClickHouse 또는 Kafka + Druid 중에서 선택할 수 있습니다.

---

서비스 디스커버리

- CoreDNS는 서비스 검색에 유용한 빠르고 유연한 도구입니다.
- Envoy와 Linkerd는 각각 서비스 메시 아키텍처를 가능하게 합니다.
그들은 상태 점검, 배선 및 부하 차단 기능을 제공합니다.

 

* Envoy

What?

Envoy는 대규모 현대식 서비스 지향 아키텍처용으로 설계된 L7 프록시 및 통신 버스입니다. 프로젝트는 다음과 같은 믿음에서 시작되었습니다.

네트워크는 애플리케이션에 투명해야 합니다. 네트워크 및 응용 프로그램 문제가 발생하면 문제의 원인을 파악하기 쉬워야 합니다.

실제로 앞에서 언급한 목표를 달성하는 것은 매우 어렵습니다. Envoy는 다음과 같은 고급 기능을 제공하여 그렇게 하려고 합니다.

프로세스 외 아키텍처: Envoy는 모든 애플리케이션 서버와 함께 실행되도록 설계된 자체 포함된 프로세스입니다. 모든 Envoy는 각 응용 프로그램이 localhost와 메시지를 주고받으며 네트워크 토폴로지를 인식하지 못하는 투명한 통신 메시를 형성합니다. out of process 아키텍처는 서비스 간 통신에 대한 기존 라이브러리 접근 방식에 비해 두 가지 상당한 이점이 있습니다.

• Envoy는 모든 애플리케이션 언어로 작동합니다. 단일 Envoy 배포는 Java, C++, Go, PHP, Python 등 사이에 메시를 형성할 수 있습니다. 서비스 지향 아키텍처에서 여러 애플리케이션 프레임워크 및 언어를 사용하는 것이 점점 보편화되고 있습니다. Envoy는 그 격차를 투명하게 연결합니다.
• 대규모 서비스 지향 아키텍처를 사용해 본 사람이라면 누구나 알고 있듯이 라이브러리 업그레이드 배포는 매우 고통스러울 수 있습니다. Envoy는 전체 인프라에서 투명하게 빠르게 배포 및 업그레이드할 수 있습니다.

L3/L4 필터 아키텍처: Envoy의 핵심은 L3/L4 네트워크 프록시입니다. 플러그형 필터 체인 메커니즘을 사용하면 필터를 작성하여 다양한 TCP/UDP 프록시 작업을 수행하고 주 서버에 삽입할 수 있습니다. 필터는 원시 TCP 프록시 , UDP 프록시 , HTTP 프록시 , TLS 클라이언트 인증서 인증 , Redis , MongoDB , Postgres 등과 같은 다양한 작업을 지원하도록 이미 작성되었습니다 .

HTTP L7 필터 아키텍처: HTTP는 Envoy 가 추가 HTTP L7 필터 계층을 지원하는 현대 애플리케이션 아키텍처의 중요한 구성 요소입니다. HTTP 필터는 버퍼링 , 속도 제한 , 라우팅/전달 , Amazon의 DynamoDB 스니핑 등과 같은 다양한 작업을 수행하는 HTTP 연결 관리 하위 시스템에 연결할 수 있습니다 .

일류 HTTP/2 지원: HTTP 모드에서 작동할 때 Envoy는 HTTP/1.1과 HTTP/2를 모두 지원합니다. Envoy는 양방향에서 투명한 HTTP/1.1 대 HTTP/2 프록시로 작동할 수 있습니다. 이것은 HTTP/1.1 및 HTTP/2 클라이언트와 대상 서버의 모든 조합이 브리지될 수 있음을 의미합니다. 서비스 구성에 권장되는 서비스는 모든 Envoy 간에 HTTP/2를 사용하여 요청과 응답을 다중화할 수 있는 영구 연결 메시를 만듭니다.

HTTP/3 지원(현재 알파 버전): 1.19.0부터 Envoy는 이제 HTTP/3 업스트림 및 다운스트림을 지원하고 HTTP/1.1, HTTP/2 및 HTTP/3의 모든 조합 간의 번역을 양방향으로 지원합니다.

HTTP L7 라우팅: HTTP 모드에서 작동할 때 Envoy는 경로, 권한, 콘텐츠 유형, 런타임 값 등에 따라 요청을 라우팅하고 리디렉션할 수 있는 라우팅 하위 시스템을 지원합니다 . 이 기능은 Envoy를 프런트/에지로 사용할 때 가장 유용합니다. 프록시이지만 서비스 메시를 구축할 때도 활용됩니다.

gRPC 지원: gRPC 는 기본 다중 전송으로 HTTP/2 이상을 사용하는 Google의 RPC 프레임워크입니다. Envoy는 gRPC 요청 및 응답을 위한 라우팅 및 로드 밸런싱 기판으로 사용하는 데 필요한 모든 HTTP/2 기능을 지원합니다. 두 시스템은 매우 상호 보완적입니다.

서비스 검색 및 동적 구성: Envoy는 선택적 으로 중앙 집중식 관리를 위해 계층화된 동적 구성 API 세트를 사용합니다. 계층은 Envoy에 백엔드 클러스터 내의 호스트, 백엔드 클러스터 자체, HTTP 라우팅, 수신 소켓 및 암호화 자료에 대한 동적 업데이트를 제공합니다. 더 간단한 배포를 위해 백엔드 호스트 검색은 DNS 확인을 통해 수행 할 수 있습니다 (또는 완전히 건너뛸 수도 있음). 추가 계층은 정적 구성 파일로 대체됩니다.

상태 확인: Envoy 메시를 구축하는 데 권장 되는 방법은 서비스 검색을 최종적으로 일관된 프로세스로 처리하는 것입니다. Envoy에는 업스트림 서비스 클러스터의 활성 상태 확인을 선택적으로 수행할 수 있는 상태 확인 하위 시스템이 포함되어 있습니다. 그런 다음 Envoy는 서비스 검색 및 상태 확인 정보의 통합을 사용하여 정상적인 로드 밸런싱 대상을 결정합니다. Envoy는 또한 이상치 탐지 하위 시스템 을 통해 수동 상태 확인을 지원합니다 .

고급 로드 밸런싱: 분산 시스템에서 서로 다른 구성 요소 간의 로드 밸런싱 은 복잡한 문제입니다. Envoy는 라이브러리가 아닌 자체 포함된 프록시이기 때문에 한 곳에서 고급 로드 밸런싱 기술을 구현할 수 있고 모든 애플리케이션에서 액세스할 수 있습니다. 현재 Envoy는 자동 재시도, 회로 차단 , 외부 속도 제한 서비스를 통한 전역 속도 제한 , 요청 섀도잉 및 이상값 감지 에 대한 지원을 포함 합니다. 요청 레이싱에 대한 향후 지원이 계획되어 있습니다.

프론트/에지 프록시 지원: 에지 에서 동일한 소프트웨어를 사용하면 상당한 이점이 있습니다(관측성, 관리, 동일한 서비스 검색 및 로드 밸런싱 알고리즘 등). Envoy에는 대부분의 최신 웹 애플리케이션 사용 사례에 대한 에지 프록시로 적합하도록 하는 기능 세트가 있습니다. 여기에는 TLS 종료, HTTP/1.1 HTTP/2 및 HTTP/3 지원 , HTTP L7 라우팅 이 포함 됩니다.

동급 최고의 관찰 가능성: 위에서 언급했듯이 Envoy의 주요 목표는 네트워크를 투명하게 만드는 것입니다. 그러나 문제는 네트워크 수준과 응용 프로그램 수준 모두에서 발생합니다. Envoy에는 모든 하위 시스템에 대한 강력한 통계 지원이 포함되어 있습니다. statsd (및 호환 가능한 공급자)는 현재 지원되는 통계 싱크이지만 다른 것을 연결하는 것은 어렵지 않습니다. 통계는 관리 포트 를 통해서도 볼 수 있습니다. Envoy는 타사 공급자를 통한 분산 추적 도 지원합니다.

 

Why?

 어떤 사람들은 우리가 기존 도구를 사용하거나 내장된 언어 프레임워크를 사용하여 이를 달성할 수 있다고 주장할 수 있습니다. 그렇다면 Envoy를 사용하는 이유는 무엇일까요? Envoy가 레거시 애플리케이션을 실행하는 기업에서 가장 많이 사용되는 것을 봅니다. Envoy를 사이드카 또는 프론트 프록시로 사용하면 애플리케이션 코드를 건드리지 않고도 거의 모든(이전/신규) 애플리케이션의 보안, 안정성 및 관찰 가능성을 쉽게 개선할 수 있습니다.

 

* CoreDNS

What? CoreDNS는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버입니다. 쿠버네티스와 동일하게, CoreDNS 프로젝트도 CNCF가 관리합니다.

사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는 kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있습니다.

 Go 로 작성되었습니다 . 유연성으로 인해 다양한 환경에서 사용할 수 있습니다. CoreDNS는 Apache 라이선스 버전 2 및 완전 오픈 소스에 따라 라이선스가 부여됩니다.

CoreDNS Architecture

 

* Linkerd

What? Linkerd는 Buoyant에서 서비스 메시로 설치하기 위해 개발한 오픈 소스 네트워크 프록시입니다. Linkerd는 서비스 메시라는 용어와 연결되는 최초의 제품 중 하나이며 Docker 및 Kubernetes와 같은 플랫폼을 지원합니다.
정보 기술에서 서비스 메시는 서비스간 통신을 제어하고 애플리케이션의 개별 부분이 서로 통신할 수 있도록 하기 위해 만들어진 전용 인프라 계층입니다. 서비스 메시는 일반적으로 클라우드 기반 애플리케이션, 컨테이너 및 마이크로서비스에 사용 됩니다.
마이크로서비스 애플리케이션에서 최대 수백개의 서비스가 서로 통신하기 때문에 어던 서비스가 서로 통신하는지 추적하는 것이 힘들 수 있습니다. Linkerd는 로드 밸런싱, 서비스 검색, 프록시 통합 및 투명성, 적응형 라우팅, 장애 복구, 회로 차단 및 계측과 같은 기능을 제공하여 이러한 서비스 간의 통신을 보호하는 클라우드 오케스트레이션 도구입니다.

 

Why? 

• 완전히 오픈 소스이며 매우 활발한 커뮤니티가 있습니다.
• 마이크로 서비스 클러스터에 Service Mesh를 추가하는 것은 매우 중요합니다.
• 개발자와 DevOps 직원 모두 애플리케이션에서 병목 현상을 찾는 데 도움이 됩니다.
• Service Mesh는 클러스터에서 실행되는 여러 응용 프로그램 간의 서비스 간 통신을 모니터링하는 탁월한 선택입니다.
• 많은 대기업에서 프로덕션에서 전투 테스트를 거쳤습니다.
• Istio와 함께 가장 많이 사용되는 Service Mesh 중 하나입니다.
• 독립적으로 작동하며 라이브러리나 언어에 종속되지 않습니다.

다음과 같은 장점이 있습니다.

• Istio 는 클러스터에서 설정하기가 상당히 어렵지만 Linkerd의 경우 구성이 필요하지 않으므로 즉시 사용할 수 있습니다.
• 수평으로 쉽게 확장할 수 있습니다.
• HTTP, http/2, gRPC 및 거의 모든 일반적으로 사용되는 프로토콜을 지원합니다.
• TLS 애플리케이션 전체를 허용합니다.
• 고도로 지능적인 최신 로드 밸런싱 알고리즘을 사용하여 트래픽을 분산합니다.
• 요청 라우팅을 동적으로 허용하고 그에 따라 트래픽을 이동합니다.
• 분산 추적을 제공하여 문제의 근본 원인을 추적합니다.
• 현대 마이크로서비스 세계와 잘 맞습니다.
• 복원력, 관찰 가능성 및 부하 분산과 같은 기능을 제공합니다 .
• Prometheus 와 Grafana를 즉시 제공합니다 .
• 또한 실시간으로 일어나는 일을 관찰할 수 있는 자체 대시보드가 ​​있습니다.

---

네트워킹 / 보안

- 보다 유연한 네트워킹을 사용하려면 Calico, Flannel 또는 Wave Net과 같은 CNI 호환 네트워크를 고려할 수 있습니다.

- OPA(Open Policy Agent)는 승인 및 승인 제어에서 데이터 필터링에 이르기까지 범용 정책 엔진입니다.

- Falco는 클라우드 네이티브를 위한 이상 감지 엔진입니다.

 

* CNI(Container Network Interface)

What? 네트워킹 리소스를 동적으로 구성하기 위한 프레임워크입니다. Go로 작성된 라이브러리와 사양 그룹을 사용합니다. 플러그인 규격은 네트워크를 구성하고 IP 주소를 프로비저닝하며 여러 호스트와의 연결을 유지하기 위한 인터페이스를 정의합니다.

 CNI는 Kubelet과 원활하게 통합되어 Overlay 또는 Underlay 네트워크를 사용하여 포드 간의 네트워크를 자동으로 구성할 수 있습니다. Overlay 네트워크는 VXLAN(Virtual Extensible LAN)과 같은 가상 인터페이스를 사용하여 네트워크 트래픽을 캡슐화합니다. Underlay 네트워크는 물리적 수준에서 작동하며 스위치와 라우터로 구성됩니다.
 네트워크 구성 유형을 지정했으면 컨테이너 런타임은 컨테이너가 가입할 네트워크를 정의합니다. 런타임은 CNI 플러그인에 대한 호출을 통해 컨테이너 네임스페이스에 인터페이스를 추가하고 IPAM(IP Address Management) 플러그인에 대한 호출을 통해 연결된 하위 네트워크 경로를 할당합니다.
 CNI는 쿠버네티스 네트워킹을 지원하며 OpenShift와 같은 다른 쿠버네티스 기반 컨테이너 오케스트레이션 플랫폼에서도 사용할 수 있습니다. 소프트웨어 정의 네트워킹(SDN) 접근 방식을 사용하여 클러스터 전체의 컨테이너 통신을 통합합니다.

 

Why? Linux 컨테이너 및 컨테이너 네트워킹 기술은 다양한 환경에서 실행되는 애플리케이션의 요구를 충족하기 위해 지속적으로 발전하고 있습니다. 
 CNI는 네트워킹 솔루션을 다양한 컨테이너 오케스트레이션 시스템 및 런타임과 통합할 수 있도록 하기 위해 만들어졌습니다. 네트워킹 솔루션을 플러그형으로 만드는 대신 네트워킹 및 컨테이너 실행 계층 모두를 위한 공통 인터페이스 표준을 정의합니다.
CNI는 컨테이너 네트워크의 연결과 컨테이너 종료 시 할당된 자원의 제거에 초점을 맞춥니다. 이것은 CNI 규격을 단순하게 만들고 널리 채택할 수 있게 합니다. CNI Github 프로젝트는 타사 플러그인과 이를 사용하는 런타임 등 CNI 사양에 대한 더 많은 정보를 제공하고 있습니다.

 

* Open Policy Agent(OPA)

What? OPA 오픈 소스 범용 정책 엔진입니다. OPA는 일반적으로 비즈니스 논리라고 하는 것과 같은 애플리케이션의 다른 책임에서 정책 결정을 분리합니다. OPA는 단일 통합 정책 언어 덕분에 Kubernetes, 마이크로서비스, 기능적 애플리케이션 권한 부여 등에 대한 결정을 내리는 데 동등하게 잘 작동합니다.

Why?

• Rego - Open Policy Agent 는 Rego 라는 고급 선언 언어를 사용하여 정책을 설명합니다. Rego를 사용하면 오늘날 거의 모든 시스템에서 널리 사용되는 JSON 또는 YAML로 표현되는 것과 같은 계층 구조 데이터에 대한 정책 규칙을 쉽게 구축할 수 있습니다. 목적에 맞게 구축된 정책 언어를 사용하면 정책을 위해 만들어진 기본 제공 및 기본 제공 맞춤식을 사용하여 정책을 간결하게 설명할 수 있습니다 . OPA에는 JSON 웹 토큰, 네트워킹, 암호화, 시간 등에 대한 지원을 포함하여 정책을 작성하는 데 도움 이 되는 150개 이상의 기본 제공 기능 이 포함되어 있습니다.
• 범용 - OPA는 임의의 구조화된 데이터(JSON, YAML 등)에 대한 정책 및 규칙을 표현하는 데 사용할 수 있습니다. 일반적인 사용 사례에는 애플리케이션 및 마이크로서비스 권한 부여 , Kubernetes 승인 제어 , 인프라 정책 및 구성 관리가 포함됩니다. OPA는 라이브러리로 포함되거나 데몬으로 배포되거나 단순히 명령줄에서 실행할 수 있습니다. OPA의 범용 특성을 통해 조직은 인프라, 애플리케이션 승인 또는 Kubernetes 승인 제어를 위한 것인지 여부에 관계없이 클라우드 네이티브 스택 전반  에 정책 시행을 위한 단일 도구 를 배포할 수 있습니다.
• 클라우드 네이티브 - OPA는 Kubernetes, Envoy 및 Prometheus와 같은 다른 저명한 클라우드 네이티브 프로젝트와 함께 CNCF(Cloud Native Computing Foundation) 내의 졸업 프로젝트입니다. OPA는 처음부터 컨테이너화된 클라우드 네이티브 환경에서 실행되도록 구축되었으며 가벼운 특성으로 인해 마이크로서비스 아키텍처 및 서버리스 워크로드와 같이 고도로 분산된 환경에 배포할 수 있습니다. 그렇다고 해서 OPA가 보다 전통적인 환경에 적합하지 않다는 의미는 아닙니다. 반대로 클라우드 네이티브 환경을 위해 구축함으로써 얻을 수 있는 대부분의 이점은 클라우드 네이티브 환경에서도 그대로 적용됩니다. 
• 오픈 소스 - 모든 OPA 코드는 자유로운 Apache 2 라이선스에 따라 릴리스됩니다. 이를 통해 누구나 개인 사용자 또는 상업용 응용 프로그램의 필요에 맞게 소스 코드를 읽고 수정할 수 있습니다. 실제로 여러 회사 에서 서비스 및 제품에 OPA를 통합합니다.
• 커뮤니티 및 생태계 - OPA의 범용 모델은 오픈 소스 라이선스 및 정책 엔진으로서의 많은 자질과 함께 프로젝트를 중심으로 성장하는 번창하는 커뮤니티와 생태계를 가져왔습니다. GitHub 에서 프로젝트를 확인하세요 . 또한 OPA 에코시스템 페이지에는 언어 통합, 데이터 필터링 및 인프라 도구에서 시스템 통합 및 서비스 메시 애드온 구축에 이르기까지 다양한 사용 사례를 다루는 커뮤니티의 기업과 개인이 모두 50개 이상의 통합을 나열합니다.
• 중앙 집중식 관리 - OPA의 관리 API를 통해 OPA는 정책 및 데이터 번들 을 가져 오고 상태 및 상태를 보고하고 결정 로그 를 Styra DAS(Declarative Authorization Service) 와 같은 중앙 제어 평면 구성 요소에서/로 보낼 수 있습니다. 이를 통해 수백 또는 수천 개의 OPA가 배포된 분산 환경에서도 OPA를 제어, 관리 및 모니터링할 수 있습니다.

* Falco

What? Falco는 Kubernetes, 컨테이너 및 클라우드 전반에서 지속적인 위험 및 위협 탐지를 위한 오픈 소스 표준 도구입니다. Falco는 보안 카메라 역할을 하여 예기치 않은 동작, 구성 변경, 침입 및 데이터 도난을 실시간으로 지속적으로 감지합니다.

• 런타임에 커널에서 Linux 시스템 호출 구문 분석
• 강력한 규칙 엔진에 대한 스트림 주장
• 규칙 위반 시 알림

---

분산 데이터베이스 / 저장소

- 단일 데이터베이스에서 얻을 수 있는 것보다 더 많은 복원력과 확장성이 필요한 경우, Vitess는 샤딩을 통해 MySQL을 규모에 맞게 실행할 수 있는 좋은 옵션입니다.
- Rook은 다양한 스토리지 솔루션 세트를 쿠버네티스에 통합하는 스토리지 오케스트레이터입니다.
- 쿠버네티스의 두뇌 역할로써, etcd는 여러 머신에 걸쳐 데이터를 저장할 수 있는 신뢰할 수 있는 방법을 제공합니다.
- TiKV는 러스트로 작성된 고성능 분산 트랜잭션 키-값 저장소입니다.

 

* Vitess

What? Vitess는 오픈 소스 데이터베이스 인스턴스의 대규모 클러스터를 배포, 확장 및 관리하기 위한 데이터베이스 솔루션입니다. 현재 MySQL, Percona 및 MariaDB를 지원합니다. 전용 하드웨어에서와 마찬가지로 퍼블릭 또는 프라이빗 클라우드 아키텍처에서 효과적으로 실행되도록 설계되었습니다. NoSQL 데이터베이스의 확장성과 함께 많은 중요한 SQL 기능을 결합하고 확장합니다. Vitess는 다음과 같은 문제를 해결하는 데 도움이 될 수 있습니다.

1. 응용 프로그램 변경 사항을 최소화하면서 샤딩을 허용하여 SQL 데이터베이스를 확장합니다.
2. 베어메탈에서 프라이빗 또는 퍼블릭 클라우드로 마이그레이션.
3. 많은 수의 SQL 데이터베이스 인스턴스 배포 및 관리.

Vitess에는 기본 쿼리 프로토콜을 사용하는 호환 JDBC 및 Go 데이터베이스 드라이버가 포함되어 있습니다. 또한 거의 모든 다른 언어와 호환되는 MySQL 서버 프로토콜을 구현합니다.

Vites는 5년 넘게 모든 YouTube 데이터베이스 트래픽을 처리했습니다. 이제 많은 기업에서 생산 요구 사항에 따라 Vites를 채택했습니다.

 

• 성능
  • 연결 풀링 - 프론트 엔드 애플리케이션 쿼리를 MySQL 연결 풀에 다중화하여 성능을 최적화합니다.
  • 쿼리 중복 제거 – 진행 중인 쿼리가 계속 실행되는 동안 수신된 동일한 요청에 대해 진행 중인 쿼리의 결과를 재사용합니다.
  • 트랜잭션 관리자 – 동시 트랜잭션 수를 제한하고 시간 초과를 관리하여 전체 처리량을 최적화합니다.
• 보호
  • 쿼리 재작성 및 삭제 – 제한을 추가하고 비결정적 업데이트를 방지합니다.
  • 쿼리 블랙리스트 – 잠재적으로 문제가 있는 쿼리가 데이터베이스에 도달하지 않도록 규칙을 사용자 지정합니다.
  • 쿼리 킬러 – 데이터를 반환하는 데 너무 오래 걸리는 쿼리를 종료합니다.
  • 테이블 ACL – 연결된 사용자를 기반으로 테이블에 대한 ACL(액세스 제어 목록)을 지정합니다.
• 모니터링
  • 성능 분석 도구를 사용하면 데이터베이스 성능을 모니터링, 진단 및 분석할 수 있습니다.
• 토폴로지 관리 도구
  • 클러스터 관리 도구(부모 변경 처리).
  • 웹 기반 관리 GUI.
  • 여러 데이터 센터/지역에서 작동하도록 설계.
• 샤딩
  • 거의 원활한 동적 리샤딩.
  • 수직 및 수평 샤딩 지원.
  • 맞춤형 구성을 플러그인할 수 있는 다중 분할 구성표.

* Rook

What? Rook은 분산 스토리지 시스템을 자가 관리, 자가 확장, 자가 치유 스토리지 서비스로 전환합니다. 배포, 부트스트랩, 구성, 프로비저닝, 확장, 업그레이드, 마이그레이션, 재해 복구, 모니터링 및 리소스 관리와 같은 스토리지 관리자의 작업을 자동화합니다.

Rook은 Kubernetes 플랫폼의 기능을 사용하여 각 스토리지 제공업체에 대해 Kubernetes Operator를 통해 서비스를 제공합니다.

 

Why?

• 간단하고 안정적인 자동 리소스 관리
• 스토리지 클러스터의 하이퍼 스케일 또는 하이퍼 컨버전스
• 데이터를 효율적으로 배포 및 복제하여 손실 최소화
• 여러 스토리지 제공자를 통해 프로비저닝, 파일, 차단 및 개체 생성
• 오픈 소스 스토리지 기술 관리
• 데이터 센터에서 손쉽게 탄력적 스토리지 활성화
• Apache 2.0 라이선스에 따라 출시된 오픈 소스 소프트웨어
• 상용 하드웨어에서 워크로드 최적화

 

* etcd

What? 쿠버네티스 Master 노드의 두뇌 역할을 하고 있습니다. 모든 상태와 데이터를 저장하는 역할을 합니다. Key-Value 형태로 저장됩니다. 부트스트래핑, 쿼럼 유지, 클러스터 멤버십 재설정, 백업 생성, 재해 복구 처리, 중요 이벤트 모니터링 등을 제공합니다. 

 

Why? 쿠버네티스 Master 노드에서는 API Server, Controller, Schedular 등 다양한 역할을 하는 것들이 있는데 이들의 작업 수행이나 상호작용들에 대해 조정하는 역할을 하기 위해 만들어졌습니다. 

 

* TiKV

What?

 TiKV는 확장성이 뛰어나고 대기 시간이 짧으며 사용하기 쉬운 키-값 데이터베이스로, 어떤 규모에서든 10ms 미만의 성능을 제공합니다. 
 TiKV는 유니파이드 분산 스토리지 계층의 역할을 수행하기 위한 것입니다. TiKV는 수 조 개의 행에 걸친 페타바이트 규모의 구현을 지원함으로써 대규모 데이터 작업에 탁월합니다.
 클라우드 네이티브 컴퓨팅 재단의 대학원 프로젝트인 TiKV는 원래 TiDB를 보완하기 위해 PingCAP에 의해 개발되었습니다.

 

Why? Latency가 짧고 안정적입니다. RawKV의 평균 응답 시간이 1ms(P99=10ms) 미만입니다.

 높은 확장성을 가지고 있습니다. 수평 확장성이 뛰어나며 100 테라바이트 이상의 데이터까지 쉽게 확장할 수 있습니다. 애플리케이션에 영향을 미치지 않고 데이터 크기 증가에 맞게 TiKV 클러스터를 스케일아웃할 수 있습니다.
 사용하기 쉽습니다. 단일 명령을 실행하여 프로덕션 환경에 필요한 모든 것이 포함된 TiKV 클러스터를 구축합니다. TiUP 또는 TiKV 운영자를 사용하여 클러스터에서 쉽게 확장 또는 확장할 수 있습니다.
 유지 관리가 용이합니다. TiKV는 구글 스패너와 HBase의 설계에 기반을 두고 있지만 분산 파일 시스템에 의존하지 않고 간단하게 관리할 수 있습니다.
 부가적으로, 구글의 스패너와 비슷하게 TiKV(TxnKV 모드)는 외부적으로 일관된 분산 트랜잭션을 지원합니다. 또한, RawKV 및 TxnKV 모드에서는 일관성과 성능 간의 균형을 사용자 지정할 수 있습니다.

---

스트리밍 / 메세징

- JSON-REST보다 높은 성능이 필요한 경우 gRPC 또는 NATS를 사용하는 것을 고려할 수 있습니다.
- gRPC는 범용 RPC 프레임워크 입니다. 
- NATS는 요청/응답, pub/sub 및 로드 밸런싱 대기열을 포함하는 다중 모드 메시징 시스템입니다. 
- CloudEvents는 이벤트 데이터를 일반적인 방식으로 설명하기 위한 사양입니다.

 

* gRPC

What? gRPC는 모든 환경에서 실행할 수 있는 최신 오픈 소스 고성능 RPC(원격 프로시저 호출) 프레임워크입니다. 클라이언트와 서버 응용 프로그램이 투명하게 통신할 수 있게 하고 연결된 시스템을 더 쉽게 구축할 수 있도록 합니다. 로드 밸런싱, 추적, 상태 확인 및 인증을 위한 플러그형 지원을 통해 데이터 센터 안팎에서 서비스를 효율적으로 연결할 수 있습니다. 또한 디바이스, 모바일 애플리케이션 및 브라우저를 백엔드 서비스에 연결하는 분산 컴퓨팅의 라스트 마일에도 적용할 수 있습니다.

 

Why?

• 짧은 대기 시간, 확장성이 뛰어난 분산 시스템.
• 클라우드 서버와 통신하는 모바일 클라이언트를 개발합니다.
• 정확하고 효율적이며 언어 독립적이어야 하는 새로운 프로토콜을 설계합니다.
• 확장을 가능하게 하는 레이어드 디자인. 인증, 로드 밸런싱, 로깅 및 모니터링 등.

* NATS

What?

소프트웨어 애플리케이션과 서비스는 데이터를 교환해야 합니다. NATS는 메시지 형태로 분할된 이러한 데이터 교환을 허용하는 인프라입니다. 우리는 이것을 " 메시지 지향 미들웨어 "라고 부릅니다.

NATS를 사용하여 애플리케이션 개발자는 다음을 수행할 수 있습니다.

• 분산되고 확장 가능한 클라이언트-서버 애플리케이션을 손쉽게 구축합니다.
• 일반적인 방식으로 실시간으로 데이터를 저장하고 배포합니다. 이는 다양한 환경, 언어, 클라우드 제공업체 및 온프레미스 시스템에서 유연하게 달성할 수 있습니다.

* CloudEvents

What?

이벤트는 어디에나 있습니다. 그러나 이벤트 생산자는 이벤트를 다르게 설명하는 경향이 있습니다.

이벤트를 설명하는 일반적인 방법이 없다는 것은 개발자가 이벤트를 사용하는 방법을 지속적으로 다시 배워야 한다는 것을 의미합니다. 이는 또한 SDK, 이벤트 라우터 또는 추적 시스템과 같은 환경 전반에서 이벤트 데이터 전달을 지원하는 라이브러리, 도구 및 인프라의 가능성을 제한합니다. 이벤트 데이터에서 얻을 수 있는 이동성과 생산성은 전반적으로 저해됩니다.

CloudEvents는 서비스, 플랫폼 및 시스템 간의 상호 운용성을 제공하기 위해 공통 형식으로 이벤트 데이터를 설명하기 위한 사양입니다.

CloudEvents는 주요 클라우드 제공업체에서 인기 있는 SaaS 회사에 이르기까지 업계의 많은 관심을 받았습니다. CloudEvents는 CNCF ( Cloud Native Computing Foundation )에서 호스팅하며 2018년 5월 15일 에 Cloud Native 샌드박스 수준 프로젝트로 승인되었습니다.

 

Why? 

- 일관성
이벤트를 설명하는 일반적인 방법이 없다는 것은 개발자가 각 이벤트 소스에 대한 새로운 이벤트 처리 로직을 작성해야 한다는 것을 의미합니다.
- 접근성
공통 이벤트 형식이 없다는 것은 환경 전반에 걸쳐 이벤트 데이터를 전달하기 위한 공통 라이브러리, 도구 및 인프라가 없음을 의미합니다. CloudEvents는 이벤트 라우터, 추적 시스템 및 기타 도구를 빌드하는 데 사용할 수 있는 Go , JavaScript , Java , C# , Ruby , PHP , PowerShell , Rust 및 Python 용 SDK를 제공합니다.
- 휴대성
이벤트 데이터에서 얻을 수 있는 이동성과 생산성은 전반적으로 저해됩니다.

---

컨테이너 레지스트리 / 런타임

- Harbor는 콘텐츠를 저장하고 서명하고 스캔하는 레지스트리입니다.
- 대체 컨테이너 런타임을 사용할 수 있습니다.
- 가장 일반적인 OCI 규격은 containerd와 CRI-O이다.

 

* Harbor

What? Harbor는 정책 및 역할 기반 액세스 제어로 아티팩트를 보호하고, 이미지가 스캔되고 취약성이 없는지 확인하고, 이미지를 신뢰할 수 있는 것으로 서명하는 오픈 소스 레지스트리입니다. CNCF 졸업 프로젝트인 Harbor는 규정 준수, 성능 및 상호 운용성을 제공하여 Kubernetes 및 Docker와 같은 클라우드 네이티브 컴퓨팅 플랫폼에서 일관되고 안전하게 아티팩트를 관리하는 데 도움이 됩니다.

 

* containerd

What? containerd 는 Linux 및 Windows용 데몬으로 사용할 수 있습니다. 이미지 전송 및 저장에서 컨테이너 실행 및 감독, 저수준 저장, 네트워크 연결 및 그 이상에 이르기까지 호스트 시스템의 전체 컨테이너 수명 주기를 관리합니다.

 

* CRI-O

What? CRI-O는 OCI(Open Container Initiative) 호환 런타임을 사용할 수 있도록 하는 Kubernetes CRI(Container Runtime Interface)의 구현입니다.Kubernetes의 런타임으로 Docker를 사용하는 것보다 가벼운 대안입니다.이를 통해 Kubernetes는 모든 OCI 호환 런타임을 팟(Pod) 실행을 위한 컨테이너 런타임으로 사용할 수 있습니다.오늘날 컨테이너 런타임으로 runc 및 Kata Containers를 지원하지만 원칙적으로 모든 OCI 호환 런타임을 연결할 수 있습니다.

CRI-O는 OCI 컨테이너 이미지를 지원하며 모든 컨테이너 레지스트리에서 가져올 수 있습니다. Kubernetes의 런타임으로 Docker, Moby 또는 rkt를 사용하는 것보다 가벼운 대안입니다.

---

배포

- 안전한 소프트웨어 배포를 수행해야 하는 경우 TUF 구현인 Notary를 고려할 수 있습니다.

 

* The Update Framework(TUF)

What? TUF(The Update Framework)는 개발자가 소프트웨어 업데이트 시스템의 보안을 유지하도록 지원하여 리포지토리 또는 서명 키를 손상시키는 공격자에 대해서도 보호를 제공합니다. TUF는 개발자가 모든 소프트웨어 업데이트 시스템에 채택할 수 있는 유연한 프레임워크 및 사양 을 제공합니다.

TUF는 CNCF( Cloud Native Computing Foundation ) 의 일부로 Linux Foundation 에서 호스팅 하며 다양한 기술 회사 및 오픈 소스 조직 에서 프로덕션에 사용됩니다 . Uptane 이라고 하는 TUF의 변종은 자동차의 무선 업데이트를 보호하는 데 널리 사용됩니다.

 

* Notary

What? 인생에서 주택 구입과 같은 특정 중요한 사건 은 "공증인"이라는 신뢰할 수 있는 제3자가 진행 합니다.집을 구입할 때 이 사람은 일반적으로 대출 기관에 고용되어 귀하의 신원을 확인하고 모기지 계약서에 서명하는 증인 역할을 합니다.공증인은 특수 스탬프를 가지고 있으며 공증인이 참석하고 차용인과 관련된 모든 필수 정보를 확인했음을 확인하는 문서에 서명합니다.

비슷한 방식으로 Docker가 처음 후원한 Notary 프로젝트는 강력한 암호화 서명을 사용하여 디지털 콘텐츠에 대해 높은 수준의 신뢰를 제공하도록 설계되었습니다. 소프트웨어의 출처를 보장하는 것 외에도 공급망의 어디에서나 작성자의 승인 없이 콘텐츠가 수정되지 않는다는 보장도 제공합니다. 그러면 Docker Content Trust(Notary 사용)가 포함된 Docker Enterprise Edition(EE)과 같은 상위 수준 시스템에서 콘텐츠 사용에 대한 명확한 정책을 설정할 수 있습니다. 예를 들어, 서명된 콘텐츠만 런타임에 사용하고 Docker 플랫폼의 오케스트레이터에서 배포할 수 있도록 정책을 설정할 수 있습니다. 전체 공증인은 보안이 개발에서 운영에 이르기까지 워크플로에 원활하고 균일하게 포함되는 보안 공급망에 대한 Docker 접근 방식의 핵심 요소입니다.

Notary는 Go로 작성된 TUF(업데이트 프레임워크)를 구현한 것입니다. TUF는 NYU Tandon School of Engineering에서 개발되었습니다. TUF는 Notary와 협력하여 CNCF에 합류하기 위해 제출되었습니다. 이 두 프로젝트의 결합된 특성으로 인해 특히 강력한 기부가 이루어집니다. 사양과 가장 널리 배포된 구현이 CNCF의 후원 하에 함께 이루어지고 있습니다.

---

참고문헌

 

Vitess : https://thenewstack.io/cncf-host-vitess/

OPA : https://blog.styra.com/blog/what-is-open-policy-agent

Notary : https://www.docker.com/blog/notary-important-cncf/

Linkerd : https://searchitoperations.techtarget.com/definition/Linkerd

ArgoCD : https://www.nine.ch/en/engineering-logbook/what-is-argo-cd

Kubernetes : https://www.predicagroup.com/blog/why-kubernetes-2021/

Envoy : https://betterprogramming.pub/using-envoy-proxy-to-improve-reliability-security-and-observability-of-microservices-85032e08d3f4

CNCF Trail Map : https://github.com/cncf/landscape