Bir VPN sidecar'ı başlatma kuralı ve hata kuralı gerektirir

Bir pod, tünel kapsayıcısını uygulamadan önce başlatır ve ilk istekler başarılı olur; sorunu gizleyen durum tam olarak budur. Sıralama bir yarışı düzeltir ve tünel arızalandıktan dört saat sonra uygulamanın başlattığı trafik hakkında hiçbir şey söylemez. Bunlar iki ayrı karardır. Genellikle yalnızca biri tasarlanır.

Sıralama yalnızca ilk isteği kapılar

Kubernetes, yeniden başlatılabilir init kapsayıcılarından oluşan bir sidecar yaşam döngüsünü destekler. Bu modelde bir başlangıç probu, tünel hazır olduğunu bildirene kadar sonraki başlatma adımını tutabilir. Bu gerçek bir iyileştirmedir ve giriş noktası betiğine sleep eklemek yerine bilinçli olarak kullanılmaya değer. Kapı, test ettiği koşul kadar iyidir.

Bu modelin dışında, sıralama semantiği kullandığınız çalışma zamanına veya bağımlılık sistemine aittir ve bunların eşleşmesi gerekmez. Başka bir platformdan kopyalanan bir dağıtım, uygulama tesadüfen yavaş başladığı için tüneli bekliyor gibi görünebilir. Bu aynı garanti değildir ve yük altında başarısız olur.

Kapının neyi gözlemlediğini söyleyin: bir süreç var, bir arayüz var, bir handshake tamamlandı. Bunların her biri “bu podun ihtiyaç duyduğu hedeflere giden veri yolu çalışıyor” iddiasından daha zayıftır.

Veri yolunu varsaymak yerine zorunlu kılın

Prob tek bir anda yapılan bir kontroldür ve güvenlik duvarı anlar arasında geçerli bir özelliktir. Gereksinim, uygulama trafiğinin tünelin dışına asla çıkmamasıysa, bu ortak ağ ad alanında kabul et-veya-düşür kuralı olarak ifade edilmelidir. Kapsayıcı başlatma sırası bu gereksinimi taşıyamaz. Yalnızca bir kural taşıyabilir.

Bir poddaki kapsayıcılar o ad alanını paylaşır, dolayısıyla uygulama noktası ad alanının kendisidir. Ne yazarsanız yazın, tünelin kendi dış bağlantısını kullanılabilir bırakmalıdır, çünkü uygulamayı korumak için onu engellemek uygulamanın ihtiyaç duyduğu yolu keser.

Hata politikasına açıkça karar verin: tünel sağlıklı olmadığında uygulama trafiği tamamen durmalı mı, yoksa devam edip korumasız olarak işaretlenmeli mi? İkisi de savunulabilir ve hiçbiri kapsayıcıları belirli bir sırayla başlatarak elde edilen şey değildir.

Bahsetmediğiniz trafiği test edin

Kontrollü bir tünel arızası sırasında yeni bir istek yapın ve dışarı çıkıp çıkmadığına bakın. Ardından çıkış adresi testinin asla dokunmadığı yollar için kontrolü tekrarlayın: küme içindeki DNS çözümlemesi, IPv6 hedefleri ve genel internet yerine küme içi adreslerle erişilen hizmetler. Tünel öldükten sonra sessizce çalışmaya devam eden yollar bunlardır.

Bir çıkış adresi sayfası, bir isteğin o anda beklediğiniz yere gittiğini kanıtlar. Diğer yolları envanterleyemez ve test ettiğiniz şey ile podun erişebildiği şey arasındaki boşluk, ilginç arızaların yaşadığı yerdir.

Testi yalnızca temiz bir başlatmadan sonra değil, sidecar yeniden başlatıldıktan sonra da tekrarlayın. Yeniden başlatılan bir tünel kapsayıcısı ad alanını rotalar ve politikayla ara durumda bırakabilir.

Dağıtım kaydını yazın

Dağıtım notlarına üç gerçek girer: hazırlık testi ve neyi gözlemlediği, o test başarısız olduğunda kurtarma eylemi ve giden trafiği yöneten uygulama kuralı. Sidecar kapsayıcı belgeleri yaşam döngüsü mekaniğini kapsar ve bu politika kararını size bırakır. Bu ayrım doğrudur ve politikanın genellikle eksik olmasının nedeni de budur.

Koruma sanılan bir sağlık kontrolü, en pahalı tür yeşil göstergedir, çünkü insanların soru sormasını durdurur. Belgede doğru adlandırmak bir cümleye mal olur ve bunu önler.

Son olarak, kurtarma yolunu uygulama çalışırken bir kez test edin. Giden trafiği geri getirmek için podun yeniden oluşturulmasını gerektiren bir tasarım bir karardır ve keşfettiğiniz değil, verdiğiniz bir karar olmalıdır.