Pod, düğüm veya küme: VPN sidecar gerçekte neyi yeniden yönlendirir

Kubernetes Pod'undaki bir VPN sidecar, daha iyi görgüye sahip ana makine düzeyinde bir VPN'e benzer ve benzerlik ad alanının sınırında biter. Bir Pod'daki konteynerler adres ve bağlantı noktası alanı da dahil olmak üzere ağ ad alanını paylaşır, bu nedenle rota ve ilke kuran bir sidecar, uygulamanın paketlerinin nereye gittiğini gerçekten değiştirir. Düğümdeki diğer Pod'lar için hiçbir şeyi değiştirmez ve siz bunu öyle yapılandırmadıkça düğümün kendi yığınına dokunmaz. Bu sınırı doğru anlamak, hem neleri dağıtabileceğinizi hem de neleri test etmeniz gerektiğini belirler. Aşağıdaki bölümler bunu ad alanından dışarı doğru izler.

Paylaşılan ad alanı, paylaşılan sonuçlar

Bir Pod'daki iki konteyner loopback üzerinden konuşur ve aynı arayüzleri görür, sidecar deseninin işlemesinin nedeni budur: uygulamanın bir tünel olduğunu bilmesine gerek yoktur, çünkü çözdüğü rota kullandığı ad alanına kurulmuştur. Aynı özellik, sidecar'ın hatalarının uygulamanın hataları olduğu anlamına gelir. Çok fazla yakalayan bir rota veya tünelin içindeki bir çözümleyiciye işaret eden DNS değişikliği, o Pod'daki her süreç için hemen geçerlidir. Paylaşılan bir ad alanında konteyner başına yönlendirme yoktur, bu nedenle bir sidecar tek bir süreçle sınırlandırılamaz.

İnceleme sırasında akılda tutulması gereken mekanizma budur: etki yarıçapı Pod'dur, düğüm değil ve küme değil.

Sidecar'ın ulaşamadığı yerler

Diğer Pod'lar kendi ad alanlarını ve kendi yönlendirmelerini korur, bu nedenle aynı çıkışa ihtiyaç duyan iş yükü aynı sidecar'a ya da bunun yerine düğüm düzeyinde bir tasarıma ihtiyaç duyar. Düğümün trafiği de Pod ad alanının dışındadır ve ana makine ağı kullanan Pod'lar bu yalıtımdan bilinçli olarak tamamen çekilir. Bir şeye kolayca ulaşmak için sidecar'ı ana makine ağıyla çalıştırırsanız, kapsamı bir Pod'dan tüm düğüme genişletmiş olursunuz ve bunu yüksek sesle söylemelisiniz.

Küme hizmetlerine giden trafik, diğer yaygın sürprizdir. Pod içindeki geniş bir varsayılan rota, API sunucusuna veya bir ClusterIP hizmetine yönelik istekleri yakalayabilir ve bunlar sonra tünel bozulmuş gibi görünen biçimlerde başarısız olur.

Rota planı: Pod, hizmet, düğüm ve VPN aralıkları

Dört aralığı yazın ve herhangi bir şey dağıtmadan önce çakışma olup olmadığını kontrol edin: Pod CIDR, hizmet CIDR, düğüm adresleri ve VPN'in arkasındaki hedefler. VPN'in özel aralıkları ile kümenin kendi alanı arasındaki çakışma nadir değildir ve varsayılan rota bunun için yanlış çözümdür. Rota planı manifestle aynı depoya aittir, çünkü bir sonraki küme tamamen farklı Pod ve hizmet aralıkları verebilir.

DNS planın bir parçasıdır, ayrı bir kaygı değildir. Çözümleyici yapılandırmasını yeniden yazan bir sidecar, dış sorgular kusursuz çalışırken küme içindeki hizmet keşfini bozabilir.

Başlatma ve arıza açık durumlardır

Çalışan bir sidecar süreci çıkış ilkesi değildir. Tünel hazır olmadan hangi trafiğin akabileceğine ve sonradan ölürse ne olacağına karar verin, sonra bu kararı uygulayın: uygulama konteynerini kapıda tutan bir yoklama, varsayılan olarak reddeden bir ağ ilkesi veya her ikisi. Bunlardan biri olmadan uygulama başlar, adları çözer ve tünel hâlâ bağlanırken trafiği düğümün normal yolunun dışına gönderir.

Bu boşluk sağlıklı bir kümede kısadır ve bozuk bir kümede kalıcıdır, ve bir saldırganın ya da kazara veri sızıntısının tercih ettiği özellik tam olarak budur.

Sıralamayı bir arıza testiyle eşleştirin. Sidecar'ı öldürün ve uygulamanın sessizce geri çekilmek yerine amaçlanan çıkışını kaybettiğini doğrulayın.

Yetenekler, ilkeler ve uygulama konteynerinden test

Arayüz oluşturmak ve rotaları değiştirmek için gereken yetenekleri vermek bir ayrıcalık kararıdır ve yalıtılmış bir Pod için uygun olan ayrıcalık, düğüm yığınında otomatik olarak uygun değildir. Kümenin desteklediği ağ ve güvenlik ilkesi mekanizmalarını kullanın ve her CNI veya ilke uygulamasının bir VPN arayüzüne aynı şekilde davrandığını varsaymayın; farklar tam olarak önemsediğiniz arıza durumlarında ortaya çıkar.

Gerçek uygulama konteynerinden test edin, özel bir hedefe, küme hizmetine ve genel internete yeni isteklerle. Sidecar'dan yapılan test tünelin çalıştığını kanıtlar, uygulamanın ihtiyacı olana ulaştığını değil.

Kümenin ağ varsayımlarını VPN yapılandırmasının yanında belgeleyin. İş yükünü başka bir kümeye taşımak o zaman sessizce çalışmayı bırakan bir imaj değişikliği değil, rota planını denetleme alıştırması olur.