Kubernetes, 네트워킹 및 Cloud Native의 VMware 찾기

Thomas Graf는 공동 창립자이자 CTO입니다. 등가, 그리고 인기 있는 오픈 소스(및 클라우드 네이티브) 네트워킹 기술의 창시자 섬모. Cilium은 커널 수준의 Linux 기술을 기반으로 구축되었습니다. eGMP.

이 인터뷰에서 Graf는 Cilium과 eBPF가 성장하는 클라우드 네이티브 네트워킹 에코시스템에서 수행하는 역할과 Kubernetes 채택 및 진화에 대한 몇 가지 광범위한 추세에 대해 설명합니다. 그는 클라우드 네이티브 인프라가 여전히 개선되어야 하는 대기업 내에서 누가 Kubernetes를 사용하고 구매하는지, 그리고 표준화에 대한 열망이 어떻게 혁신을 주도하는지 설명합니다.

---

미래: 일반적으로 컴퓨팅 및 네트워킹의 맥락에서 eBPF와 Cilium에 대해 어떻게 생각해야 할까요? 클라우드 네이티브 생태계?

토마스 그라프: 전반적으로 eBPF는 기술이며 매우 낮은 수준입니다. 커널 개발자를 위해 설계되었으며 내 배경은 커널 개발입니다. eBPF는 커널, 운영 체제에, JavaScript는 브라우저에 대한 것입니다. JavaScript가 브라우저를 프로그래밍 가능하게 하는 것처럼 운영 체제를 프로그래밍 가능하게 만듭니다. 과거에는 특정 웹사이트를 실제로 사용하려면 브라우저 버전을 업그레이드해야 했습니다. 그리고 나서 JavaScript가 등장했고, 갑자기 애플리케이션 팀과 개발자는 가장 인기 있는 워드 프로세싱 애플리케이션이 브라우저 내 애플리케이션으로 대체될 정도로 대규모 애플리케이션을 구축할 수 있었습니다. 엄청난 혁신의 물결을 일으켰습니다. 

eBPF에서도 동일한 일이 발생하지만 운영 체제 수준에서는 갑자기 커널 또는 운영 체제 수준에서 모든 것을 보고 모든 것을 제어할 수 있기 때문에 커널을 변경하지 않고도 보안에 매우 중요한 모든 것을 제어할 수 있습니다. 소스 코드. 기본적으로 커널에 프로그램을 로드하여 기능을 확장하고 새로운 기능을 가져올 수 있습니다. 이것은 또한 엄청난 혁신의 물결을 불러일으켰습니다. Facebook, Google 및 Netflix와 같은 하이퍼스케일러는 자체 커널 팀과 함께 직접 이를 사용하고 있습니다. 

Cilium이 테이블에 가져오는 것은 저수준 eBPF 기술을 사용하여 특히 클라우드 네이티브 웨이브를 위한 새로운 소프트웨어 인프라를 본질적으로 제공한다는 것입니다. 이것을 소프트웨어 정의 네트워킹과 VMware NSX가 된 Nicira가 가상화 산업에 한 일과 같다고 생각하십시오. 우리는 클라우드 제공자 또는 퍼블릭 클라우드 인프라와 온프레미스 인프라가 혼합된 클라우드 네이티브에 대해서도 동일한 작업을 수행하고 있습니다. 그리고 우리는 인프라 계층에서 네트워킹, 보안 및 관찰 가능성 사용 사례를 해결하고 있습니다.

그리고 방금 출시된 Cilium Service Mesh는 이러한 기능의 진화입니까?

약 XNUMX년 전부터 현재 일어나고 있는 일은 두 공간이 충돌하고 있다는 것입니다. Cilium은 지금까지 네트워킹, 가상화 네트워킹, 클라우드 네이티브 네트워킹에 중점을 두고 있지만 여전히 네트워킹입니다. 그러나 위에서 아래로 내려오는 것은 Twitter와 Google의 애플리케이션 팀이 하는 일이었습니다. 서비스 메시 물건 — 응용 프로그램에서 먼저, 다음으로 사이드카 기반 모델, 프록시 기반 모델에서 프로젝트가 좋아하는 것 이스 티오 배달. 이제 이 두 층이 가까워지고 있기 때문에 기존 기업은 클라우드 네이티브 세계로 진입하고 있으며 기업 네트워킹 요구 사항이 있지만 앱 팀도 서비스 메시를 원합니다.. 

