Kubernetes, Ağ İletişimi ve Cloud Native'in VMware'ini Bulma

Thomas Graf, kurucu ortağı ve CTO'sudur. izovalentve popüler bir açık kaynak (ve bulut yerel) ağ teknolojisinin yaratıcısı kirpik. Cilium, çekirdek düzeyinde bir Linux teknolojisi üzerine inşa edilmiştir. eGMP.

Bu röportajda Graf, Cilium ve eBPF'nin büyüyen bulut yerel ağ ekosisteminde oynadığı rollerin yanı sıra Kubernetes'in benimsenmesi ve evrimiyle ilgili bazı daha geniş trendleri tartışıyor. Büyük kuruluşlarda Kubernetes'i kimlerin kullandığını ve satın aldığını, bulut tabanlı altyapının hâlâ iyileştirilmesi gerektiğini ve standartlaştırma arzusunun yeniliğe nasıl yön verdiğini açıklıyor.

---

GELECEK: eBPF ve Cilium hakkında genel olarak bilgi işlem ve ağ oluşturma bağlamında ve daha sonra özel olarak da bilgisayar ağı bağlamında nasıl düşünmeliyiz? bulut yerel ekosistemi?

- Thomas GRAF: Genel olarak, eBPF teknolojidir ve son derece düşük seviyelidir. Çekirdek geliştiricileri için tasarlandı ve geçmişim çekirdek geliştirme üzerine. Tarayıcı için JavaScript ne ise, eBPF de çekirdek ve işletim sistemi için odur. Tıpkı JavaScript'in tarayıcıyı programlanabilir hale getirmesi gibi, işletim sistemini de programlanabilir hale getirir. Geçmişte, belirli web sitelerini gerçekten kullanabilmek için tarayıcı sürümlerimizi yükseltmek zorunda kalıyorduk. Sonra JavaScript geldi ve birdenbire uygulama ekipleri ve geliştiriciler çok büyük uygulamalar geliştirebildiler; öyle ki, en popüler kelime işlemci uygulamasının yerini tarayıcı içi bir uygulama aldı. Büyük bir yenilik dalgasına yol açtı. 

Aynı şey eBPF'de de oluyor, işletim sistemi düzeyinde de olsa, çünkü birdenbire çekirdek veya işletim sistemi düzeyinde, her şeyi gördüğümüz ve her şeyi kontrol ettiğimiz - güvenlik açısından çok önemli olan - çekirdeği değiştirmeye gerek kalmadan şeyler yapabiliyoruz. kaynak kodu. İşlevselliğini genişletmek ve beraberinde yeni yetenekler getirmek için esas olarak çekirdeğe programlar yükleyebiliriz. Bu aynı zamanda büyük bir inovasyon dalgasının da önünü açtı. Facebook, Google ve Netflix gibi hiper ölçekleyiciler bunu kendi başlarına, doğrudan kendi çekirdek ekipleriyle kullanıyor. 

Cilium'un masaya getirdiği şey, bu düşük seviyeli eBPF teknolojisini, özellikle bulut yerel dalga için esasen yeni bir yazılım altyapısı dalgası sağlamak için kullanmasıdır. Bunu yazılım tanımlı ağ oluşturma ve VMware NSX haline gelen Nicira'nın sanallaştırma endüstrisi için yaptıkları gibi düşünün. Aynısını, bulut sağlayıcısı veya genel bulut altyapısının yanı sıra şirket içi altyapının bir karışımı olan yerel bulut için de yapıyoruz. Ayrıca ağ oluşturma, güvenlik ve gözlemlenebilirlik kullanım örneklerini altyapı katmanında çözüyoruz.

Peki yeni piyasaya sürülen Cilium Service Mesh bu yeteneklerin bir evrimi mi?

Yaklaşık bir yıl öncesinden beri şu anda olan şey, iki uzayın çarpışmasıdır. Cilium'un şu ana kadar yaptığı şey ağ oluşturmaya, sanallaştırılmış ağ oluşturmaya ve ardından bulut yerel ağ oluşturmaya odaklanmıştır - ancak yine de ağ oluşturmaya devam etmektedir. Ancak daha sonra, yukarıdan aşağıya gelindiğinde, Twitter ve Google'daki uygulama ekipleri, hizmet ağı şeyler - önce uygulamada, sonra sepet tabanlı modelde, proxy tabanlı modelde, projelerin neye benzediği Istio teslim etmek. Ve şimdi bu iki katman birbirine yaklaşıyor çünkü geleneksel işletmeler bulut yerel dünyasına geliyor ve kurumsal ağ gereksinimleri var, ancak uygulama ekipleri de bir hizmet ağı istiyor. 

