왜 클라우드 쿠버네티스는 보이는 것만큼 공급업체에 독립적이 아닌가 – 그리고 그것에 대해 무엇을 해야 하는가

쿠버네티스는 오픈소스 플랫폼입니다. 그렇다면 공급업체에 독립적인 플랫폼이라고 생각할 수 있습니다. 즉, 한 Kubernetes 구현에서 다른 구현으로 쉽게 이동할 수 있다는 의미입니다.

하지만 그건 틀린 생각이에요. 현실은 많은 Kubernetes 솔루션, 특히 특정 퍼블릭 클라우드에 묶인 솔루션은 여러분이 생각하는 것보다 공급업체에 대한 의존성이 훨씬 낮다는 것입니다.

다행히도, 이는 잠금 현상을 피하고 싶다면 Kubernetes 호스팅 솔루션으로 퍼블릭 클라우드를 활용할 수 없다는 의미는 아닙니다. 물론 가능합니다. 하지만 특정 클라우드 공급업체의 Kubernetes 서비스에 얽매이지 않으면서도 클라우드 기반 Kubernetes의 이점을 누릴 수 있는 방식으로 Kubernetes 전략을 설계해야 합니다.

클라우드 기반 Kubernetes 옵션

오늘날 모든 주요 퍼블릭 클라우드는 SaaS 아키텍처를 통해 호스팅된 Kubernetes 서비스를 제공합니다. Amazon에는 Elastic Kubernetes Service가 있습니다. Azure는 Azure Kubernetes Service를 제공합니다. Google은 Google Kubernetes Engine을 제공합니다. IBM에는 IBM Cloud Kubernetes Service가 있습니다.

이러한 서비스는 클라우드 기반 인프라를 Kubernetes 배포 및 관리를 자동화하는 데 도움이 되는 소프트웨어와 결합하기 때문에 Kubernetes를 신속하게 사용하고자 하는 조직에 매력적인 솔루션입니다.

클라우드 쿠버네티스의 잠금 위험

이러한 클라우드 Kubernetes 서비스가 독립적이라는 사실도 그 매력을 증가시킵니다. 표면적으로 보면 한 Kubernetes SaaS 플랫폼에서 다른 Kubernetes SaaS 플랫폼으로 이동하는 것이 충분히 쉬울 것처럼 보일 수도 있습니다. 이러한 모든 플랫폼은 표준 오픈 소스 Kubernetes를 기반으로 합니다. 이러한 솔루션은 동일한 Kubernetes 툴링(예: kubectl)에 대한 액세스를 제공하며 일반적으로 동일한 유형의 스토리지 및 네트워킹 구성을 지원합니다. 이런 관점에서 보면, 그들은 공급업체에 대해 매우 중립적인 것처럼 보입니다.

그러나 더 깊이 파고들면 Kubernetes를 호스팅 서비스로 제공하는 퍼블릭 클라우드가 보이는 것만큼 유연하고 일반적이지 않다는 것을 깨닫게 됩니다. 이들은 다양한 방식으로 자신을 호스팅하는 퍼블릭 클라우드에서 실행되는 다른 서비스를 통합하고 의존합니다. Kubernetes 클러스터를 관리하는 데 사용하는 클라우드에서 IAM 정책을 생성해야 합니다. Azure Kubernetes Service의 경우 인증을 위해 Azure Active Directory와 같은 공급업체별 서비스를 사용하게 될 수 있습니다. 그리고 많은 경우, Kubernetes 서비스에서 엄격하게 요구하지 않더라도 사용자가 사용하기를 선호하는 추가 기능이나 대체 도구가 있습니다. 예를 들어 Google Kubernetes Engine은 kubectl 대신 gke-deploy를 사용하길 원하는 반면, Elastic Kubernetes Service는 Amazon의 독점 도구인 eksctl과 함께 사용하도록 설계되었습니다.

따라서 Kubernetes를 호스팅하는 클라우드에 관계없이 기본 Kubernetes 코드는 동일할 수 있으며, 실제로 노력한다면 일반적인 도구를 고수할 수도 있지만 결국 사용하게 될 도구와 구성은 공급업체에 독립적이지는 않습니다. 이러한 설정은 사용하는 Kubernetes 서비스에 따라 달라집니다.

예를 들어 Azure Kubernetes Service에서 Google Kubernetes Engine으로 전환하려는 경우 큰 장벽이 발생합니다. Kubernetes 워크로드를 리프트 앤 시프트할 수 있더라도 이를 지원하는 툴 체인과 구성 파일에 대해서는 동일한 작업을 수행할 수 없습니다.

클라우드 쿠버네티스 잠금 방지

Kubernetes 클러스터를 배포할 때 퍼블릭 클라우드의 편의성과 확장성을 활용하지만 종속성은 원하지 않는 경우, 두 가지 기본 솔루션이 있습니다.

하나는 클라우드 기반 가상 머신을 사용하여 수동으로 자체 클러스터를 설정한 다음 직접 관리하는 것입니다. 이 접근 방식을 사용하면 클라우드 공급업체의 SaaS Kubernetes 제품에서 제공하는 자동화 및 통합 기능은 얻을 수 없지만 인프라는 여전히 제공됩니다. 특수 툴을 사용하지 않으므로 모든 것을 다시 빌드하지 않고도 한 클라우드 호스트에서 다른 클라우드 호스트로 클러스터를 마이그레이션하는 것이 더 쉽습니다. 물론, 이것의 단점은 클러스터를 설정하고 관리하는 데 상당한 양의 수동 작업이 필요하다는 것입니다.

다른 접근 방식은 보다 자동화되고 확장성이 뛰어나며 Volterra의 VoltStack® 서비스와 같은 솔루션을 사용하여 클러스터가 어떤 클라우드에 있든 상관없이 클러스터를 관리하는 것입니다. 이 전략을 사용하면 각 공급업체 플랫폼의 클라우드 전용 툴링을 모든 퍼블릭 클라우드와 호환되는 중앙 집중식 명령 및 제어 센터로 대체하여 서로 다른 퍼블릭 클라우드 간에 클러스터를 쉽게 마이그레이션하거나 복제할 수 있습니다. 특정 퍼블릭 클라우드에 종속되지 않고도 Google Kubernetes Engine 및 Azure Kubernetes Engine과 같은 서비스에서 제공하는 것과 동일한 관리 용이성을 얻을 수 있습니다.

결론

어디서 어떻게 실행하든 쿠버네티스가 쿠버네티스일 것이라고 가정하는 실수는 저지르지 마세요. 다양한 클라우드 기반 Kubernetes 서비스 간에는 큰 차이가 있으며, 이로 인해 Kubernetes 클러스터를 한 클라우드에서 다른 클라우드로 이식하는 데 방해가 될 수 있습니다(각각 다른 도구 세트가 있기 때문에 서로 다른 클라우드에 있는 클러스터를 관리하는 것도 어렵게 만들 수 있음).

좋은 소식은 해결책이 있다는 것입니다. Volterra의 VoltStack 서비스와 같은 클라우드 독립적인 Kubernetes 관리 솔루션을 사용하여 모든 클러스터를 관리하면 특정 클라우드 공급자에 대한 종속성에서 벗어나면서도 클라우드 기반 Kubernetes의 사용 편의성을 활용할 수 있습니다.