Gartner는 이 새로운 계층을 "서비스 연결성"이라고 부르고 있습니다. 이 용어가 유행하는지 알게 될 것입니다. 그러나 본질적으로 애플리케이션 팀에서 제공하는 엔터프라이즈 네트워킹 부분과 서비스 메시 부분을 포함하는 계층입니다. 그리고 그것이 고객이 요구하는 것이기 때문에 Cilium 자체에 기능을 추가했습니다. 따라서 기본적으로 Cilium은 엔터프라이즈 네트워킹 측면에서 위쪽으로 이동하고 서비스 메시는 더 많은 네트워킹 측면으로 아래쪽으로 이동합니다.

Kubernetes 스택의 네트워킹 및 서비스 메시 수준에 집중하는 이유는 무엇입니까?

여러 클라우드에서 실행하고 애플리케이션을 컨테이너로 분할하려는 욕구로 인해 연결 계층이 중심이 되었습니다. 과거에는 프로세스 간 통신과 미들웨어였던 것이 이제 네트워크가 되었습니다. 따라서 네트워크는 애플리케이션이 서로 통신하고 데이터가 흐르는 데 절대적으로 필수적인 요소가 되었습니다. 

특히 클라우드 네이티브에서는 멀티 클라우드가 절대적으로 필수가 되고 있습니다.. 모든 클라우드 제공업체에는 자체 네트워킹 계층이 있지만 물론 자체 클라우드에 맞게 조정됩니다. 온프레미스 제품이 있지만 진정한 멀티 클라우드는 아닙니다. Cilium과 eBPF는 다중 클라우드, 불가지론적 계층을 테이블로 가져옵니다. 퍼블릭 클라우드에서와 동일한 온프레미스 방식으로 작동합니다. 여러 퍼블릭 클라우드 제공업체는 관리형 Kubernetes 제품에 Cilium을 사용하고 있으며 통신 회사는 온프레미스 5G 인프라에 Cilium을 사용하고 있습니다. 두 언어를 모두 사용하고 이 세계를 연결하는 것입니다.

이것이 바로 이것에 집중하는 이유입니다. 클라우드 공급자가 고객을 가두는 가장 쉬운 방법 중 하나는 해당 연결 계층을 소유하는 것이기 때문입니다. 가상화 계층이 핵심이었던 것처럼 전략적 인프라 관점에서는 이제 연결성과 네트워크 계층이 절대적으로 중요하다고 생각합니다.

[미래] 혁신의 원천은 오픈 소스가 될 것이며 수요를 주도하는 고객과 사용자는 하이퍼스케일러보다 한 단계 낮은 기업이 될 것입니다.

Kubernetes는 이 시점에서 꽤 널리 받아들여지고 채택되었지만 여전히 일부 서클에서는 과도하다는 이야기가 있습니다. Kubernetes와 전반적인 클라우드 네이티브 에코시스템이 누구를 위한 것이라고 생각하십니까?

최신 애플리케이션 팀을 위한 것입니다. 최신 애플리케이션 팀을 유치하고 시장 출시 시간을 단축하려면 클라우드 네이티브 인프라를 제공해야 한다는 깨달음이 시작되었다고 생각합니다. Lambda와 같은 서버리스에서 프로토타이핑(초기, MVP 이전, 개념 증명 또는 내부 판매)을 종종 봅니다. 그리고 Kubernetes에서는 앱 팀이 인프라를 직접 소유할 수 있기 때문입니다. 그런 다음 프로덕션으로 이동하면서 엔터프라이즈 온프레미스 Kubernetes 배포로 이동합니다. 그러나 이는 실제로 전체 인프라에서 상대적으로 작은 부분이며 한 자리 또는 낮은 두 자리 비율입니다. 

그러나 분명히 새로운 표준이 될 것입니다. 가상화 채택이 처음에는 매우 느렸고 사람들은 그것이 과잉이라고 말했지만 물론 시간이 지남에 따라 대부분의 것을 대체하기 시작했습니다. 여기에서도 마찬가지입니다. 또는 현대 언어와 마찬가지로. 사람들은 Java가 과도하다고 말했고 아마도 여전히 많은 애플리케이션을 위한 것일 것입니다. 하지만 대부분의 애플리케이션 개발자가 작성할 수 있는 것이기 때문에 Java 외부에서 애플리케이션 개발을 수행하는 것이 매우 어려워지는 시간이 있었습니다. 마찬가지일 것입니다. 현대 애플리케이션 팀의 경우에도 마찬가지입니다. 그들은 더 민첩하게 개발하고 제품을 시장에 빨리 출시하기 위해 Kubernetes를 사용할 것으로 기대합니다.

