platform oluşturmayı kolaylaştırmanıza olanak tanır Bulut hizmet sağlayıcılarının altyapısı, sanallaştırma platformları veya yalın donanım sistemleri dahil. Gerçek anlamda bulut tabanlı bir platform oluşturmak için kullanılan tüm öğelerin sıkı kontrolünü ele almamız ve böylece karmaşık bir otomasyon sürecinin güvenilirliğini artırmamız gerekiyordu.
Bariz çözüm standart olarak Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux'un bir çeşidi) ve CRI-O'yu kullanmaktı ve işte nedeni...
Yelken konusu, Kubernetes ve konteynerlerin çalışmalarını açıklarken analojiler bulmak için çok iyi bir konu olduğundan, bir örnek kullanarak CoreOS ve CRI-O'nun çözdüğü iş sorunları hakkında konuşmaya çalışalım. . 1803 yılında Marc Brunel, büyüyen İngiliz donanmasının ihtiyaçları için 100 arma bloğu üretmekle görevlendirildi. Arma bloğu, halatları yelkenlere bağlamak için kullanılan bir arma türüdür. 19. yüzyılın başlarına kadar bu bloklar elle yapılıyordu ancak Brunel, üretimi otomatikleştirmeyi başardı ve takım tezgahları kullanarak standart bloklar üretmeye başladı. Bu sürecin otomasyonu, ortaya çıkan blokların temelde aynı olması, kırılırsa kolayca değiştirilebilmesi ve büyük miktarlarda üretilebilmesi anlamına geliyordu.
Şimdi Brunel'in bu işi 20 farklı gemi modeli (Kubernetes versiyonları) ve tamamen farklı deniz akıntıları ve rüzgarlara sahip beş farklı gezegen (bulut sağlayıcıları) için yapmak zorunda kaldığını hayal edin. Ayrıca kaptanlar (kümelerin işleyişini yöneten operatörler) açısından navigasyonun yapıldığı gezegenlere bakılmaksızın tüm gemilerin (OpenShift kümeleri) aynı şekilde davranması gerekiyordu. Denizcilik benzetmesine devam edersek, gemi kaptanları gemilerinde ne tür arma bloklarının (CRI-O) kullanıldığını hiç umursamazlar - onlar için asıl önemli olan bu blokların güçlü ve güvenilir olmasıdır.
Bir bulut platformu olarak OpenShift 4 de benzer bir iş sorunuyla karşı karşıya. Düğümlerden birinde bir arıza olması durumunda veya kümeyi ölçeklendirirken, küme oluşturma sırasında yeni düğümler oluşturulmalıdır. Yeni bir düğüm oluşturulduğunda ve başlatıldığında, CRI-O dahil kritik ana bilgisayar bileşenlerinin buna göre yapılandırılması gerekir. Her üretimde olduğu gibi başlangıçta “hammadde” temin edilmesi gerekmektedir. Gemilerde ham maddeler metal ve ahşaptır. Ancak bir OpenShift 4 kümesinde kapsayıcıları dağıtmak için bir ana bilgisayar oluşturulması durumunda, girdi olarak yapılandırma dosyalarına ve API tarafından sağlanan sunuculara sahip olmanız gerekir. OpenShift daha sonra tüm yaşam döngüsü boyunca gerekli otomasyon seviyesini sağlayarak son kullanıcılara gerekli ürün desteğini sunacak ve böylece platforma yapılan yatırımın karşılığını alacak.
OpenShift 4, tüm büyük bulut bilişim sağlayıcıları, sanallaştırma platformları ve hatta yalın donanım sistemleri için platformun tüm yaşam döngüsü boyunca (sürüm 4.X için) sistemi rahatlıkla güncelleme olanağı sağlayacak şekilde oluşturuldu. Bunu yapmak için, değiştirilebilir öğeler temelinde düğümler oluşturulmalıdır. Bir küme, Kubernetes'in yeni bir sürümünü gerektirdiğinde CoreOS'ta ilgili CRI-O sürümünü de alır. CRI-O sürümü doğrudan Kubernetes'e bağlı olduğundan test, sorun giderme veya destek amaçlı permütasyonlar büyük ölçüde basitleştirilir. Ayrıca bu yaklaşım, son kullanıcılar ve Red Hat için maliyetleri de azaltıyor.
Bu, Kubernetes kümeleri hakkında temelde yeni bir düşünme biçimidir ve bazı çok yararlı ve ilgi çekici yeni özelliklerin planlanmasının temelini oluşturur. CRI-O (Konteyner Çalışma Zamanı Arayüzü - Açık Konteyner Girişimi, kısaltılmış CRI-OCI), OpenShift ile çalışmak için gerekli olan düğümlerin toplu oluşturulmasında en başarılı seçim olduğu ortaya çıktı. CRI-O, OpenShift kullanıcılarına daha önce kullanılan Docker motorunun yerini alacak – evet, doğru duydunuz – özellikle Kubernetes ile çalışmak üzere oluşturulmuş sıkıcı bir konteyner motoru.
Açık konteynerlerin dünyası
Dünya uzun süredir açık konteynerlere yöneliyor. İster Kubernetes'te ister daha düşük düzeylerde olsun, her düzeyde bir inovasyon ekosistemiyle sonuçlanır.
Her şey Açık Konteynerler Girişimi'nin oluşturulmasıyla başladı . Çalışmanın bu erken aşamasında konteyner spesifikasyonları oluşturuldu и . Bu, araçların tek bir standart kullanabilmesini sağladı ve onlarla çalışmak için birleşik bir format. Özellikler daha sonra eklendi kullanıcıların kolayca paylaşım yapmasına olanak tanır .
Kubernetes topluluğu daha sonra takılabilir bir arayüz için tek bir standart geliştirdi. . Bu sayede Kubernetes kullanıcıları Docker'ın yanı sıra çeşitli motorları da konteynerlerle çalışacak şekilde bağlayabildi.
Red Hat ve Google'daki mühendisler, CRI protokolü üzerinden Kubelet isteklerini kabul edebilecek bir konteyner motoruna yönelik pazar ihtiyacını gördüler ve yukarıda bahsedilen OCI spesifikasyonlarıyla uyumlu konteynerleri piyasaya sürdüler. Bu yüzden . Ama kusura bakmayın, bu materyalin CRI-O'ya ithaf edileceğini söylememiş miydik? Aslında öyle, sadece piyasaya sürülmesiyle birlikte projenin adı CRI-O olarak değiştirildi.
Şek. 1.
CRI-O ve CoreOS ile yenilik
OpenShift 4 platformunun piyasaya sürülmesiyle birlikte değişti Platformda varsayılan olarak kullanılan Docker'ın yerini CRI-O aldı ve Kubernetes'e paralel gelişen bir konteyneri çalıştırmak için uygun maliyetli, stabil, basit ve sıkıcı bir ortam sundu. Bu, küme desteğini ve yapılandırmasını büyük ölçüde basitleştirir. Konteyner motorunun ve ana bilgisayarın konfigürasyonunun yanı sıra bunların yönetimi de OpenShift 4'te otomatik hale geliyor.
Bekle, bu nasıl?
Doğru, OpenShift 4'ün gelişiyle birlikte artık bireysel ana bilgisayarlara bağlanmaya ve bir konteyner motoru kurmaya, depolamayı yapılandırmaya, arama sunucularını yapılandırmaya veya bir ağ yapılandırmaya gerek yok. OpenShift 4 platformu, OpenShift XNUMX platformunu kullanacak şekilde tamamen yeniden tasarlandı. yalnızca son kullanıcı uygulamaları açısından değil, aynı zamanda görüntüleri dağıtma, sistemi yapılandırma veya güncellemeleri yükleme gibi platform düzeyindeki temel işlemler açısından da.
Kubernetes her zaman kullanıcıların istenen durumu tanımlayarak ve kullanarak uygulamaları yönetmesine olanak tanımıştır. Gerçek durumun hedef duruma mümkün olduğunca yakın olmasını sağlamak için. Bu hem geliştirme hem de operasyon açısından büyük fırsatlar yaratıyor. Geliştiriciler gerekli durumu şu şekilde tanımlayabilir: operatöre YAML veya JSON dosyası biçiminde gönderilir ve ardından operatör üretim ortamında gerekli uygulama örneğini oluşturabilir ve bu örneğin çalışma durumu, belirtilen duruma tamamen karşılık gelecektir.
OpenShift 4, platformdaki Operatörleri kullanarak bu yeni paradigmayı (set ve gerçek durum kavramını kullanarak) RHEL CoreOS ve CRI-O yönetimine getiriyor. İşletim sistemi ve konteyner motorunun sürümlerini yapılandırma ve yönetme görevleri, sözde kullanılarak otomatikleştirilir. . MCO, küme yöneticisinin işini büyük ölçüde basitleştirir; temel olarak kurulumun son aşamalarını ve sonraki kurulum sonrası işlemleri (ikinci gün işlemleri) otomatikleştirir. Bütün bunlar OpenShift 4'ü gerçek bir bulut platformu haline getiriyor. Bu konuya biraz sonra gireceğiz.
Konteynerleri çalıştırma
Kullanıcılar, OpenShift platformunda CRI-O motorunu Teknik Önizleme durumundaki sürüm 3.7'den ve Genel Kullanılabilir durumundaki (şu anda desteklenmektedir) sürüm 3.9'dan itibaren kullanma fırsatına sahip oldu. Ayrıca Red Hat, yoğun bir şekilde OpenShift Online'da sürüm 3.10'dan beri. Tüm bunlar, CRI-O üzerinde çalışan ekibin büyük Kubernetes kümelerinde konteynerlerin toplu olarak başlatılması konusunda kapsamlı deneyim kazanmasına olanak sağladı. Kubernetes'in CRI-O'yu nasıl kullandığına dair temel bir anlayışa sahip olmak için mimarinin nasıl çalıştığını gösteren aşağıdaki resme bakalım.
Pirinç. 2. Kubernetes kümesinde konteynerler nasıl çalışır?
CRI-O, yeni düğümleri başlatırken ve OpenShift platformunun yeni sürümlerini yayınlarken tüm üst düzeyi senkronize ederek yeni konteyner ana bilgisayarlarının oluşturulmasını basitleştirir. Tüm platformun revizyonu, işlemsel güncellemelere/geri alma işlemlerine olanak tanır ve ayrıca konteyner kuyruk çekirdeği, konteyner motoru, düğümler (Kubelet'ler) ve Kubernetes Ana düğümü arasındaki bağımlılıklarda kilitlenmeleri önler. Tüm platform bileşenlerinin kontrol ve sürüm oluşturma ile merkezi olarak yönetilmesi sayesinde, A durumundan B durumuna her zaman açık bir yol vardır. Bu, güncelleme sürecini basitleştirir, güvenliği artırır, performans raporlamasını iyileştirir ve güncelleme ve yeni sürümlerin kurulum maliyetlerinin azaltılmasına yardımcı olur. .
Yedek elemanların gücünün gösterilmesi
Daha önce de belirtildiği gibi, OpenShift 4'te konteyner ana bilgisayarını ve konteyner motorunu yönetmek için Makine Yapılandırma Operatörünün kullanılması, daha önce Kubernetes platformunda mümkün olmayan yeni bir otomasyon düzeyi sağlar. Yeni özellikleri göstermek için crio.conf dosyasında nasıl değişiklik yapabileceğinizi göstereceğiz. Terminolojinin kafanızı karıştırmasını önlemek için sonuçlara odaklanmaya çalışın.
İlk olarak, konteyner çalışma zamanı yapılandırması ( Container Runtime Config) adı verilen şeyi oluşturalım. Bunu, CRI-O yapılandırmasını temsil eden bir Kubernetes kaynağı olarak düşünün. Gerçekte bu, OpenShift kümesinin bir parçası olarak RHEL CoreOS makinesine dağıtılan herhangi bir yapılandırma olan MachineConfig adı verilen bir şeyin özel bir sürümüdür.
ContainerRuntimeConfig adı verilen bu özel kaynak, küme yöneticilerinin CRI-O'yu yapılandırmasını kolaylaştırmak için oluşturuldu. Bu araç, MachineConfigPool ayarlarına bağlı olarak yalnızca belirli düğümlere uygulanabilecek kadar güçlüdür. Bunu aynı amaca hizmet eden bir grup makine olarak düşünün.
/etc/crio/crio.conf dosyasında değiştireceğimiz son iki satıra dikkat edin. Bu iki satır crio.conf dosyasındaki satırlara çok benzer, bunlar:
vi ContainerRuntimeConfig.yaml
Sonuç:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Şimdi bu dosyayı Kubernetes kümesine gönderelim ve gerçekten oluşturulduğunu kontrol edelim. Lütfen işlemin diğer Kubernetes kaynaklarıyla tamamen aynı olduğunu unutmayın:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Sonuç:
NAME AGE
set-log-and-pid 22h
ContainerRuntimeConfig'i oluşturduktan sonra, bu yapılandırmayı kümedeki belirli bir makine grubuna uygulamak istediğimizi Kubernetes'e bildirmek için MachineConfigPool'lardan birini değiştirmemiz gerekir. Bu durumda ana düğümler için MachineConfigPool'u değiştireceğiz:
oc edit MachineConfigPool/master
Sonuç (açıklık sağlamak için ana öz bırakılmıştır):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Bu noktada MCO, küme için yeni bir crio.conf dosyası oluşturmaya başlar. Bu durumda tamamen tamamlanmış konfigürasyon dosyası Kubernetes API kullanılarak görüntülenebilir. ContainerRuntimeConfig'in yalnızca MachineConfig'in özel bir sürümü olduğunu unutmayın; dolayısıyla sonucu MachineConfigs'teki ilgili satırlara bakarak görebiliriz:
oc get MachineConfigs | grep rendered
Sonuç:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Lütfen ana düğümler için ortaya çıkan yapılandırma dosyasının orijinal yapılandırmalardan daha yeni bir sürüm olduğunu unutmayın. Görüntülemek için aşağıdaki komutu çalıştırın. Bu arada, bunun belki de Kubernetes tarihindeki en iyi kısa cümlelerden biri olduğunu belirtelim:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Sonuç:
pids_limit = 2048
Şimdi konfigürasyonun tüm ana düğümlere uygulandığından emin olalım. İlk önce kümedeki düğümlerin bir listesini alıyoruz:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Şimdi kurulu dosyaya bakalım. ContainerRuntimeConfig kaynağında belirttiğimiz pid ve debug direktiflerine göre dosyanın yeni değerlerle güncellendiğini göreceksiniz. Zarafetin kendisi:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Sonuç:
...
pids_limit = 2048
...
log_level = "debug"
...
Kümede yapılan tüm bu değişiklikler SSH çalıştırılmadan yapıldı. Tüm işler Kuberentes ana düğümüne erişilerek yapıldı. Yani bu yeni parametreler yalnızca ana düğümlerde yapılandırılmıştır. Çalışan düğümler değişmedi; bu, Kubernetes metodolojisinin, değiştirilebilir öğelere sahip konteyner ana bilgisayarları ve konteyner motorlarıyla ilişkili olarak belirtilen ve gerçek durumları kullanmanın faydalarını gösteriyor.
Yukarıdaki örnek, üç üretim düğümüne sahip küçük bir OpenShift Container Platform 4 kümesinde veya 3000 düğüme sahip büyük bir üretim kümesinde değişiklik yapma yeteneğini gösterir. Her durumda, iş miktarı aynı olacak ve çok az olacaktır; yalnızca ContainerRuntimeConfig dosyasını yapılandırın ve MachineConfigPool'daki bir etiketi değiştirin. Ve bunu, yaşam döngüsü boyunca Kubernetes'i çalıştıran OpenShift Container Platform 4.X'in herhangi bir sürümüyle yapabilirsiniz.
Çoğu zaman teknoloji şirketleri o kadar hızlı gelişiyor ki, temel bileşenler için neden belirli teknolojileri seçtiğimizi açıklayamıyoruz. Konteyner motorları tarihsel olarak kullanıcıların doğrudan etkileşimde bulunduğu bileşen olmuştur. Konteynerlerin popülaritesi doğal olarak konteyner motorlarının ortaya çıkışıyla başladığından, kullanıcılar sıklıkla bunlara ilgi göstermektedir. Red Hat'in CRI-O'yu seçmesinin bir başka nedeni de budur. Konteynerler artık orkestrasyona odaklanılarak gelişiyor ve OpenShift 4 ile çalışırken CRI-O'nun en iyi deneyimi sağladığını gördük.
Kaynak: habr.com