Gartner bu yeni katmanı "hizmet bağlantısı" olarak adlandırıyor - bu terimin tutulup tutulamayacağını göreceğiz - ancak bu, esasen kurumsal ağ oluşturma parçasını ve uygulama ekiplerinden gelen hizmet ağ parçasını içeren bir katmandır. Ve müşterilerin talep ettiği şey bu olduğundan, yetenekleri Cilium'un kendisine ekledik. Yani, esasen, Cilium kurumsal ağ oluşturma tarafında yukarı doğru gidiyor ve hizmet ağları daha çok ağ oluşturma tarafında aşağıya doğru gidiyor.

Kubernetes yığınının ağ oluşturma ve hizmet ağı düzeyine neden bu kadar odaklanılıyor?

Çünkü birden fazla bulutta çalışma ve uygulamaları konteynerlere bölme isteği nedeniyle bağlantı katmanı merkezi hale geldi. Eskiden belki de süreçler arası iletişim ve ara katman yazılımı olan şey artık ağ haline geldi; dolayısıyla ağ, uygulamaların birbirleriyle konuşması ve veri akışı için kesinlikle gerekli hale geliyor. 

Ve özellikle bulut yerelinde, Çoklu bulut kesinlikle gerekli hale geliyor. Tüm bulut sağlayıcılarının kendi ağ katmanları vardır, ancak elbette kendi bulutlarına göre uyarlanmıştır. Şirket içi teklifleri var ancak gerçek anlamda çoklu bulut değiller. Cilium ve eBPF, çoklu bulut, agnostik katmanı masaya getiriyor. Genel bulutta olduğu gibi şirket içinde de tamamen aynı şekilde davranır. Genel bulut sağlayıcılarının birçoğu, yönetilen Kubernetes teklifleri için Cilium'u kullanıyor ve telekom şirketleri bunu şirket içi 5G altyapısı için kullanıyor. Bu, her iki dili de konuşmak ve bu dünyaları birbirine bağlamakla ilgilidir.

Bu yüzden buna bu kadar çok odaklanılıyor: Çünkü bulut sağlayıcılarının müşterileri kendine bağlamasının en kolay yollarından biri bu bağlantı katmanına sahip olmaktır. Stratejik altyapı perspektifinden bakıldığında, tıpkı sanallaştırma katmanının önemli olduğu gibi, artık bağlantı ve ağ katmanının da kesinlikle önemli olduğunu düşünüyorum.

[Geleceğin] inovasyonunun kaynağı açık kaynak olacak ve talebi yönlendiren müşteriler ve kullanıcılar, hiper ölçekleyicilerin bir seviye altındaki şirketler olacak; halihazırda oldukça büyük olan ve hâlâ son derece yıkıcı olan şirketler.

Kubernetes bu noktada oldukça geniş çapta kabul görüyor ve benimseniyor, ancak bazı çevrelerde hala bunun fazla abartıldığı konuşuluyor. Sizce Kubernetes ve genel olarak bulut yerel ekosistemi kimin içindir?

Modern uygulama ekipleri içindir. Modern uygulama ekiplerinin ilgisini çekmek ve pazara hızlı giriş süreleri elde etmek istiyorsanız, onlara bulut tabanlı altyapı sağlamanız gerektiğinin farkına varıldığını düşünüyorum. Lambda gibi sunucusuz platformlarda sıklıkla prototip oluşturma (başlangıç, MVP öncesi, hatta konseptin kanıtlanması veya şirket içinde satış) görüyoruz. Ve sonra Kubernetes'te çünkü uygulama ekipleri altyapının doğrudan sahibi olabiliyor. Daha sonra, üretime geçtikçe kurumsal, şirket içi Kubernetes dağıtımlarına geçiyorlar. Ancak bu aslında tüm altyapının nispeten küçük bir kısmı, belki de tek veya düşük çift haneli bir yüzde. 