인프라 측면에서는 약간 과도할 수 있지만 대안이 서버리스에서 온프레미스로 애플리케이션을 다시 작성하는 것이라면 이는 엄청난 작업입니다. 따라서 Kubernetes는 매우 매력적인 중간 지점입니다. 

Kubernetes에 여전히 더 나은 개발자 경험이 필요하다는 생각은 어떻습니까?

Kubernetes를 기반으로 하기 전의 원래 OpenShift를 보면 이렇습니다. 애플리케이션 팀과 더 가까웠고 훨씬 더 나은 애플리케이션 개발자 경험이었습니다. Git에 푸시하면 자동으로 배포됩니다. Heroku도 이것을 시도했지만 SaaS 기반입니다. 

쿠버네티스는 한 걸음 물러서면서 “몇 가지 운영 측면을 유지하고 시스템 관리자가 기대하는 것에 조금 더 가깝게 만들어야 합니다. 우리는 애플리케이션에만 맞출 수 없습니다.” 중간 지점: 애플리케이션 팀에게 충분한 매력이 있어야 하지만 특정 환경 외부에서 해당 앱을 실행할 수 있어야 하고 애플리케이션 개발자가 아닌 다른 사람이 관리할 수 있어야 합니다.

Docker와 Kubernetes 사이의 가장 큰 단계는 Docker가 개발자 경험에 관한 것이었습니다. 그 부분은 해결했지만 퍼블릭 클라우드 생태계 부분은 해결하지 못했다.

우리가 어떻게 이 지경에 이르렀습니까? 이것이 PaaS(Platform-as-a-Service) 및 애플리케이션 컨테이너에서 자연스러운 진화였습니까?

Docker 이미지와 Docker의 패키징 측면이었습니다. 오래된 학교는 가상 머신에 배포하는 방법이었고 주변에는 모든 종류의 자동화가 있었습니다. 그리고 Facebook이 Tupperware를 사용하여 수행한 작업이 있었습니다. 매우 맞춤 제작된 대규모 규모였습니다. 그리고 Docker가 등장하여 기본적으로 이 컨테이너 이미지를 제공했으며 모든 사람이 이를 미니어처 VM처럼 취급할 수 있었습니다. 이제 앱을 배포할 수 있으며 600MB 가상 이미지 대신 10MB 컨테이너가 되었습니다. 그러나 당신은 그것을 똑같이 취급할 수 있습니다. 그것은 필요한 모든 것을 갖추고 있습니다. 

이를 통해 애플리케이션을 미니 VM처럼 취급할 수 있는 Kubernetes와 같은 오케스트레이터를 도입할 수 있는 기능이 해제되었지만 한 단계 더 나아가 실제로 이를 마이크로서비스로 취급할 수 있습니다. 두 가지 모두를 수행할 수 있습니다.

Docker와 Kubernetes 사이의 가장 큰 단계는 Docker가 개발자 경험에 관한 것이었습니다. 그 부분은 해결했지만 퍼블릭 클라우드 생태계 부분은 해결하지 못했다. 클라우드 제공업체와의 긴밀한 통합이 없었거나 반드시 필요했습니다. Kubernetes가 이를 해결했습니다. 

회사 내에서 누가 Kubernetes를 실행하고 있다고 보십니까? 개별 지원팀인가요?

클라우드 네이티브에서 일어난 흥미로운 변화가 있습니다. 바로 "플랫폼 팀"이 부상했다는 것입니다. 그들은 애플리케이션 엔지니어가 아닙니다. 그들은 약간의 네트워크 운영 지식과 상당한 보안 지식을 가지고 있습니다. 그들은 SRE 지식을 가지고 있으며 클라우드 자동화를 수행하는 방법을 알고 있습니다. 그들은 애플리케이션 팀을 위한 플랫폼을 제공하고 해당 애플리케이션 팀을 고객으로 대하고 있습니다.

