Eski Kubernetes Görevleri Nasıl Temizlenir
Web ajansı » Dijital haberler » Kubernetes Sunucu Tarafı Uygulaması (SSA) nedir?

Kubernetes Sunucu Tarafı Uygulaması (SSA) nedir?

Sunucu Tarafında Uygulama (SSA), Ağustos 1.22'de v2021'den beri Kubernetes'te genel olarak kullanıma sunulmuştur. kubectl apply sunucuda sipariş.

Bu makalede, SSA'nın nasıl çalıştığı ve önceki istemci tarafı uygulama (CSA) yaklaşımına göre neden tercih edildiği açıklanmaktadır. Kümenizdeki nesnelerde değişiklik yaparken SSA'yı nasıl etkinleştireceğinizi de öğreneceksiniz.

Bildirime Dayalı Güncellemeleri Anlama

La kubectl apply Komut, nesnelerde bildirime dayalı güncellemeler gerçekleştirir. Kubernet'lerden belirli alanları değiştirmelerini istemek yerine, nesnenin görünmesini istediğiniz şekilde tam bir temsilini sağlarsınız. Sistem, kümenizin mevcut durumundan farkları otomatik olarak hesaplar. Ardından, durumu bildirim dosyanız tarafından ifade edilen istenen duruma dönüştüren eylemleri gerçekleştirecektir.

İşte basit bir pod bildirimi:

API Sürümü: v1
tür: Koza
meta:
  isim: nginx
spec:
  kaplar:
    - isim: nginx
      görüntü: nginx: en son

operasyon kubectl apply bu bildirim ile çalıştıran yeni bir bölme başlatacak nginx:latest görüntü. Kümenin mevcut durumu ile istenen durum arasındaki fark açıktır: daha önce hiçbirinin olmadığı bir Bölme oluşturulmuştur. nginx Nom.

Daha sonra bölme özelliklerinden birini değiştirerek bildirimi düzenleyebilirsiniz:

API Sürümü: v1
tür: Koza
meta:
  isim: nginx
spec:
  kaplar:
    - isim: nginx
      görüntü: nginx:1.23

Bu sefer, mevcut durum ile istenen durum arasındaki fark daha az önemlidir. bu kubectl apply komut, gözden geçirilmiş sürümü algılar image ve pod yapılandırmanızı buna göre güncelleyin.

İstemci tarafı uygulamayla ilgili sorunlar

Değişikliklerin ertelenmesi ve çakışmaların çözülmesi bildirime dayalı güncellemelerin en önemli parçasıdır. Bu işlem varsayılan olarak Kubectl'de çalışır. İstemci, sunucudaki mevcut nesneyi tanımlamaktan ve değişikliklerini karşılaştırmaktan sorumludur.

La kubectl apply komut bir yazar last-applied-configuration Bu işlemi kolaylaştırmak için nesneler üzerinde açıklama. Etkin nesnede var olan ancak gelen bildirimden kaldırılmış alanları tanımlar. İstemci daha sonra yeni duruma ulaşmak için bunları nesneden nasıl sileceğini bilir.

Bu yaklaşım, birden çok aracı aynı nesneyi güncellediğinde sorunludur. Örneğin, tek bir nesne hem Kubectl hem de kümenizdeki özel bir denetleyici tarafından değiştirilebilir. İstemci tarafı uygulaması, hangi aracının bir alanı değiştirdiğini veya bir çakışmanın ne zaman meydana geldiğini bilemez. Sadece yerel bildiriminizi mevcut nesneninkiyle karşılaştırır. last-applied-configuration ve tüm değişikliklerde birleşir.

İstemci tarafı uygulaması da özünde Kubectl'e bağlıdır. Kendi bildirime dayalı güncellemelerini gerçekleştirmek isteyen üçüncü taraf araçlar, Kubectl'i çağırmalı veya Kubectl'i yeniden oluşturmalıdır. apply sıfırdan mantık. Bu iki seçeneğin hiçbiri özellikle ideal değildir.

Sunucu tarafı uygulama işlemi

CSA ile ilgili temel sorun, güncelliğini yitirmiş yerel bildirimlerin asla algılanmamasıdır. Çalıştırmadan önce başka bir aplikatör bir nesneyi değiştirirse kubectl apply, eski yerel düzeltmeleriniz doğru yenilerinin üzerine yazabilir. SSA etkinleştirildiğinde, çakışma algılanacak ve güncelleme engellenecektir. Yerel durumunuzun güncel tutulmasını sağlayan merkezi bir sistemdir.

