SUSE에 합류해을 때, Rancher Kubernetes Engine (RKE), RKE2 및 K3s의 Kubernetes 배포판에 대해 들었습니다. 하지만 RKE와 RKE2의 차이는 저에게 분명하지 않았습니다. 그들과 시간을 보내기로 결심했고, 다른 점들에 대해 블로그를 쓰기로 했습니다.
RKE 및 RKE2를 설치
설치부터 시작하겠습니다. RKE 설치 프로세스에는 약간의 준비가 필요합니다. 구성의 기본이 포함된 yaml 파일을 제공하거나 몇 가지 질문을 하는 바이너리를 실행하고 해당 yaml 파일을 빌드해야 합니다. 제 경우, 문제는 질문들이 무엇을 요구하고 있는지 완전히 확신할 수 없다는 것이었습니다. 저는 무슨 일이 일어나고 있는지 이해하기 위해 설치 프로그램을 몇 번 실행하고 결과를 확인해야 했습니다. 일단 해결되면, 이것은 큰 문제가 아니다. HA 클러스터를 배포하고 단일 매니페스트에서 버전 및 구성 업데이트를 모두 수행할 수 있습니다.
RKE2의 경우 설치 프로세스가 더 명확합니다. 단일 노드를 설치하는 스크립트를 실행하면 됩니다. 나중에 토큰을 사용하여 노드를 추가할 수 있습니다. 또한 바이너리를 사용하여 클러스터의 노드를 구성할 수 있습니다. 프로세스를 최대한 단순하게 유지하기 위해 RKE2는 대부분의 구성에 대해 합리적인 기본값을 사용하지만 구성 파일을 사용하여 사용자 정의 값을 사용하여 클러스터를 배포할 수도 있습니다.
RKE 및 RKE2를 평가할 때 고려해야 할 가장 중요한 사항 중 하나는 설치 방법 및 Rancher와 함께 작동하는 방법입니다. 이미 Rancher를 사용하고 있거나 사용할 생각을 하고 있기 때문에 이러한 분포를 검정하고 있을 수 있습니다. 랜처에서 RKE와 RKE2의 배치 방식은 완전히 다릅니다. RKE의 경우, 우리는 오픈 소스이지만 표준화되지 않은 배포 방법을 사용합니다. 그러나 RKE2 및 K3s를 배포하기 위해 Kubernetes 클러스터 배포를 위한 사실상의 표준이 되고 있는 오픈 소스 프로젝트 Cluster API를 사용합니다. 이것은 좋지만 다른 이점도 있습니다. Rancher는 이미 여러 플랫폼에 RKE 및 RKE2 클러스터를 배포할 수 있도록 지원합니다. RKE2 및 K3s를 위한 구축 방법으로 Cluster API를 추가하여 게임을 새로운 수준으로 끌어올리고 있습니다. Rancher가 즉시 인프라 공급자를 지원하지 않더라도 Cluster API 및 해당 드라이버를 사용하여 Rancher의 UI 내에 사용자 지정 공급자를 생성할 수 있습니다. 그런 다음 Rancher의 관리 및 자동화 기능을 활용하고 Rancher의 API를 사용하여 사용하는 인프라 공급자에 관계없이 클러스터의 전체 라이프사이클을 관리할 수 있습니다.
RKE와 RKE2의 주요 차이점은?
RKE와 RKE2의 가장 큰 차이점은 컨테이너 런타임입니다. RKE는 컨테이너 런타임으로 Docker를 필요로 하는 반면, RKE2는 업계 표준 컨테이너 런타임이 된 containerd에 의존합니다. 2020년 12월 CNCF는 도커를 쿠버네티스의 기본 런타임으로 삭제하고 containerd로 기본 컨테이너 런타임으로 이동한다고 발표했습니다. 도커의 폐지는 2022년 2월에 일어났습니다. 또 다른 중요한 차이점은 RKE2는 kubelet에 의해 관리되는 정적 포드를 제어 평면으로 사용하는 반면 RKE에서는 제어 평면 포드가 도커에 의해 관리된다는 것입니다. containerd를 사용하면 RKE2가 컨테이너 레지스트리를 미러링할 수 있습니다. 이것은 도커 때문에 RKE에서는 가능하지 않습니다.
CNI 플러그인
두 배포판 모두 CNCF 인증 배포판을 완벽하게 준수하지만 컨테이너 런타임 외에도 고려해야 할 몇 가지 차이점이 있습니다. 첫째, RKE는 Canal, Flannel, Calico 및 Weave를 사용할 수 있는 RKE2와 다른 CNI 플러그인 통합을 제공합니다. RKE2에서는 Cillium, Calico, Canal 및 Multus를 사용할 수 있습니다. 특히 통신사 또는 멀티 NIC 사용 사례에 RKE2를 사용할 계획인 경우 Cillium과 Multus는 상당한 차이를 보입니다. 또한 Multus가 없으면 포드에서 여러 NIC를 사용할 수 없습니다. Cillium은 다양한 보안 및 규정 준수 기능과 함께 우수한 네트워킹 기능을 제공하며, 이는 Telco 애플리케이션에 매우 중요합니다.
보안
RKE2는 원래 미국 정부 프로젝트에 배치되도록 설계되었기 때문에 이전에는 RKE Government로 알려져 있었습니다. 이러한 시나리오에서는 보안이 가장 중요하므로 RKE2는 즉시 보안 및 규정 준수에 중점을 둡니다.
RKE2는 최소한의 노력과 구성으로 CIS Kubernetes 벤치마크 스캔을 통과하도록 구성되었으며, 암호화 모듈에 대한 FIPS 140-2 컴플라이언스를 지원하며, 클러스터에서 사용되는 이미지에서 CVE를 정기적으로 검색하기 위해 trivy를 사용합니다.
RKE는 보안에 중점을 두지 않는 표준 Kubernetes 배포판입니다.
또 다른 큰 차이가 있습니다. RKE2는 K3s를 기반으로 사용하기 때문에 단순성, 모듈성, 운영 용이성 및 구축 모델을 모두 갖추고 있으며, 두 가지 장점(RKE 및 K3s)을 모두 갖추고 있습니다. K3s는 리소스가 제한된 환경을 위한 가벼운 배포판이며 운영을 쉽게 하도록 설계되었습니다. 에지 시나리오에서는 수천 또는 수십만 개의 단일 노드 클러스터를 관리할 수 있기 때문입니다.
맺음말
RKE2는 RKE의 다음 새버전(interation)으로 간주됩니다. 보안, 간소화된 운영, 고급 CNI 플러그인과의 통합에 중점을 둔 RKE2는 Telco, 더 큰 네트워킹 기능을 갖춘 애플리케이션, 보안 및 규정 준수가 중요한 환경에 적합한 솔루션입니다. 그러나 RKE는 CNCF 인증을 받은 Kubernetes 배포판으로서 모든 종류의 생산 환경에서 사용할 수 있습니다.
Rancher Blog에 올라온 글을 기계번역했습니다. 출처 : https://www.suse.com/c/rancher_blog/rke-vs-rke2-comparing-kubernetes-distros/