플랫폼 팀은 최신 앱 팀을 행복하게 만들기 위해 차세대 인프라를 제공해야 하기 때문에 사용하는 Kubernetes 및 관련 기술을 구매하는 팀입니다.

특히 매우 빠른 애플리케이션 개발을 위해 서버리스를 위한 공간이 분명히 있다고 생각합니다. 그러나 기업에서는 클라우드 네이티브를 가상화 위에 새로운 계층으로 보고 있습니다.

그것은 순 신규 구매자입니까, 아니면 순 신규 팀입니까? 아니면 플랫폼 팀이 Google이나 Facebook과 같은 내부에 존재하고 현재 주류가 되고 있는 것과 같은 것입니까?

그들은 대부분 새로운 팀입니다. 나는 그들이 Google과 Facebook의 SRE 팀과 어느 정도 비슷하다고 생각합니다. 그러나 기업에서는 Google 및 Facebook과 같은 SRE와 소프트웨어 엔지니어 간의 명확한 구분이 없기 때문에 애플리케이션 팀은 기업에서 더 많은 앱 배포를 소유할 수 있습니다. 저는 이 진화가 가상화 팀이 있었던 방식과 매우 유사하다고 말하고 싶습니다. 그런 다음 많은 네트워크 작업이 네트워크에서 마이그레이션되거나 발전되거나 발전했습니다. 하드웨어 네트워크에 대해 가상화. 예를 들어 이러한 팀은 VMware NSX를 운영하기 시작했습니다. 여기에서도 같은 일이 일어나고 있습니다. 

그러나 반드시 새로운 예산은 아닙니다. 예를 들어, 클라우드 지출이 증가하고 네트워크 하드웨어에 대한 지출이 줄어들면서 예산이 보안 및 네트워킹에서 이 플랫폼 팀으로 이동하는 것을 봅니다. 그들은 종종 동의를 얻기 위해 보안 팀 및 네트워크 운영 팀과 협력하지만 실제로는 상당한 규모의 예산을 소유하고 있습니다.

당신은 어떻게 봅니까 클라우드 네이티브 컴퓨팅 재단 Kubernetes는 항상 그 중심에 있을 것입니까? 아니면 전반적으로 클라우드 네이티브 운동의 중심에 있을 것입니까?

Kubernetes는 CNCF를 촉발시켰고 처음 몇 년 동안은 Kubernetes와 퍼블릭 클라우드에 관한 모든 것이었습니다. 약 XNUMX년 전 이후로 우리가 본 것은 이제 더 이상 Kubernetes에 관한 것이 아니라 실제로 클라우드 네이티브에 관한 것입니다. 원칙. 이것은 실제로 더 이상 반드시 클라우드가 아니며 사설 클라우드도 아님을 의미합니다. 종종 전통적인 엔터프라이즈 네트워킹, 지루한 온프레미스 인프라, 베어메탈 서버 등이 있지만 클라우드 기본 원칙이 내장되어 있습니다. 

새로운 표준은 이제 하이브리드이며 여러 퍼블릭 클라우드 제공업체와 온프레미스 인프라를 포함합니다. 기업은 동일한 애플리케이션 개발자 민첩성을 제공하거나 최신 클라우드 기본 도구를 사용하여 관찰 가능성을 제공하거나 최신 클라우드 기본 도구(예: 세분화 또는 ID 기반 시행 대신 인증)로 보안을 수행하기를 원합니다. 기존 인프라. 

우리는 여전히 구세계에 연결하고 MPLS, VLAN, sFlow 및 NetFlow(기존의 기업 요구 사항의 전체 집합)에 대해 이야기하려는 매우 강력한 요구를 보고 있습니다. 그들 중 누구도 떠나지 않았습니다.

약 XNUMX년이 지난 지금, 클라우드 네이티브 공간은 유행이 아닌 것 같습니다. 계속 발전할 여지가 얼마나 있습니까?

"오, 쿠버네티스는 아마 수명이 짧고 서버리스는 다음 계층이 될 것입니다."와 같은 시간이 분명히 있었습니다. 또는 “Kubernetes는 OpenStack과 유사합니다. 또는 "그것은 사라지고 구현 세부 사항이 될 것입니다." 그리고 그런 일은 일어나지 않았습니다. 