Ancak bunun yeni standart olacağı açık. Tıpkı sanallaştırmanın benimsenmesinin başlangıçta çok yavaş olması ve insanların bunun aşırı olduğunu söylemesi gibi - ancak zamanla elbette çoğu şeyin yerini almaya başladı - burada da aynısını göreceğiz. Veya tıpkı modern dillerde olduğu gibi. İnsanlar Java'nın aşırıya kaçtığını söylüyordu ve muhtemelen birçok uygulama için de öyledir, ancak Java dışında herhangi bir uygulama geliştirmenin çok zorlaştığı bir dönem vardı çünkü uygulama geliştiricilerin çoğunluğu bunu yazabiliyordu. Modern uygulama ekipleri için de geçerli: Daha çevik bir ürün geliştirmek ve ürünü hızla pazara sunmak için Kubernetes'in ortalıkta olmasını bekleyecekler.

Altyapı tarafında bu biraz abartı olabilir, ancak alternatif bir uygulamayı sunucusuzdan şirket içi olarak yeniden yazmaksa, bu çok büyük bir görevdir. Yani Kubernetes buranın orta noktasıdır ve bu çok çekicidir. 

Peki Kubernetes'in hâlâ daha iyi bir geliştirici deneyimine ihtiyacı olduğu fikrine ne dersiniz?

Orijinal OpenShift'e Kubernetes'e yeniden dayanmadan önce bakarsak, durum buydu. Uygulama ekibine daha da yakındı ve daha da iyi bir uygulama geliştirici deneyimiydi. Git'e basabilirsiniz ve otomatik olarak dağıtılır. Heroku da bunu denedi ancak SaaS tabanlı. 

Kubernetes bir adım geri giderek şöyle dedi: "Bazı operasyonel yönleri burada tutmamız ve onu bir sistem yöneticisinin bekleyebileceğine biraz daha yakın hale getirmemiz gerekiyor. Sadece uygulamalara göre uyarlanamayız.” Orta yol: Uygulama ekipleri için yeterince çekici olması gerekiyor, ancak yine de uygulamayı belirli bir ortamın dışında çalıştırmanın ve uygulama geliştiricileri dışındaki kişiler tarafından yönetilmesinin mümkün olması gerekiyor.

Docker ile Kubernetes arasındaki en büyük adımın Docker'ın tamamen geliştirici deneyimine yönelik olması olduğunu söyleyebilirim. Bu kısmı çözdü ancak genel bulut ekosistemi kısmını çözmedi.

Bu noktaya nasıl geldik? Bu, hizmet olarak platform (PaaS) ve uygulama kapsayıcılarının doğal gelişimi miydi?

Docker görselleri ve Docker'ın paketleme yönüydü. Eski usul, sanal makinelere nasıl dağıtılacağıyla ilgiliydi ve bunun etrafında her türlü otomasyon vardı. Ve bir de Facebook'un Tupperware ile yaptığı şey vardı; çok özel yapım ve gerçekten büyük ölçekli. Daha sonra Docker ortaya çıktı ve aslında bu konteyner görüntüsünü sağladı ve herkes buna minyatür bir sanal makine gibi davranabildi. Artık uygulamamı dağıtabiliyorum ve 600 MB'lık bir sanal görüntü yerine artık 10 MB'lık bir kapsayıcı haline geldi. Ama ona aynı şekilde davranabilirsiniz, ihtiyacı olan her şeye sahiptir. 

Bu, Kubernetes gibi bir orkestratör getirme yeteneğinin kilidini açtı; bu, hâlâ mini VM'ler gibi uygulamaları işlemenize izin veriyor, ancak aynı zamanda bir adım daha ileri giderek bunları gerçekten mikro hizmetler olarak ele alıyor. Her ikisini de yapmanıza olanak sağlar.

Docker ile Kubernetes arasındaki en büyük adımın Docker'ın tamamen geliştirici deneyimine yönelik olması olduğunu söyleyebilirim. Bu kısmı çözdü ancak genel bulut ekosistemi kısmını çözmedi. Bulut sağlayıcılarıyla yakın bir entegrasyonu yoktu veya zorunlu olarak böyle olmasını istemiyordu. Kubernetes bunu çözdü. 

Şirketlerde Kubernetes'i kimin çalıştırdığını görüyorsunuz? Bireysel başvuru ekipleri mi?

Bulut yerlisinde ilginç bir değişim yaşandı; ben buna "platform ekibi" diyeceğim yükselişe geçtik. Onlar uygulama mühendisi değiller. Biraz ağ operasyonları bilgisine sahipler ve oldukça fazla güvenlik bilgisine sahipler. SRE bilgisine sahipler ve bulut otomasyonunun nasıl yapılacağını biliyorlar. Uygulama ekipleri için platform sağlıyorlar ve bu uygulama ekiplerine müşterileri gibi davranıyorlar.

