Kubernetes'te yapılandırma eşleme güncellendiğinde bölmeler yeniden başlatılsın mı?

Yapılandırma haritaları değiştirildiğinde / güncellendiğinde dağıtımlarla ilişkili Kubernetes bölmelerini ve kapsüllerini otomatik olarak nasıl yeniden başlatırım?

Bir yapılandırma haritası değiştiğinde bölmeleri otomatik olarak yeniden başlatma yeteneği hakkında konuşulduğunu biliyorum, ancak bildiğim kadarıyla bu henüz Kubernetes 1.2'de mevcut değil.

Yani (sanırım) yapmak istediğim şey, yapılandırma haritasını tüketen bölmelerle ilişkili dağıtım kaynağının "sürekli yeniden başlatılması" . Gerçek şablondaki hiçbir şeyi değiştirmeden Kubernetes'te bir dağıtımın sürekli olarak yeniden başlatılmasını zorlamak mümkün müdür ve eğer öyleyse nasıl? Şu anda bunu yapmanın en iyi yolu bu mu yoksa daha iyi bir seçenek var mı?

Yapılandırma haritası güncellemesinde bir bölmeyi işaretlemek, çalışmalardaki bir özelliktir ( https://github.com/kubernetes/kubernetes/issues/22368 ).

Her zaman, confimap'in değiştiğini fark eden ve uygulamanızı yeniden başlatan özel bir pid1 yazabilirsiniz.

Ayrıca, örneğin: aynı konfigürasyon haritasını 2 konteynere monte edebilirsiniz, ikinci konteynere konfigürasyon haritası içeriklerinin karması değiştiğinde başarısız olan bir http sağlık kontrolünü ifşa edebilirsiniz ve bunu birinci konteynerin canlılık araştırması olarak taşıyabilirsiniz (çünkü konteynerler bir pod aynı ağ ad alanını paylaşır). Kubelet, prob başarısız olduğunda sizin için ilk konteynırınızı yeniden başlatacaktır.

Elbette, bölmelerin hangi düğümlerde olduğunu umursamıyorsanız, onları silebilirsiniz ve çoğaltma denetleyicisi bunları sizin için "yeniden başlatır".

Bu soruna şu anki en iyi çözüm ( kardeş yanıtında https://github.com/kubernetes/kubernetes/issues/22368 adresinde derinlemesine başvurulmuştur ) Dağıtımları kullanmak ve ConfigMap'lerinizin değişmez olduğunu düşünmektir.

Yapılandırmanızı değiştirmek istediğinizde, yapmak istediğiniz değişikliklerle yeni bir ConfigMap oluşturun ve dağıtımınızı yeni ConfigMap'e yönlendirin. Yeni yapılandırma bozulursa Dağıtım, çalışan ReplicaSet'inizi küçültmeyi reddeder. Yeni yapılandırma çalışıyorsa, eski ReplicaSet'iniz 0 kopyaya ölçeklenecek ve silinecek ve yeni yapılandırma ile yeni bölmeler başlatılacaktır.

ConfigMap'i yerinde düzenlemek kadar hızlı değil, ama çok daha güvenli.

https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#user-content-automatically-roll-deployments-when-configmaps-or-secrets-change

Çoğu zaman, yapılandırma dosyaları veya gizli diziler, kapsayıcılara yapılandırma dosyaları olarak eklenir. Uygulamaya bağlı olarak, bunların daha sonra güncellenmesi durumunda yeniden başlatma gerekebilir helm upgrade, ancak dağıtım özelliğinin kendisi değişmediyse, uygulama eski yapılandırmayla çalışmaya devam ederek tutarsız bir dağıtımla sonuçlanır.

sha256sumFonksiyon ile birlikte kullanılabilir includebaşka Spec değişirse şablon bölüm güncellenmektedir bir dağıtımları sağlamak için işlevin:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

Benim durumumda, bazı nedenlerden dolayı $.Template.BasePathişe yaramadı ama işe yarıyor $.Chart.Name:

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

Bunu yapmanın en iyi yolu Reloader'ı çalıştırmak

İzlenecek konfigürasyon haritalarını veya sırları tanımlamanıza olanak tanır, güncellendiklerinde, dağıtımınızın sürekli güncellemesi gerçekleştirilir. İşte bir örnek:

Bir dağıtımınız foove adlı bir ConfigMap'iniz var foo-configmap. Yapılandırma haritası her değiştirildiğinde dağıtım bölmelerini döndürmek istiyorsunuz. Reloader'ı şunlarla çalıştırmanız gerekir:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

Ardından, dağıtımınızda bu ek açıklamayı belirtin:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

Dağıtımınızla alakalı olmayan bir meta veri etiketini güncelleyebilirsiniz. sıralı güncellemeyi tetikleyecek

Örneğin:

metadata:
  labels:
    configmap-version: 1

Dağıtımın bir alt grafikte olduğu ve onu kontrol eden değerlerin üst grafiğin değerler dosyasında olduğu bir sorun vardı. Yeniden başlatmayı tetiklemek için kullandığımız şey buydu:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

Açıkçası bu, herhangi bir değer değişikliğinde yeniden başlatmayı tetikleyecektir, ancak durumumuz için işe yarar. Başlangıçta alt grafikte olan şey, yalnızca alt grafiğin kendisindeki config.yaml değiştiğinde işe yarar:

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

Kuantumların çözümünü yapıyorum ve mükemmel çalışıyor. Ama anlamadığım şey, kapsülün aslında yeniden başlamadığı ... Bölme hala aynı ama değişim var!

Örneğin: Kapsül 50 dakikadan beri çalışıyor ve bir şeyi değiştiriyorum ve değişiklik çevrimiçi. Onu tarayıcımda görebiliyorum ve bölme hala + 50 dakika çalışıyor !! Helm3 kullanıyorum ... Configmap'i yeniden güncellemeden bunu neyin mümkün kıldığını biliyor musunuz?

Başka bir yol da onu Dağıtım'ın komut bölümüne yapıştırmaktır:

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

Alternatif olarak, daha ConfigMap benzeri hale getirmek için, yalnızca o yapılandırmayı commandbölümde barındıracak ve kubectl createadına benzersiz bir 'sürüm' eklerken (içeriğin bir karmasını hesaplamak gibi) ve tüm bu yapılandırmayı kullanan dağıtımlar:

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

kubectl-apply-config.shÇalışmaya başlarsa muhtemelen göndereceğim .

(bunu yapma; çok kötü görünüyor)