특히 매우 빠른 애플리케이션 개발을 위해 서버리스를 위한 공간이 분명히 있다고 생각합니다. 그러나 기업에서는 클라우드 네이티브를 가상화의 상위 계층으로 보고 있으며 가상화와 유사한 수명을 갖고 있다고 생각합니다. 이는 우리가 클라우드 네이티브 마이그레이션의 시작 단계에 있음을 의미합니다.

인프라 수준에서 아직 해결해야 할 큰 문제는 무엇입니까?

우리는 원하든 원하지 않든 갑자기 멀티 클라우드 전략이 필요한 상황에 처한 기업을 보고 있습니다. 또한 온프레미스 인프라가 있기 때문에 이제 그 위에 하이브리드 클라우드 전략이 필요합니다. 그리고 특정 퍼블릭 클라우드에 갇히지 않고 이 인프라 전반에서 보안 및 기타 기능을 보편적으로 수행하는 방법을 파악해야 합니다. 

이것이 다음 큰 과제입니다. 누가 VMware가 된 것처럼 멀티 클라우드 및 클라우드 네이티브를 위한 불가지론적 계층이 될 것입니까? 누가 클라우드 네이티브용 VMware가 될 것입니까?

최신 애플리케이션 팀을 유치하고 시장 출시 시간을 단축하려면 클라우드 네이티브 인프라를 제공해야 한다는 깨달음이 시작되었다고 생각합니다.

그리고 클라우드 네이티브 채택이 얼리 어답터였던 현대 웹 회사에게는 비교적 쉬웠을 수도 있지만 귀하의 관점에서 볼 때 도전 과제는 이 현대 세계와 기존 엔터프라이즈 도구 및 시스템 사이의 격차를 해소하는 새로운 기술을 구축하는 것입니까?

어려운 부분은 현대 앱 팀이 인프라 계층을 빠르게 발전시키는 데 익숙하다는 것입니다. 그리고 이로 인해 인프라 계층이 훨씬 더 프로그래밍 가능하고 조정 가능해야 했습니다. 그렇기 때문에 실제로 클라우드 네트워킹 계층 위에 네트워킹 계층과 보안 계층이 있는 것입니다. 그러나 이제 기업이 들어오고 있으며 여전히 기존 기업 요구 사항의 전체 집합인 MPLS, VLAN, sFlow 및 NetFlow에 대해 기존 세계에 연결하고 대화하려는 매우 강력한 수요를 보고 있습니다. 그들 중 누구도 사라지지 않았으며 모든 규정 준수 규칙은 여전히 ​​​​동일합니다. 그리고 일부 현대 SaaS 기업도 이제 규모가 커지고 규정 준수에 관심을 갖게 되면서 이러한 문제에 직면하게 되었습니다. 등등. 

기술적인 관점에서 볼 때 새로운 클라우드 네이티브 세계를 기존 엔터프라이즈 요구 사항에 연결하는 방법에 관한 것입니다. 이러한 문제의 대부분은 퍼블릭 클라우드 제공업체에 의해 숨겨져 있기 때문입니다. 퍼블릭 클라우드 제공업체는 규정 준수 문제를 해결했지만 소스를 공개하거나 게시하지 않았습니다. 그들은 그것을 스스로 해결했습니다. 클라우드 가치의 일부입니다. 이제 기업은 퍼블릭 클라우드 제품에 종속되지 않으려면 이를 다시 구축하고 구매해야 합니다.

클라우드 네이티브 혁신의 다음 물결은 어디에서 올 것이라고 보십니까? 여전히 Google과 같은 회사에서 제공합니까, 아니면 새로운 유형의 회사가 이를 주도하고 있습니까?

이것은 매우 흥미 롭다. 나는 그것이 아마도 구글과 페이스북에서 오지 않을 것이라고 말하고 싶다. 혁신의 원천은 오픈 소스가 될 것이며, 수요를 주도하는 고객과 사용자는 하이퍼스케일러보다 한 단계 아래인 회사가 될 것입니다. Adobe, Shopify 또는 GitHub와 같이 여전히 매우 파괴적인 이미 상당한 규모의 회사입니다. 그러나 금융 서비스, 보험 제공업체, 통신 회사와 같이 기술로 인해 혼란에 빠질 위험이 있는 회사도 있습니다. 이 회사들은 모두 반복 가능한 개발 및 인프라 모델로 인프라를 표준화하는 데 공통된 관심을 가지고 있습니다.

게시일: 26년 2022월 XNUMX일