SSA, nesnelerinizin her alanı hakkında bilgi depolayan bir kontrol düzlemi mekanizması ekleyerek çalışır. yerini alır last-applied-configuration yeni bir ek açıklama metadata.managedFields alan. Nesnenizin her alanı, managedFields.

Alanlar, sahibi olan müşteriyi tanımlayan bir "saha yöneticisine" atanır. Kubectl ile bir bildirim uygularsanız, Kubectl atanmış işleyici olacaktır. Bir alanın işleyicisi, nesnelerinizi güncelleyen harici bir denetleyici veya entegrasyon da olabilir.

Yöneticilerin diğer kişilerin alanlarını güncellemesi yasaktır. ile bir alanı düzenleyemezsiniz. kubectl apply şu anda başka bir denetleyiciye aitse. Bu birleştirme çakışmalarını çözmek için üç strateji mevcuttur:

  • Değerin üzerine yazmaya zorla – Bazı durumlarda güncellemeyi zorlamak isteyebilirsiniz. Bu, değerini değiştirecek ve mülkiyeti yeni arazi yöneticisine devredecektir. Esas olarak, doldurdukları alanların yönetimini elinde tutması gereken denetleyiciler için tasarlanmıştır. ayarlayarak bir güncellemeyi manuel olarak zorlayabilirsiniz. --force-conflicts Kubectl'de bayrak.
  • Değerin üzerine yazma – Uygulayıcı, alanı yerel yapılandırmasından kaldırabilir ve ardından isteği tekrarlayabilir. Alan mevcut değerini koruyacaktır. Alanın silinmesi, sahipliği mevcut yöneticiye vererek çakışmayı çözer.
  • Paylaşım yönetimi – Uygulayıcı, yerel değerini sunucudaki mevcut değerle eşleşecek şekilde güncelleyebilir. Sahibi olduğunu iddia ederken talebi tekrarlarsa SSA, yönetimi mevcut yöneticiyle paylaşmasına izin verir. Bunun nedeni uygulayıcının alanın mevcut durumunu kabul etmesi, ancak gelecekte onu yönetmek isteyebileceğini belirtmesidir.

Bu yaklaşım geleneksel yaklaşımdan çok daha güçlüdür. kubectl apply. Yanlışlıkla üzerine yazmayı önler, denetleyicilerin kontrol ettikleri alanların sahipliğini güvenilir bir şekilde talep etmelerini sağlar ve tamamen bildirime dayalıdır. SSA, yalnızca nesnenin son tam durumunu kaydetmek yerine, farklı kullanıcıların bireysel alanları nasıl değiştirdiğini izler. Bu aynı zamanda dil veya dil ne olursa olsun artık uygulamayı herhangi bir araçta kullanabileceğiniz anlamına gelir. kubectl ikili kullanılabilirlik Operasyona nasıl başlarsanız başlayın aynı tutarlı sonuçları alacaksınız.

SSA'yı bugün kullanın

ayarlayarak SSA'yı etkinleştirebilirsiniz. --server-side Kubectl uygulamasını her çalıştırdığınızda işaretleyin:

$ kubectl Apply -f nginx.yaml --sunucu tarafında pod/nginx sunucu tarafında uygulandı

Komut çıkışı, SSA'nın kullanıldığını gösterecek şekilde değişir.

Nesnenin YAML bildirimini incelemek, desteklenen alanları ortaya çıkarır:

$ kubectl get pod nginx -o yaml apiVersion: v1 tür: Kapsül meta verisi: oluşturmaTimestamp: "2022-11-24T16:02:29Z" yönetilenFields: - apiVersion: v1 fieldType: FieldsV1 fieldV1: f:spec: f:containers: k: {"name":"nginx"}: .: {} f:image: {} f:name: {} yönetici: kubectl işlem: Uygulama zamanı: "2022-11-24T16:02:29Z" - apiVersion: v1 fieldType : FieldsV1 fieldV1: f:status: f:conditions: k:{"type":"ContainersReady"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":"Initialized"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{"type":" Ready"}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} f:containerStatuses: {} f:hostIP: {} f:phase: {} f:podIP: {} f:podIPs: .: {} k:{"ip":"10.244.0.186"}: .: {} f:ip: {} f:startTime: {} yönetici: kubelet işlemi: Güncelleme alt kaynak: durum zamanı: "2022-11-24T16:02:31Z" ...

Alanlar, sahibi olan yöneticiye göre gruplandırılır. Bu örnekte, spec Kubectl tarafından yönetilmektedir, çünkü Pod bu şekilde oluşturulmuştur. bu status Ancak, bölmeyi çalıştıran düğüm, bölmenin yaşam döngüsü boyunca bu alanın değerini değiştirdiği için alan Kubelet tarafından yönetilir.

SSA ayrıca denetleyicilerde kullanıma hazırdır. Nesneleri yeniden yapılandıranlar da dahil olmak üzere daha güçlü semantik ve yeni denetleyici türleri sağlar. Bu model, önce bir nesnenin alanlarını denetleyiciyi tatmin edecek şekilde sıfırdan yeniden yapılandırarak ve ardından sonucu sunucuya uygulayarak değişiklikleri ele alır. Bu, istenen değişikliği üretecek işlem sırasını manuel olarak oluşturmaktan daha doğal bir yöntemdir.

Bir nesnenin SSA ile yönetilip yönetilmediğini kontrol edin

Kubectl'de YAML bildirimini alarak bir nesnenin CSA mı yoksa SSA mı kullandığını kontrol edebilirsiniz:

$ kubectl, nginx -o yaml bölmesini al

eğer bir görürsen last-applied-configuration ek açıklama, nesneniz CSA tarafından yönetilir:

API Sürümü: v1
tür: Koza
meta:
  ek açıklamalar:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec": {"containers":[{"image":"nginx:latest","name":"nginx"}]}}
  oluşturmaZaman damgası: "2022-11-24T14:20:07Z"
  isim: nginx
  ad: varsayılan
  ...
...

Aşağıdaki durumlarda nesne için SSA kullanılmıştır: metadata.managedFields bunun yerine görünür:

API Sürümü: v1
tür: Koza
meta:
  oluşturmaZaman damgası: "2022-11-24T16:02:29Z"
  yönetilen Alanlar:
  - api Sürümü: v1
    alanlarTürü: AlanlarV1
    alanlarV1:
      f:özellik:
        f:kaplar:
          k:{"isim":"nginx"}:
            .: {}
            f:resim: {}
            f:isim: {}
    müdür: Kubectl
    operasyon: Tamam
    zaman: "2022-11-24T16:02:29Z"
    ...
  ...
...

Bir nesneyi basitçe ekleyerek veya çıkararak CSA ve SSA arasında taşıyabilirsiniz. --server-side bir sonraki çalıştırışınızda rapor verin kubectl apply. Kubernetes, last-applied-configuration içinde managedFields ve tersi.

Yerel bildiriminiz sunucudaki nesneden farklıysa, SSA yükseltmelerinde çakışmalar olabilir. Bu, aşağıdaki gibi zorunlu bir komut çalıştırdığınızda gerçekleşir. kubectl scale ou kubectl label nesne üzerindeki son uygulama işleminizden bu yana. SSA'ya dönüştürmeden önce yerel bildiriminizin etkin nesneyle tam olarak eşleştiğini doğrulamanız gerekir.

özet

Sunucu tarafı uygulaması, alanların Kubernetes kontrol düzlemi tarafından izlendiği bildirime dayalı bir nesne yönetimi yaklaşımıdır. Bu, güçlü çakışma algılamayı ve esnek çözüm stratejilerini kolaylaştırır. SSA, alanların herhangi bir uyarı olmaksızın yanlışlıkla üzerine yazılmasına izin veren istemci tarafı uygulama sınırlamalarını giderir.

SSA artık genel olarak kullanılabilir olsa da, her çalıştırdığınızda yine de manuel olarak belirtmeniz gerekir. kubectl apply. SSA'nın özellikle Kubectl'li insan operatörler ve bir denetleyici döngüsü gibi nesnelerin birkaç farklı işlem tarafından yönetildiği durumlarda yararlı olduğunu unutmayın. Yalnızca kullanırsanız, SSA'dan fazla yararlanamazsınız. kubectl apply nesneleri oluşturmak ve güncellemek için.

Gelecekteki bir Kubernetes sürümü, CSA'yı kaldırarak SSA'yı tek varsayılan seçenek haline getirmelidir. bu --server-side bayrak daha sonra gereksiz hale gelecektir.

★ ★ ★ ★ ★