Klasik vaka inceleme-operasyon ve bakım uzmanları K8S inişine nasıl ulaşılacağı hakkında konuşuyor
Son yıllarda, Yunmanman'ın işi hızla gelişti ve sistem kararlılığı için gereksinimleri gittikçe artıyor.Bazı sorunlu noktalara yanıt olarak, K8'leri uygulamaya başladı.
Arka plan tanıtımı
Yunmanman mikro hizmet dönüşümünü başlattığından beri, mikro hizmetlerin binlerce Java örneği çevrimiçi ve çevrimdışı çalışıyor. Bu Java örnekleri, yüzlerce bulut sunucusuna veya sanal makineye dağıtılır.Yüksek trafiğe sahip birkaç önemli uygulama dışında, örneklerin çoğu karma bir şekilde dağıtılır.
Bu örneklerin yönetimi, açık kaynaklı yazılımla birlikte kendi geliştirdiği bir platformu benimser. Belirtilen sürümün paketleme, dağıtım, başlatma, durdurma ve geri alma gibi temel işlevler, platform sayfasındaki düğme menüsü aracılığıyla gerçekleştirildi ve iyi sonuçlar elde edildi. Ancak aşağıdaki gibi hala birkaç acı noktası var:
Örnekler arasında kaynak izolasyonu, özellikle yoğun dönemlerde veya arızalarda, tek bir sunucudaki farklı örnekler arasında CPU ve bellek kaynakları için rekabet özellikle belirgindir.
Çevrimiçi bir uygulama örneği anormal olduğunda, manuel müdahale gerekir ve bu da uzun bir arıza süresine neden olur.
Web sitesi anahtar işlevi hataları gibi sunucu tarafındaki uygulamaların çok sayıda yeni sürümü çevrimiçi olduktan sonra, her uygulama için ilgili sürümü seçmeniz ve bir geri alma işlemi gerçekleştirmeniz gerekir.Tüm işlem uzun zaman alır.
Çevrimdışı DEV / QA ortamları sık sık yayınlanır ve her sürümün yeni bir sürüm yayınlamadan önce eski sürümü durdurması gerekir, bu da günlük testleri etkileyecektir.
Yunmanman'ın hızla büyüyen işletmesi, sistem kararlılığı için giderek daha yüksek gereksinimlere sahiptir.Yukarıdaki sorunları acilen çözmemiz gerekiyor.
Teknik araştırma ve seçim
Başlangıçta bizi cezbeden şey, konteyner teknolojisinin iyi izolasyonu ve yatay genişlemesiydi. Docker'ın itibarı ve birkaç yıl önce katıldığımız bazı Docker projelerinin deneyimi, Docker konteyner teknolojisinin benimsenmesini tek seçeneğimiz haline getirdi.
Ancak Docker konteynerlerinin yönetimini otomatikleştirmek için hala bir dizi konteyner düzenleme sistemine ihtiyacımız var. 3 seçenek vardır: Kubetnetes (K8S), swarm, mesos
Bu üç sisteme aşina değiliz ve bu projenin hızı çok acil ve bu üç sistemi derinlemesine anladıktan sonra seçim yapmamıza izin verilmiyor. Neyse ki, Github'ın istatistiksel bir işlevi vardır. Aşağıdaki şekilde gösterildiği gibi, Github'da bu üç açık kaynaklı proje hakkında bazı temel bilgiler bulduk:
Bu istatistiksel verilere ve Google'ın aurasına dayanarak, K8S'nin kısa sürede bir konteyner düzenleme yönetim sistemi olarak kullanımını belirledik. K8S, bu açık kaynaklı proje, konteyner uygulamalarını otomatik olarak dağıtabileceğini, genişletebileceğini ve yönetebileceğini iddia ediyor ve aşağıdaki temel sorunları çözebilir:
-
Yük dengeleme -Bir uygulama birden çok aynı kapsayıcıyı çalıştırır, dahili Hizmet birleşik bir erişim tanımı sağlar ve yük dengeli bir şekilde erişim sağlar.
-
Hizmet keşfi -Servis ve Kube-DNS birleştirilir ve ilgili konteynere yalnızca sabit bir Servis adı aracılığıyla erişilebilir ve servis keşif bileşenlerini bağımsız olarak bulmaya ve kullanmaya gerek yoktur.
-
Yüksek kullanılabilirlik -K8S, hizmetin sağlık durumunu kontrol edecek ve normal çalışmayı sağlamak için bir anormallik bulunduğunda hizmeti otomatik olarak yeniden başlatmayı deneyecektir.
-
Rolling yükseltme Yükseltme işlemi sırasında, K8S, yükseltmenin etkisini en aza indirmek için bir konteyneri birbiri ardına yükseltmeyi planlayacaktır.
-
Otomatik ölçeklendirme -Konteyner kaynak kullanımı yüksek olduğunda bir strateji yapılandırabilirsiniz, baskıyı paylaşmak için otomatik olarak yeni konteynerler ekler ve kaynak kullanımı azaldığında konteynerler geri dönüştürülür.
-
Hızlı dağıtım -İlgili orkestrasyon betiğini yazın, çok kısa sürede bir ortam setini dağıtabilirsiniz.
-
Kaynak sınırı - Kaynakların ve kazaların veya baskının önlenmesini önlemek için programın maksimum kaynak kullanımını sınırlamak, temel hizmetlerin etkilenmemesini sakin bir şekilde sağlayabilir.
K8S'yi daha iyi anladıktan sonra, aşağıdaki bileşenlerin, ilgili teknolojilerin ve sistemlerin kullanılacağını kabaca belirledik:
-
Uygulama dağıtımı K8S Dağıtımı, HPA;
-
Birkaç temel hizmet K8S Daemonset, kube-dns;
-
Harici hizmet teşhiri K8S Ingress, Traefik, Service;
-
Ağ eklentisi Flannel;
-
Alarmları izleme Heapster, InfluxDB, Grafana, Prometheus;
-
Yönetim arayüzü Kubectl, Dashboard, kendi geliştirdiği kumaş yönetim sistemi;
-
İkiz imajlar oluşturun Jenkins, Maven, Docker;
-
Aynalı depo Limanı;
-
Günlük toplama Filebeat, Kafka, ELK.
Zorluklar ve temel ilkeler
Çevrimiçi hizmetler, hizmet sunumunda kesinti olmadan taşınmalıdır.Her uygulama trafiği orantılı olarak böler ve kararlılığı sağlama öncülü altında K8S kümesine taşınır.
DEV ortamı toplu olarak başlatılabilir ve QA ve Üretim ortamlarının her uygulamanın sürüm bağımlılıklarını dikkate alması gerekir.
Başlangıçta yalnızca vatansız uygulamalar kullanıldı.
Ar-Ge / Kalite Güvencesi üzerindeki etkiyi en aza indirin (meşgul Ar-Ge / QA öğrencileri için iş yükünü artırmamaya çalışın).
İniş sürecinin analizi
Dockerization öncesi ve sonrası uygulama yayınlama sürecinin karşılaştırılması
Aşağıdaki şekilde iki belirgin değişiklik görülebilir:
1. Savaş paketi ve jar paketi daha önce konuşlandırıldı ve Docker görüntüsü daha sonra konuşlandırıldı (görüntü savaş paketi ve jar paketi içerir). 2. Uygulama süreci durdurulup daha sonra başlatılmadan önce, yayınlama sürecinde hizmet kesintiye uğrayacak, daha sonra yeni sürüm kabı başlatılmış, ardından eski sürüm kabı durdurulmuştur.Uygulama, yayınlama sürecinde hizmet vermektedir.
Geçişte sistem mimarisi
Mevcut iş uygulamaları temel olarak iki türe ayrılır: Yalnızca dahili uygulama çağrıları için RPC hizmeti (Pigeon çerçevesi) ve harici hizmetler için REST API. REST API ayrıca API ağ geçidine bağlı ve API ağ geçidine bağlı olmayan iki türe ayrılabilir. . API ağ geçidine bağlanan RPC hizmeti ve uygulamaların kendi kayıt defteri vardır. Geçiş adımları nispeten basittir, sadece K8S kümesinde ilgili uygulamayı başlatın. API ağ geçidine bağlı olmayan uygulamalar, harici hizmetlere erişim sağlamak için K8S Ingress eklentisini kullanır ve bazı yapılandırmalar gerektirir. Sistem mimarisi aşağıdaki şekilde gösterilmiştir: Nihai amaç, şeklin altındaki iki kutudaki tüm uygulamaları K8S kümesine taşımaktır.
Ana kümenin yüksek kullanılabilirliği
Genel bulutun sınırlandırılması nedeniyle, esas olarak servis sağlayıcılar tarafından sağlanan SLB'yi uyguluyoruz. Şematik diyagram aşağıdaki gibidir:
K8S küme uygulamaları harici hizmetler sağlar
Kümedeki POD'un IP adresindeki dinamik değişiklikler nedeniyle, harici hizmetlere birleşik bir giriş sağlamak için Traefik + Ingress + Nginx + SLB yöntemini benimsiyoruz. Traefik, HTTP isteğinin etki alanı adı ve yoluna göre farklı uygulama hizmetlerine yönlendirir.Nginx, yeniden yazma gibi bazı karmaşık işlemleri gerçekleştirir ve SLB yüksek kullanılabilirlik sağlar. Yapı şeması aşağıdaki gibidir:
Kapta uygulama başlatma
Aynı görüntünün DEV, QA, Production vb. Gibi çeşitli ortamlarda çalışabileceğini anlamak için, görüntüde saklanan bir başlatma komut dosyası yazılmalıdır. Konteyner başladığında, mevcut ortamı Env değişkeninden okur ve her bir ortama karşılık gelen yapılandırma dosyalarına ve günlük dizinini ayarlama gibi diğer başlatma işlemlerine bir dizi yumuşak bağlantı oluşturur ve ardından kabı algılamak ve ayarlamak için yeni bir işlemi zorlar. Dahili uygulamanın normal başlatmayı tamamlayıp tamamlamadığı (kapsayıcı hazırlık araştırmasıyla kullanılır) ve aynı zamanda uygulama başlatma komut dosyasını çağırıp çağırmadığı. Aşağıdaki şekil, kabın yumuşak bağlantılar aracılığıyla farklı ortam yapılandırma dosyalarına işaret ettiğini göstermektedir:
Aşağıdaki şekil, kapsayıcıdaki yumuşak zincir aracılığıyla ayarlanan günlük dizini gösterir:
K8S günlük toplama
Geçerli uygulama günlükleri dosyalar biçiminde saklanır ve tek bir örnek birden çok günlük dosyasına karşılık gelir, bu nedenle resmi K8S günlük şeması kullanılamaz. Aynı zamanda, konteynerin vatansız olması nedeniyle, günlüğü kaydetmenin başka bir yolunu bulmalıyız. Şu anda, Node üzerindeki sabit bir dizin, konteynere eklemek için bir depolama birimi olarak kullanılmaktadır. Konteyner başlatıldığında, uygulama adı + konteyner IP'sine göre konteynere özel günlük yolunu oluşturmak için bir başlatma komut dosyası kullanılır. Günlükleri kolayca görüntülemek için 3 yol sunuyoruz:
1. Kaptaki SSH sunucusunu etkinleştirin ve WEBSSH'yi yayınlama yönetim sisteminde uygulayın Normal şartlar altında, günlükleri WEB sayfası üzerinden görüntülemek için kapsayıcı komut satırına girebilirsiniz. Rahatlığı nedeniyle bu yöntem önerilir. 2. Bazı durumlarda, kapsayıcı başlatılamaz ve şu anda komut satırına giremezsiniz.Günlük bağlantı adresini sürüm yönetim sisteminde bulabilir ve görüntülemek için bu makineye indirebilirsiniz. 3. Ek olarak, her Düğümde bir Filebeat kapsayıcısı çalıştırıyoruz ve Düğümde toplanan günlükleri gerçek zamanlı olarak Kafka kümesine gönderiyor ve daha sonra alınmak üzere ES kümesinde depoluyoruz.
Aşağıdaki şekil, Düğüm sunucusundaki günlük dizini yapısını gösterir:
Aşağıdaki şekil, Düğüm sunucusunda paylaşılan günlük indirme yolunu gösterir:
K8S izleme
Heapster + InfluxDB + Grafana kombinasyonunu kullanarak, InfluxDB'nin izleme verilerini depolamak için kullanıldığı ve verilerin kalıcı olması gerektiği unutulmamalıdır. Grafana üzerinde Ad Alanı, Düğüm ve uygulama adına göre geri alınabilen farklı boyutlarda gösterge panoları oluşturulmuştur ve uygulamalar, sorun giderme ve günlük optimizasyonu kolaylaştırmak için CPU, bellek, ağ bant genişliği ve sabit disk kullanımına göre filtrelenebilir. (Elbette, daha iyi izleme sistemi, zaten yolda olan Prometheus'tur.)
Aşağıdaki resim izleme pazarını göstermektedir:
Aşağıdaki resim izleme menüsünü göstermektedir:
Aşağıdaki resim, bir uygulamanın izleme resmidir:
Liman aynası deposu
Şu anda tek ana çoklu köle yapısını kullandığımız liman. Ana kitaplık ve paketlenmiş Jenkins, çevrimdışı ağdadır. Görüntü ana kitaplığa yüklendikten sonra, aşağıda gösterildiği gibi başka bir çevrimdışı köle kitaplığı ve çevrimiçi köle kitaplığı ile otomatik olarak senkronize edilecektir. Gösterilen:
Ayna ağacı
Planımız bir ayna ağacı oluşturmaktır.Tüm uygulamalar, uygulama aynaları oluşturmak için bu ağaçtaki temel aynaya dayanır.Her bir uygulamayı oluştururken, en benzer temel aynayı seçin ve ardından uygulamanın özel gereksinimlerini artırın. Bu görüntü ağacına dayalı olarak, uygulamalarımızın% 95'inden fazlasının Dockerfile'ı Gitlab'a yerleştirmesine gerek yoktur. Dockerfile, paketleme sırasında değişkenlere göre otomatik olarak oluşturulabilir, örneğin:
Aşağıdaki şekil, komut dosyası tarafından otomatik olarak oluşturulan bir uygulama Dockerfile'ını gösterir:
Aynalı ağaç yapısının şematik diyagramı aşağıdaki gibidir:
Mevcut durum
Konteynerizasyon : DEV / QA ortamındaki uygulamalar Dockerize edildi ve ürün ortamındaki uygulamaların yaklaşık% 98'i Dockerize edildi. Sistem kendi kendini iyileştirme : OOM veya başka bir Crash uygulanırken, sistem, başarısız olan düğümü değiştirmek için otomatik olarak yeni bir düğüm çekebilir ve gelişmiş durum denetimi henüz etkinleştirilmemiştir (başka işbirliği gereklidir). Elastik ölçeklendirme : Tüm temel uygulamalar elastik ölçeklendirmeyi mümkün kılar ve yoğun ziyaretler sırasında gözlemlenen etki çok iyidir. Yuvarlanan sürüm : Uygulama sürümü, belirtilen orana göre gruplar halinde dağıtılabilir ve güncellenebilir, önce bir grubu güncelleyin, başarılı olduktan sonra bir grubu imha edin ve sırayla yuvarlayın. Hızlı geri alma : Şu anda, yalnızca tek uygulamalı hızlı geri alma desteklenmektedir. Daha sonraki dönemde işlem düzeyinde geri alma kapasitesini artırmanız gerekirse, K8S'nin kullanıma sunma işlevi kolayca uygulanabilir.
Bazı basamaklı çukurlar ve öneriler
1. Altta yatan işletim sistemi, sorunlardan kurtaracak CentOS 7.x sürümünü benimser. 2. Alibaba Cloud klasik ağındaki ECS, konteyner IP'sine erişemez ve VPC ortamına taşınması gerekir.Diğer genel bulutlardaki durum benzerdir. Anahtar, rotaları bağımsız olarak ekleyebilmektir. 3. Uygulama düzeyinde izleme varsa, konteynerden toplanan Bellek ve Yük Ortalaması gibi bilgiler konteynerden değil, temeldeki işletim sistemindendir Bu göstergeler, özel bir konteyner izleme sistemine dayanabilir. 4. Ulimit sınırlamasına dikkat edin, konteynerde izole edilmemiştir.Çok küçük ayarlarsanız açıklanamayan bazı problemlerle karşılaşacaksınız. 5. Konteynırdaki kök kullanıcı, netstat komutu ile diğer kullanıcılar tarafından oluşturulan işlemin sahibini göremeyebilir, bazı eski komut dosyaları varsa benzer problemlerle karşılaşılabilir. 6. Konteynırın belirli bağlantı noktalarına doğrudan erişmesi gereken bazı dahili sistemler varsa, başsız servis çok kullanışlıdır. 7. Zookeeper'ın varsayılan 60 tek IP bağlantısı sınırı vardır Bu parametre değiştirilmezse, uygulamalar K8S'ye geçtikten sonra bu sorunla karşılaşabilir. 8. Ürün ortamında çok ziyaret edilen bir uygulama K8S'ye taşındığında, önce tüm trafiğin tüketilebilmesini sağlamak için daha fazla sayıda kapsayıcı tahsis edilebilir ve ardından izlemeye dayalı olarak, fazla kapsayıcıları azaltmak için esnek ölçeklendirme işlevini kullanın. 9. K8S kümesinin performansını önceden bilmek istiyorsanız, uygulamayı konuşlandırdıktan sonra bir stres testi yapmanız gerekir.
yazar hakkında
Chunlin Wang, Yunmanman Teknik Destek Departmanında, konteyner ve DevOPS alanlarına odaklanıyor.
