JD'nin OpenStack'ten Kubernetes'e geçme deneyimi
Yazar Bao Yongcheng
Düzenle Bella
JD.com, 2016'nın sonunda OpenStack'ten Kubernetes'e geçişi başlattı. Şimdiye kadar, geçişin% 20'si tamamlandı. İkinci çeyrekte anahtarı tamamlaması bekleniyor. OpenStack çözümüyle karşılaştırıldığında, Kubernetes çözümü daha özlü bir mimariye sahiptir. Bu süreçte, bu deneyimler endüstri tarafından referans olarak kullanılabilir.
Arka plan tanıtımı
2016'nın sonunda, JD.com'un yeni nesil konteyner motoru platformu JDOS 2.0 piyasaya sürüldü ve JD.com OpenStack'ten Kubernetes'e geçti. Şimdiye kadar, JDOS2.0 kümesi 2w + Kapsülü kararlı bir şekilde çalışıyordu ve işletme, IDC dağıtımına göre toplu olarak yeni platforma taşındı. Şu anda% 20'si taşındı. İkinci çeyrekte Kubernetes'e geçmesi planlanıyor. İşletme Ar-Ge personeli, otomatik dağıtımdan çevrimiçi ortama geçmek için kademeli olarak uyum sağlıyor Yansıtmaya odaklanan çevrimiçi moda. JDOS 2.0, birleşik JD hizmetleri, gerçek zamanlı çevrimdışı büyük veri ve makine öğrenimi (GPU) bilgi işlem kümeleri sağlar. OpenStack'ten Kubernetes'e geçerken, öğrenmek için hangi deneyim var?
Bu makale, okuyuculara geliştirme geçmişini tanıtacak ve JD.com Ar-Ge Temel Platform Departmanı'nın 0'dan JDOS1.0'dan JDOS2.0'a nasıl geçtiğine ilişkin deneyim özetini sunacak:
-
Temel platform sistemi işinin giriş noktası olarak sorunlu noktalar nasıl bulunur;
-
Pratik yaparken teknik vizyon nasıl korunur;
-
Büyük ölçekli bir konteyner platformu nasıl çalıştırılır ve sürdürülür;
-
Konteyner teknolojisi yazılım tanımlı veri merkezleriyle nasıl birleştirilir.
Küme yapımının tarihçesi
Fiziksel makineler dönemi (2004-2014)
2014'ten önce, şirketin uygulamaları doğrudan fiziksel makinelerde kullanılıyordu. Fiziksel makineler çağında, uygulamanın başlatılmasından fiziksel makinelerin nihai tahsisine kadar geçen ortalama süre bir haftadır. Uygulamalar karıştırılır ve birlikte dağıtılır ve izolasyon olmadan uygulama karışık parçaları kaçınılmaz olarak birbirini etkiler. Olumsuz etkiyi azaltmak için, karma departmandaki her bir fiziksel makinenin ortalama oranı, farklı uygulamaların 9 Tomcat örneğinden daha düşüktür ve bu, fiziksel makine kaynaklarının ciddi şekilde israfına ve son derece esnek olmayan programlamaya neden olur. Fiziksel makine arızalarının neden olduğu uygulama örneklerinin geçiş süresi saat olarak ölçülür ve otomatik elastik ölçeklendirmenin elde edilmesi zordur. Uygulama dağıtımının verimliliğini artırmak için şirket, derleme ve paketleme, otomatik dağıtım, günlük toplama ve kaynak izleme gibi çoklu destekleyici araç sistemleri geliştirmiştir.
Konteynerizasyon dönemi (2014-2016)
2014'ün üçüncü çeyreğinde, şirketin baş mimarı Liu Haifeng, temel platform ekibine küme yapımını yeniden tasarlama ve planlama konusunda öncülük etti. Docker konteynerleri ana seçim çözümü oldu. Docker o dönemde yavaş yavaş ortaya çıkmış olsa da, işlevleri biraz zayıftı ve bir üretim ortamı, özellikle büyük ölçekli bir üretim ortamı uygulamasından yoksundu. Ekip, Docker üzerinde, özellikle büyük ölçekli uzun vadeli stres ve kararlılık testleri üzerinde tekrarlanan testler gerçekleştirdi. Test sonuçlarına göre, Aygıt Eşleştiricisi, Linux çekirdeği ve diğer sorunların neden olduğu çökmeyi gideren Docker için özelleştirilmiş geliştirme gerçekleştirildi ve harici disklerin hız sınırı, kapasite yönetimi ve görüntü oluşturma seviyesi birleştirme gibi fonksiyonlar eklendi.
Ekip, kapsayıcı küme yönetimi için, sanal makineleri yöneterek kapsayıcıları yönetmek için OpenStack + nova-docker mimarisini seçti ve bunu JD'nin birinci nesil kapsayıcı motoru platformu JDOS1.0 (JD DataCenter OS) olarak tanımladı. JDOS 1.0'ın ana işi, altyapının konteynırlaştırılmasını gerçekleştirmektir ve uygulama, orijinal fiziksel makine yerine konteyneri kullanacaktır.
Uygulama operasyonu ve bakımı açısından, önceki destekleyici alet sistemi de kullanılır. Bilgi işlem kaynakları için çevrimiçi Ar-Ge uygulaması, önceki haftadan dakika seviyesine indirildi: İster 1 konteyner ister 1.000 konteyner olsun, hesaplama kaynak havuzlamasından sonra saniyeler içinde sağlanabilir. Aynı zamanda, uygulama konteynerleri arasındaki kaynak kullanımı da etkin bir şekilde izole edilmiş, ortalama uygulama yoğunluğu 3 kat artmış ve fiziksel makinelerin kullanım oranı 3 kat artarak büyük ekonomik faydalar sağlanmıştır.
Çoklu IDC dağıtım yöntemini benimsiyoruz ve işin IDC'ler arası dağıtımını desteklemek için çevrimiçi sistemi açmak ve bağlanmak için birleşik bir küresel API kullanıyoruz. Tek bir OpenStack kümesinde maksimum 10.000 fiziksel bilgi işlem düğümü ve minimum 4K bilgi işlem düğümü bulunur. Birinci nesil konteyner motoru platformu, 2015 ve 2016 yıllarında 618 ve Double Eleven promosyon etkinliklerini başarıyla destekledi. Kasım 2016 itibariyle, 15W + konteynerler istikrarlı bir şekilde çalışmaktadır.
Tamamlanan birinci nesil konteyner motoru iniş uygulamasında ekip, işin fiziksel makinelerden konteynerlere geçişini teşvik etti. JDOS1.0'da, IaaS yöntemini, yani konteynerleri yönetmek için sanal makineleri yönetme yöntemini kullanıyoruz.Bu nedenle, uygulamaların dağıtımı, fiziksel makineler çağında hala büyük ölçüde derleme ve paketleme ve otomatik dağıtım gibi araç sistemlerine dayanmaktadır. Bununla birlikte, JDOS 1.0 uygulaması çok anlamlıdır ve önemi, iş uygulamalarının konteynerizasyonunu tamamlamak ve konteynerin ağını ve depolamasını kademeli olarak olgunlaştırmaktır. Bunların hepsi, 1.0 deneyimine dayalı yeni bir uygulama geliştirmemiz içindir. Konteyner motoru sağlam bir temel attı.
Yeni nesil uygulama kapsayıcı motoru (JDOS 2.0)
1.0 ağrı noktası
JDOS 1.0, uygulama konteynerleştirme sorununu çözmektedir, ancak yine de birçok eksiklik vardır.
Birincisi, derleme, paketleme ve otomatik dağıtım gibi araçların fiziksel makine çağından doğması ve kullanıma hazır konteyner konseptiyle uyumsuz olmasıdır.Konteyner başlatıldıktan sonra, yapılandırmayı dağıtmak, uygulamaları dağıtmak vb. İçin destekleyici bir araç sistemine ihtiyaç duyulur ve uygulama başlatma hızı sınırlanır. .
İkinci olarak, çevrimiçi ve çevrimdışı ortamlarda hala tutarsızlıklar vardır Uygulamanın işletim ortamı ve bağımlı yazılım yığını, çevrimdışı kendi kendini sınama sırasında yine de ayrı ayrı oluşturulmalıdır. Çevrimiçi ve çevrimdışı ortamların tutarsızlığı da bazı çevrimiçi sorunların çevrimdışı yeniden üretilmesinin zor olmasına neden oldu ve aynalamanın ideal "bir kez oluştur, herhangi bir yerde çalıştır" durumuna ulaşmak da imkansız.
Üçüncüsü, konteynerin hacmi çok ağırdır ve uygulamaların dağıtım için alet sistemlerine güvenmesi gerekir.Sonuç olarak, iş geçişi hala alet sistemlerinin manuel olarak çalıştırılmasını ve bakımını gerektirir. Genel platform katmanında esnek genişleme ve daralma ve yüksek kullanılabilirlik elde etmek zordur.
Ek olarak, kabın programlama yöntemi nispeten basittir ve yalnızca fiziksel makinenin kalan kaynaklarının gereksinimleri karşılayıp karşılamadığına bağlı olarak taranabilir ve programlanabilir Uygulamanın performansını ve platformun kullanım oranını iyileştirmede bir tavan vardır ve daha fazla geliştirilemez.
Platform mimarisi
Yukarıdaki eksiklikler ışığında, JDOS 1.0 kademeli olarak bin veya iki bin konteynerden altmış bin veya yüz bine çıktığında, yeni nesil bir konteyner motoru platformunun (JDOS 2.0) geliştirilmesine şimdiden başladık. JDOS 2.0'ın amacı yalnızca bir altyapı yönetimi platformu değil, aynı zamanda uygulamaya bakan bir konteyner motorudur. Orijinal 1.0 temelinde, JDOS 2.0, JDOS 1.0 depolama ve ağını Kubernetes etrafında bütünleştirir, kaynak koddan aynalamaya ve ardından çevrimiçi dağıtıma kadar tüm CI / CD sürecini açar. Günlük, izleme, sorun giderme, terminal ve düzenleme sağlar. Tek duraklı işlevi bekleyin. JDOS 2.0'ın platform mimarisi aşağıdaki şekilde gösterilmektedir.
JDOS 2.0'da iki seviye sistem ve uygulama tanımladık. Bir sistem birkaç uygulama içerir ve bir uygulama aynı hizmeti sağlayan birkaç kapsayıcı örneği içerir. Genel olarak konuşursak, büyük bir departman bir veya daha fazla sistem için başvurabilir. Sistem seviyesi doğrudan Kubernetes'teki ad alanına karşılık gelir ve aynı sistem altındaki tüm konteyner örnekleri aynı Kubernetes ad alanında olacaktır. Uygulama yalnızca kapsayıcı örnek sayısının yönetimini sağlamakla kalmaz, aynı zamanda sürüm yönetimi, etki alanı adı çözümleme, yük dengeleme ve yapılandırma dosyaları gibi hizmetleri de içerir.
Yalnızca şirketin çeşitli iş uygulamaları değil, JDOS 2.0 bileşenlerinin çoğu (Gitlab / Jenkins / Harbor / Logstash / Elastic Search / Prometheus) da kapsayıcıya alınmış ve Kubernetes platformunda dağıtılmıştır.
Geliştirici tek elden çözüm
JDOS 2.0, çekirdek olarak yansıtma ile sürekli entegrasyon ve sürekli dağıtım gerçekleştirir.
Geliştiriciler, kodu kaynak kod yönetimi kitaplığına gönderir
Derleme görevleri oluşturmak için Jenkins Master'ı tetikleyin
Jenkins Master, Jenkins Slave Pod'u oluşturmak için Kubernetes kullanır
Jenkins Slave, derleme ve paketleme için kaynak kodunu çekiyor
Paketlenmiş dosyayı ve Dockerfile'ı derleme düğümüne gönderin
Derleme düğümünde görüntüler oluşturun ve oluşturun
Resmi Liman'a itin
Gerektiği gibi farklı ortamlarda uygulama kapsayıcıları üretin / güncelleyin
JDOS 1.0'da, konteyner görüntüsü esas olarak işletim sistemini ve uygulamanın çalışma zamanı yazılım yığınını içerir. APP'nin konuşlandırılması, önceki operasyon ve bakımın otomatik olarak dağıtılması gibi araçlara hala dayanmaktadır. 2.0'da, görüntünün oluşturulması sırasında uygulamanın dağıtımını tamamlıyoruz Görüntü, tamamen kutudan çıkarılmış olan APP dahil olmak üzere eksiksiz yazılım yığınını içeriyor.
Ağ ve harici hizmet yükü dengeleme
JDOS 2.0, JDOS 1.0 şemasını devralır ve OpenStack-Neutron'un VLAN modunu benimser Bu şema, konteynerler arasında verimli iletişimi gerçekleştirir ve şirketin dahili küme ortamı için çok uygundur. Her Bölme, Neutron'da bir bağlantı noktası kaplar ve bağımsız bir IP'ye sahiptir. CNI standardına dayanarak, Kubelet ve Neutron'u entegre etmek için yeni bir proje Cane geliştirdik.
Aynı zamanda Cane, Kubernetes'te hizmette LoadBalancer'ın oluşturulmasından sorumludur. LoadBalancer türü bir hizmet oluşturulduğunda / silindiğinde / değiştirildiğinde, Cane, harici hizmet yük dengelemesinin yönetimini gerçekleştirmek için LBaaS oluşturmak / silmek / değiştirmek için buna karşılık olarak Neutron'un hizmet arayüzünü arayacaktır. Ek olarak, Cane projesinin Hades (https://github.com/ipdcode/hades Jingdong açık kaynak on GitHub) bileşeni, kapsayıcı için dahili DNS çözümleme hizmetleri sağlar.
Esnek zamanlama
JDOS 2.0, büyük veri, web uygulamaları ve derin öğrenme dahil olmak üzere çeşitli uygulama türlerine erişebilir ve türüne göre her uygulama için farklı kaynak kısıtlama yöntemleri kullanır ve farklı Kubernetes etiketleriyle etiketlenir. Çeşitli etiketlere dayanarak, daha çeşitli ve esnek zamanlama yöntemleri uyguladık ve bazı IDC'lerde deneysel olarak çevrimiçi görevleri ve çevrimdışı görevleri devreye aldık. 1.0 ile karşılaştırıldığında, genel kaynak kullanımı yaklaşık% 30 artmıştır.
Promosyon ve görünüm
Temel olarak 1.0 değerindeki büyük ölçekli istikrarlı operasyon ile işletme, konteynerlerin kullanımı için önemli ölçüde güven ve destek sağlamıştır, ancak platform tabanlı konteynerler ve altyapı tabanlı konteynerler, uygulamalar için farklı gereksinimlere sahiptir. Örneğin, platform tabanlı bir uygulama konteynerinin IP'si sabit değildir, çünkü bir konteyner arızalandığında, platform onu değiştirmek için otomatik olarak başka bir konteyner başlatacaktır Yeni konteyner IP'si orijinal IP'den farklı olabilir. Bu, artık ana tanımlayıcı olarak kapsayıcı IP'sini kullanmak yerine alan adlarını, yük dengelemeyi veya hizmetin kendi kendine kaydını kullanmak için hizmet keşfi gerektirir.
Bu nedenle, JDOS2.0'ın tanıtım sürecinde, iş tarafının da uygulama hizmetlerine odaklanmasını ve tek bir konteyner gibi detayların işleyişini azaltmasını teşvik ettik ve bu sayede yeni bir akıllı alan adı çözümleme hizmeti ve DPDK tabanlı yüksek performanslı bir yük dengeleme hizmeti geliştirdik. Kubernetes, destekle etkin bir şekilde işbirliği yapar.
Son iki yılda, büyük veri ve yapay zeka gibi araştırma ve geliştirmenin yaygınlaşmasıyla, bilgi işlem kaynaklarının tüketimi de arttı. Bu nedenle, büyük veri ve derin öğrenme gibi çevrimdışı bilgi işlem hizmetlerini JDOS 2.0'a taşıdık. Şu anda, bölgeleri bölme yöntemi esas olarak kullanılmaktadır.İlgili hizmetler hala nispeten bağımsız hesaplama kaynaklarını kullanmaktadır, ancak birleşik yönetim için JDOS2.0 platformuna dahil edilmiştir ve bilgi işlem kaynaklarının kullanımı, makine öğrenimi yöntemleriyle iyileştirilmiştir.
Esnek etiketler, küme planlaması için sınırsız olanaklar sunar. Gelecekte, programlama algoritmalarını zenginleştireceğiz ve kümenin genel yatırım getirisini artırmak için bunları enerji tasarrufu teknolojileriyle donatacağız, böylece düşük enerji tüketimi ve yüksek performanslı yeşil bir veri merkezi inşa etmenin temelini atacağız.
Geriye bakmak ve özetlemek
OpenStack çözümüyle karşılaştırıldığında, Kubernetes çözümü daha özlü bir mimariye sahiptir. OpenStack'in genel işletim maliyeti nispeten yüksektir, çünkü birden fazla proje söz konusudur ve her projenin birden çok farklı bileşeni vardır Bileşenler RPC (genellikle MQ) aracılığıyla iletişim kurar. Kullanılabilirliği ve performansı iyileştirmek için, her bileşenin genişletilmesi ve yedeklenmesi de dikkate alınmalıdır. Tüm bunlar, genel planın karmaşıklığını ağırlaştırdı ve sorunların giderilmesi ve bulunmasındaki zorluk buna bağlı olarak arttı ve işletme ve bakım personeli için gereksinimler de buna göre arttı.
Buna karşılık, Kubernetes daha az bileşene ve net işlevlere sahiptir. Temel konsepti (kaynakları ve görevleri anlama), esnek tasarımı (etiketler) ve bildirim temelli API'si, Google'ın Borg sisteminin yıllar içindeki en iyi özetidir ve sağladığı zengin işlevler, daha fazla enerji yatırımı yapmamızı sağlar Platformun tüm ekolojisinde, örneğin ağ performansının iyileştirilmesi ve platformun kendisinin değil, konteynerlerin hassas planlanması gibi. Özellikle kopya kontrolü işlevi, çevrimiçi iş uygulama işletim ve bakım mühendisleri tarafından aranmıştır ve uygulama genişletme ve küçültme ve yüksek kullanılabilirlik saniyeler içinde tamamlanmıştır. JDOS 2.0 şu anda uygulamaların yaklaşık% 20'sine bağlanmıştır, 2 küme ile konuşlandırılmıştır, şu anda günlük 20.000 konteyner çalışmaktadır ve hala kademeli olarak yükseltilmektedir.
Kubernetes topluluğuna ve ilgili açık kaynak projelerine katkıda bulunanlara içtenlikle teşekkür ederim.Şu anda JD, CNCF organizasyonuna katıldı ve topluluk sıralamasında TOP30'a ulaştı.
yazar hakkındaJD.com'un Temel Platform Departmanı Teknik Direktörü Bao Yongcheng, Temel Platform Departmanı'nın küme teknik ekibini, JD'nin konteyner motoru platformu JDOS1.0'ın 2014'te piyasaya sürülmesinden, JD'nin tüm işlerini istikrarlı bir şekilde taşımak için sağlam bir birleşik bilgi işlem işletim platformu olarak mevcut JDOS2.0'a yönlendirdi. Şu anda, ana çalışma yönü JDOS2.0 araştırma ve geliştirme ve JD'nin birinci nesil yazılım tanımlı veri merkezinin inşasıdır.
Paskalya zamanı
2017'de yeni teknoloji trendi nasıl kontrol edilir? Yıllarca süren teknolojinin çökelmesi ve yeniden düzenlenmesinden sonra, büyük veri çerçeveleri ve makine öğrenimi çerçeveleri arasında nasıl seçim yapılır? Düşük gecikmeli sistem mimarisi, blok zinciri ve yeni finansal teknolojiler için en iyi uygulamalar nelerdir? Temmuz ayında, Güney Çin'deki en büyük teknoloji şöleni olan Shenzhen'de InfoQ altında sizleri bekliyor! Sınırlı bir süre için% 30 indirimli ArchSummit, daha fazlasını öğrenmek için "Orijinal metni okuyun" u tıklayın!
Okumak için aşağıdaki resme tıklayın
Tencent HTTPS performans optimizasyonu uygulaması