Platform ekipleri, modern uygulama ekiplerini mutlu edecek yeni nesil altyapıyı sağlamakla görevlendirildikleri için kullandıkları Kubernetes'i ve ilgili teknolojileri satın alan ekiplerdir.

Sunucusuz ortamlar için, özellikle de çok hızlı uygulama geliştirme için kesinlikle bir alan olduğunu düşünüyorum. Ancak işletmelerde bulut yerelini sanallaştırmanın üzerindeki yeni katman olarak görüyoruz

Bu net olarak yeni bir alıcı mı yoksa net olarak yeni bir ekip mi? Yoksa platform ekipleri Google veya Facebook gibi yerlerde var olan ve artık ana akım haline gelen bir şey mi?

Çoğunlukla yeni bir takım bunlar. Bir dereceye kadar Google ve Facebook'taki SRE ekiplerine benzediklerini düşünüyorum. Ancak uygulama ekipleri muhtemelen kuruluşlardaki uygulama dağıtımının daha fazlasına sahiptir, çünkü kuruluşlarda yazılım mühendisleri ile Google ve Facebook gibi SRE'ler arasında çok net bir ayrım yoktur. Bu evrimin, sanallaştırma ekiplerinizin nasıl olduğuna çok benzediğini ve ardından birçok ağ operasyonunun ağla ilgili olmaktan taşındığını veya geliştiğini veya ilerlediğini söyleyebilirim. donanım ağla ilgili olmak sanallaştırma. Ve bu ekipler örneğin VMware NSX'i çalıştırmaya başladı. Aynı şey burada da oluyor. 

Ancak bu mutlaka yeni bir bütçe değildir. Örneğin bulut harcamaları arttıkça ve ağ donanımına daha az harcandıkça bütçelerin güvenlik ve ağ oluşturmadan bu platform ekibine kaydığını görüyoruz. Destek almak için genellikle güvenlik ekibi ve ağ operasyonları ekibiyle birlikte çalışırlar, ancak aslında oldukça önemli bir bütçeye sahiptirler.

nasıl görüyorsun Bulut Yerel Bilgi İşlem Vakfı Gelişiyor ve Kubernetes her zaman bunun merkezinde mi olacak, yoksa genel olarak bulut tabanlı hareketin merkezinde mi?

CNCF'yi ateşleyen şey Kubernetes'ti ve ilk birkaç yılda her şey Kubernetes ve genel bulutla ilgiliydi. Yaklaşık bir yıl öncesinden bu yana gördüğümüz şey artık bunun yalnızca Kubernetes ile ilgili olmadığı, aslında daha çok bulut yereliyle ilgili olduğu. ilkeler. Bu aslında artık bulut olmadığı, özel bulut bile olmadığı anlamına geliyor. Hatta çoğu zaman geleneksel kurumsal ağ iletişimi, sıkıcı şirket içi altyapı, yalın donanım sunucular ve tüm bunlar, ancak yerleşik bulut yerel ilkeleriyle sağlanır. 

Yeni norm artık hibrittir ve şirket içi altyapının yanı sıra birden fazla genel bulut sağlayıcısını da içermektedir. Şirketler, aynı uygulama geliştirici çevikliğini sağlamak veya modern bulut yerel araçlarıyla gözlemlenebilirlik sağlamak veya güvenliği modern bulut yerel araçlarıyla (örneğin, yalnızca segmentasyon veya kimlik tabanlı uygulama yerine kimlik doğrulama) sağlamak istiyor; tüm bu yeni bulut yerel kavramları mevcut altyapı. 

Eski dünyaya bağlanmaya ve mevcut tüm kurumsal gereksinimler kümesi olan MPLS, VLAN, sFlow ve NetFlow hakkında konuşmaya devam etmeye yönelik çok güçlü bir talep görüyoruz. Hiçbiri gitmedi.

Yaklaşık on yıl sonra, bulut yerel alanı bir moda gibi görünmüyor. Gelişmeye devam etmesi için ne kadar yer var?

Kesinlikle şunun söylendiği bir dönem vardı: "Ah, Kubernetes muhtemelen kısa ömürlüdür ve bir sonraki katman sunucusuz olacak." Veya “Kubernetes, OpenStack'e benzer. Veya “Ortadan kaybolacak ve bir uygulama detayı olacak.” Ve bu gerçekleşmedi. 

