Adım Dmitry Sugrobov, Leroy Merlin'de geliştiriciyim. Bu yazıda size Helm'e neden ihtiyaç duyulduğunu, Kubernetes ile çalışmayı nasıl kolaylaştırdığını, üçüncü versiyonda nelerin değiştiğini ve üretimdeki uygulamaları kesinti olmadan güncellemek için nasıl kullanılacağını anlatacağım.
Bu bir konferanstaki konuşmaya dayanan bir özettir by — Okumak istemiyorsanız videoyu izleyin.
Üretimde neden Kubernetes kullanıyoruz?
Leroy Merlin, Rusya ve Avrupa'da DIY perakende pazarında liderdir. Şirketimizin yüzden fazla geliştiricisi, 33 dahili çalışanı ve hipermarketleri ve web sitesini ziyaret eden çok sayıda kişi bulunmaktadır. Hepsini mutlu etmek için endüstri standardı yaklaşımları izlemeye karar verdik. Mikro hizmet mimarisini kullanarak yeni uygulamalar geliştirin; ortamları izole etmek ve uygun teslimatı sağlamak için kaplar kullanın; ve düzenleme için Kubernetes'i kullanın. Orkestratör kullanmanın fiyatı hızla ucuzluyor: Piyasada teknoloji konusunda yetkin mühendislerin sayısı artıyor ve Kubernetes'i bir hizmet olarak sunan sağlayıcılar ortaya çıkıyor.
Kubernetes'in yaptığı her şey elbette başka yollarla da yapılabilir, örneğin bazı Jenkins ve docker-compose komut dosyalarını kapsayarak, ancak hazır ve güvenilir bir çözüm varsa neden hayatı zorlaştırasınız ki? Bu yüzden Kubernetes'e geldik ve onu bir yıldır üretimde kullanıyoruz. Şu anda en eskisi bir yıldan daha eski olan ve yaklaşık iki yüz kapsül içeren yirmi dört Kubernetes kümesine sahibiz.
Kubernetes'te büyük YAML dosyalarının laneti
Kubernetes'te bir mikro hizmet başlatmak için en az beş YAML dosyası oluşturacağız: Dağıtım, Hizmet, Giriş, ConfigMap, Sırlar için ve bunları kümeye göndereceğiz. Bir sonraki uygulama için aynı söve paketini yazacağız, üçüncüsüne bir tane daha yazacağız vb. Belge sayısını ortam sayısıyla çarparsak zaten yüzlerce dosya elde ederiz ve bu henüz dinamik ortamları hesaba katmıyor.
Helm'in temel sorumlusu Adam Reese, "", şuna benziyor:
- YAML'yi kopyala - bir YAML dosyasını kopyalayın.
- YAML'yi yapıştırın - yapıştırın.
- Girintileri Düzelt - girintileri düzeltin.
- Tekrarla - tekrar tekrarlayın.
Bu seçenek çalışır ancak YAML dosyalarını birçok kez kopyalamanız gerekir. Bu döngüyü değiştirmek için Helm icat edildi.
Dümen Nedir?
İlk olarak, Helm - Paketleme yöneticisiİhtiyacınız olan programları bulmanıza ve yüklemenize yardımcı olur. Örneğin MongoDB'yi yüklemek için resmi web sitesine gitmenize ve ikili dosyaları indirmenize gerek yoktur, sadece komutu çalıştırmanız yeterlidir. helm install stable/mongodb.
İkincisi, Helm - şablon motoru, dosyaları parametreleştirmeye yardımcı olur. Kubernetes'teki YAML dosyalarının durumuna dönelim. Aynı YAML dosyasını yazmak, Helm'in değerleri değiştireceği bazı yer tutucular eklemek daha kolaydır. Yani, geniş bir iskele seti yerine, gerekli değerlerin doğru zamanda değiştirileceği bir dizi şablon olacaktır.
Üçüncüsü, Helm - dağıtım yöneticisi. Bununla birlikte uygulamaları yükleyebilir, geri alabilir ve güncelleyebilirsiniz. Bunu nasıl yapacağımızı bulalım.
Kendi uygulamalarınızı dağıtmak için Helm nasıl kullanılır?
Resmi talimatları takip ederek Helm istemcisini bilgisayarınıza yükleyelim. . Daha sonra bir dizi YAML dosyası oluşturacağız. Belirli değerler belirtmek yerine Helm'in gelecekte bilgilerle dolduracağı yer tutucuları bırakacağız. Bu tür dosyalardan oluşan bir diziye Helm grafiği adı verilir. Dümen konsolu istemcisine üç şekilde gönderilebilir:
- şablonların bulunduğu bir klasörü belirtin;
- arşivi bir .tar dosyasına paketleyin ve üzerine gelin;
- şablonu uzak bir depoya koyun ve Helm istemcisindeki depoya bir bağlantı ekleyin.
Ayrıca değerleri olan bir dosyaya da ihtiyacınız var -values.yaml. Oradan gelen veriler şablona eklenecektir. Onu da oluşturalım.
Helm'in ikinci versiyonunda ek bir sunucu uygulaması var - Tiller. Kubernetes'in dışında asılı kalır ve Helm istemcisinden gelen istekleri bekler ve çağrıldığında gerekli değerleri şablona yerleştirir ve Kubernetes'e gönderir.
Helm 3 daha basit: Sunucudaki şablonları işlemek yerine bilgiler artık tamamen Helm istemci tarafında işleniyor ve doğrudan Kubernetes API'sine gönderiliyor. Bu basitleştirme, küme güvenliğini artırır ve kullanıma sunma planını kolaylaştırır.
Her şey nasıl çalışıyor?
Komutu çalıştır helm install. Uygulama sürümünün adını belirtelim ve value.yaml yolunu verelim. Sonunda grafiğin bulunduğu depoyu ve grafiğin adını belirteceğiz. Örnekte bunlar sırasıyla “lmru” ve “bestchart”tır.
helm install --name bestapp --values values.yaml lmru/bestchart
Komut yalnızca bir kez çalıştırılabilir; bunun yerine tekrar çalıştırıldığında install kullanmam gerekiyor upgrade. Basit olması açısından iki komut yerine şu komutu çalıştırabilirsiniz: upgrade ek anahtarla --install. İlk kez çalıştırıldığında Helm, sürümü yüklemek için bir komut gönderecek ve onu gelecekte güncelleyecektir.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Bir uygulamanın yeni sürümlerini Helm ile dağıtmanın tuzakları
Hikayenin bu noktasında izleyicilerle Kim Milyoner Olmak İster oyununu oynuyorum ve Helm'in uygulamanın sürümünü güncellemesini nasıl sağlayacağımızı bulmaya çalışıyoruz. .
Helm'in nasıl çalıştığını öğrenirken, çalışan uygulamaların sürümlerini güncellemeye çalışırken karşılaştığım garip davranışlar beni şaşırttı. Uygulama kodunu güncelledim, Docker kayıt defterine yeni bir görüntü yükledim, dağıtım komutunu gönderdim ve hiçbir şey olmadı. Aşağıda uygulamaları güncellemenin tamamen başarılı olmayan bazı yolları verilmiştir. Her birini daha detaylı inceleyerek enstrümanın iç yapısını ve bu belirgin olmayan davranışın nedenlerini anlamaya başlayacaksınız.
Yöntem 1. Son başlatmadan bu yana bilgileri değiştirmeyin
Dediği gibi Helm, "Kubernetes grafikleri büyük ve karmaşık olabilir, bu nedenle Helm hiçbir şeye çok fazla dokunmamaya çalışıyor." Bu nedenle, docker kayıt defterindeki uygulama görüntüsünün en son sürümünü güncellerseniz ve komutu çalıştırırsanız helm upgrade, o zaman hiçbir şey olmayacak. Helm hiçbir şeyin değişmediğini ve uygulamayı güncellemek için Kubernetes'e komut göndermeye gerek olmadığını düşünecek.
Burada ve aşağıda en son etiket yalnızca örnek olarak gösterilmektedir. Bu etiketi belirttiğinizde Kubernetes, imagePullPolicy parametresinden bağımsız olarak her seferinde görüntüyü docker kayıt defterinden indirecektir. Üretimde en yenisinin kullanılması istenmeyen bir durumdur ve yan etkilere neden olur.
Yöntem 2. Görüntüdeki LABEL'i güncelleyin
Aynı şekilde yazıldığı gibi , "Helm, bir uygulamayı yalnızca son sürümden bu yana değişmişse günceller." Bunun için mantıklı bir seçenek, liman işçisi görüntüsünün kendisindeki LABEL öğesini güncellemek gibi görünebilir. Ancak Helm, uygulama görsellerini incelemiyor ve bunlarda herhangi bir değişiklik olduğuna dair hiçbir fikri yok. Buna göre görüntüdeki etiketler güncellenirken Helm'in bunlardan haberi olmayacak ve uygulama güncelleme komutu Kubernetes'e gönderilmeyecek.
Yöntem 3: Anahtar kullanma --force
Kılavuzlara dönelim ve gerekli anahtarı arayalım. Anahtar en mantıklısı --force. Açık isme rağmen davranış beklenenden farklıdır. Bir uygulamayı güncellemeye zorlamak yerine asıl amacı, BAŞARISIZ durumdaki bir sürümü geri yüklemektir. Bu tuşu kullanmazsanız komutları sırayla uygulamanız gerekir. helm delete && helm install --replace. Bunun yerine anahtarı kullanmanız önerilir --forceBu komutların sıralı yürütülmesini otomatikleştiren. Daha fazla bilgi burada . Helm'e uygulama sürümünü güncellemesini söylemek için maalesef bu anahtar çalışmayacaktır.
Yöntem 4. Etiketleri doğrudan Kubernetes'te değiştirin
Komutu kullanarak etiketi doğrudan kümede güncelleme kubectl edit - kötü bir fikir. Bu eylem, çalışan uygulama ile başlangıçta dağıtım için gönderilen uygulama arasında bilgi tutarsızlığına yol açacaktır. Bu durumda Helm'in dağıtım sırasındaki davranışı sürümünden farklıdır: Helm 2 hiçbir şey yapmayacak ve Helm 3, uygulamanın yeni sürümünü dağıtacaktır. Nedenini anlamak için Helm'in nasıl çalıştığını anlamalısınız.
Helm nasıl çalışır?
Bir uygulamanın son sürümünden bu yana değişip değişmediğini belirlemek için Helm şunları kullanabilir:
- uygulamayı Kubernetes'te çalıştırmak;
- yeni değerler.yaml ve güncel grafik;
- Helm'in dahili yayın bilgileri.
Daha fazla merak edilenler için: Helm, sürümlerle ilgili dahili bilgileri nerede saklıyor?Komutu yürüterek helm historyHelm kullanılarak kurulan sürümlerle ilgili tüm bilgileri alacağız.
Gönderilen şablonlar ve değerler hakkında da detaylı bilgiler bulunmaktadır. Bunu talep edebiliriz:
Helm'in ikinci sürümünde bu bilgi, ConfigMap'te Tiller'ın çalıştığı ad alanında (varsayılan olarak kube sistemi) "OWNER=TILLER" etiketiyle işaretlenmiş olarak bulunur:
Helm'in üçüncü sürümü ortaya çıktığında bilgiler sırlara ve uygulamanın çalıştığı ad alanına taşındı. Bu sayede birden fazla uygulamayı aynı sürüm adıyla farklı ad alanlarında aynı anda çalıştırmak mümkün hale geldi. İkinci versiyonda, ad alanlarının izole olması ancak birbirini etkileyebilmesi ciddi bir baş ağrısıydı.
İkinci Dümen, bir güncellemenin gerekli olup olmadığını anlamaya çalışırken yalnızca iki bilgi kaynağı kullanır: kendisine şu anda sağlananlar ve ConfigMap'te bulunan sürümlerle ilgili dahili bilgiler.
Üçüncü Helm, üç yönlü bir birleştirme stratejisi kullanıyor: Bu bilgilere ek olarak şu anda Kubernetes'te çalışan uygulamayı da dikkate alıyor.
Bu nedenle Helm'in eski sürümü, kümedeki uygulama bilgilerini dikkate almadığı için hiçbir şey yapmayacak ancak Helm 3, değişiklikleri alıp yeni uygulamayı dağıtıma gönderecektir.
Yöntem 5. --recreate-pods anahtarını kullanın
Bir anahtarla --recreate-pods anahtarıyla başlangıçta başarmayı planladığınız şeyi başarabilirsiniz. --force. Kapsayıcılar yeniden başlatılacak ve imagePullPolicy: Her zaman en son etiket politikasına göre (bununla ilgili daha fazla bilgiyi yukarıdaki dipnotta bulabilirsiniz) Kubernetes, görüntünün yeni bir sürümünü indirip başlatacak. Bu en iyi şekilde yapılmayacaktır: Dağıtımın Strateji Türü dikkate alınmadan, tüm eski uygulama örneklerini aniden kapatacak ve yenilerini başlatmaya başlayacaktır. Yeniden başlatma sırasında sistem çalışmayacak, kullanıcılar sıkıntı yaşayacaktır.
Kubernetes'te de benzer bir sorun uzun süredir mevcuttu. Ve şimdi, açılıştan 4 yıl sonra , sorun düzeltildi ve Kubernetes'in 1.15 sürümünden itibaren bölmeleri yeniden başlatma yeteneği ortaya çıkıyor.
Helm basitçe tüm uygulamaları kapatır ve yakındaki yeni kapsayıcıları başlatır. Uygulamanın aksama süresine neden olmamak için bunu üretimde yapamazsınız. Bu yalnızca geliştirme ihtiyaçları için gereklidir ve yalnızca sahne ortamlarında gerçekleştirilebilir.
Helm kullanılarak uygulama sürümü nasıl güncellenir?
Helm'e gönderilen değerleri değiştireceğiz. Tipik olarak bunlar, resim etiketinin yerine geçen değerlerdir. Verimsiz ortamlar için sıklıkla kullanılan en son durumda, değiştirilebilir bilgiler Kubernetes'in kendisi için faydasız olan bir açıklamadır ve Helm için uygulamanın güncellenmesi gerektiğine dair bir sinyal görevi görecektir. Ek açıklama değerini doldurma seçenekleri:
- Rastgele değer standart işlevi kullanarak -
{{ randAlphaNum 6 }}.
Bir uyarı var: Böyle bir değişkene sahip bir grafik kullanan her dağıtımdan sonra, ek açıklama değeri benzersiz olacak ve Helm, değişikliklerin olduğunu varsayacaktır. Sürümünü değiştirmemiş olsak bile uygulamayı her zaman yeniden başlatacağımız ortaya çıktı. Kesinti olmayacağı için bu kritik değil, ancak yine de rahatsız edici. - Geçerli olanı yapıştır tarih ve saat -
{{ .Release.Date }}.
Bir değişken, kalıcı olarak benzersiz bir değişkene sahip rastgele bir değere benzer. - Daha doğru bir yol kullanmaktır sağlama toplamları. Bu, görüntünün SHA'sı veya git'teki son işlemin SHA'sıdır -
{{ .Values.sha }}.
Bunların sayılması ve arayan taraftaki Helm istemcisine (örneğin Jenkins'e) gönderilmesi gerekecektir. Uygulama değiştiyse sağlama toplamı da değişecektir. Bu nedenle Helm, uygulamayı yalnızca gerektiğinde güncelleyecektir.
Denemelerimizi özetleyelim
- Helm, değişiklikleri en az müdahaleci şekilde yapar, böylece Docker Kayıt Defterindeki uygulama görüntüsü düzeyindeki herhangi bir değişiklik bir güncellemeyle sonuçlanmaz: komut yürütüldükten sonra hiçbir şey olmaz.
- Anahtar
--forcesorunlu sürümleri geri yüklemek için kullanılır ve zorunlu güncellemelerle ilişkili değildir. - Anahtar
--recreate-podsuygulamaları zorla güncelleyecek, ancak bunu vandal bir şekilde yapacak: tüm kapsayıcıları aniden kapatacak. Kullanıcılar bundan zarar görecektir; bunu üretimde yapmamalısınız. - Komutu kullanarak Kubernetes kümesinde doğrudan değişiklik yapın
kubectl edityapmayın: Tutarlılığı bozarız ve davranış, Helm sürümüne bağlı olarak farklılık gösterir. - Helm'in yeni sürümünün piyasaya sürülmesiyle birlikte birçok nüans ortaya çıktı. Helm deposundaki sorunlar açık bir dille anlatılmıştır ve ayrıntıları anlamanıza yardımcı olacaktır.
- Grafiğe düzenlenebilir bir açıklama eklemek grafiği daha esnek hale getirecektir. Bu, uygulamayı kesinti olmadan doğru şekilde kullanıma sunmanıza olanak tanır.
Hayatın her alanında işe yarayan bir “dünya barışı” düşüncesi: Kullanmadan önce talimatları okuyun, kullandıktan sonra değil. Güvenilir sistemler oluşturmak ve kullanıcıları mutlu etmek ancak eksiksiz bilgi ile mümkün olacaktır.
Diğer ilgili bağlantılar:
Bu rapor ilk olarak şu tarihte sunuldu: Mail.ru Bulut Çözümleri tarafından. Bakmak diğer performanslar ve Telegram'daki etkinlik duyurularına abone olun .
Kaynak: habr.com