Sunucusuz ortamlar için, özellikle de çok hızlı uygulama geliştirme için kesinlikle bir alan olduğunu düşünüyorum. Ancak işletmelerde bulut yerelini sanallaştırmanın üzerindeki yeni katman olarak görüyoruz ve sanallaştırmayla benzer bir raf ömrüne sahip olduğuna inanıyoruz. Bu da buluta yerel geçişin en başında olduğumuz anlamına geliyor.

Altyapı düzeyinde hâlâ hangi büyük sorunların çözülmesi gerekiyor?

İşletmelerin isteseler de istemeseler de birdenbire çoklu bulut stratejisine ihtiyaç duydukları bir durumda olduklarını görüyoruz. Ayrıca şirket içi altyapıya sahip oldukları için artık bunun üzerine bir hibrit bulut stratejisine de ihtiyaçları var. Ve kendilerini belirli bir genel buluta kilitlemeden, bu altyapıda güvenlik ve diğer işlevleri evrensel olarak nasıl gerçekleştireceklerini bulmaları gerekiyor. 

İşte bir sonraki büyük zorluk şu: VMware'in dönüştüğü gibi, çoklu bulut ve bulut yereline yönelik agnostik katman kim olacak? Bulut yerel için VMware kim olacak?

Modern uygulama ekiplerinin ilgisini çekmek ve pazara hızlı giriş süreleri elde etmek istiyorsanız, onlara bulut tabanlı altyapı sağlamanız gerektiğinin farkına varıldığını düşünüyorum.

Her ne kadar bulut yerelliğini benimsemek, ilk benimseyen modern web şirketleri için nispeten kolay olsa da, sizin bakış açınıza göre zorluk, bu modern dünya ile mevcut kurumsal araçlar ve sistemler arasındaki boşluğu dolduracak yeni teknolojiler oluşturmak mı?

İşin zor kısmı, modern uygulama ekiplerinin altyapı katmanının kendileri kadar hızlı gelişmesine alışkın olmasıdır. Bu da altyapı katmanını daha programlanabilir, daha ayarlanabilir olmaya zorladı. Bu nedenle aslında bulut ağ katmanının üstünde bir ağ katmanı ve bir güvenlik katmanı görüyoruz. Ancak artık girişimlerimiz geliyor ve eski dünyaya bağlanmak ve MPLS, VLAN, sFlow ve NetFlow (tüm mevcut kurumsal gereksinimler kümesi) hakkında konuşmak için hala çok güçlü bir talep görüyoruz. Hiçbiri ortadan kalkmadı, tüm uyum kuralları hala aynı. Ve Modern SaaS şirketlerinden bazıları bile artık büyüdükçe bu zorluklarla karşı karşıya kalıyor ve uyumluluğu önemsiyorlar ve benzerleri. 

Teknoloji açısından bakıldığında bu, yeni bulut yerel dünyasının mevcut kurumsal gereksinimlere nasıl bağlanacağıyla ilgilidir. Çünkü bu sorunların çoğu genel bulut sağlayıcıları tarafından gizleniyordu. Genel bulut sağlayıcıları uyumluluk sorunlarını çözdüler ancak bunların hiçbirini açık kaynak haline getirmediler veya yayınlamadılar; bunu kendi başlarına çözdüler. Bu, bulut değerinin bir parçasıdır. Şirketlerin artık kendilerini genel bulut tekliflerine kilitlemek istemiyorlarsa bunu yeniden inşa etmeleri ve satın almaları gerekiyor.

Bulut tabanlı inovasyonun bir sonraki dalgasının nereden geleceğini görüyorsunuz? Bu hâlâ Google gibi bir şirketten mi geliyor, yoksa sorumluluğu üstlenen yeni türde bir şirket mi var?

Bu çok ilginç. Muhtemelen Google'lardan ve Facebook'lardan gelmediğini söyleyebilirim. İnovasyonun kaynağı açık kaynak olacak ve talebi yönlendiren müşteriler ve kullanıcılar, hiper ölçekleyicilerin bir seviye altındaki şirketler olacak; Adobe, Shopify veya GitHub gibi halihazırda oldukça büyük ve hâlâ son derece yıkıcı olan şirketler. Ancak aynı zamanda finansal hizmetler, sigorta sağlayıcıları ve telekomünikasyon şirketleri gibi teknolojiden etkilenme riskiyle karşı karşıya olan şirketler de var. Bu şirketlerin hepsinin, tekrarlanabilir geliştirme ve altyapı modelleri ile altyapıyı standartlaştırma konusunda ortak çıkarları var.

26 Temmuz 2022'da yayınlandı