🥇Kubernetes kümesindeki güncel olmayan bir özellik dalını kaldırma

Merhaba! Özellik dalı (diğer adıyla dağıtım önizlemesi, uygulamayı inceleme) - bu, yalnızca ana dalın dağıtıldığı değil, aynı zamanda her çekme isteğinin benzersiz bir URL'ye dağıtıldığı zamandır. Kodun üretim ortamında çalışıp çalışmadığını kontrol edebilirsiniz; özellik diğer programcılara veya ürün uzmanlarına gösterilebilir. Bir çekme isteğinde çalışırken, eski koda yönelik her yeni taahhüt geçerli dağıtımı silinir ve yeni kod için yeni dağıtım kullanıma sunulur. Bir çekme isteğini ana dalla birleştirdiğinizde sorular ortaya çıkabilir. Artık özellik dalına ihtiyacınız yoktur ancak Kubernetes kaynakları hâlâ kümededir.

Özellik dalları hakkında daha fazla bilgi

Kubernetes'te özellik dalları oluşturmaya yönelik yaklaşımlardan biri ad alanlarını kullanmaktır. Kısacası üretim konfigürasyonu şöyle görünür:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

Bir özellik dalı için, tanımlayıcısı (örneğin, çekme isteği numarası) ve bir tür önek/sonek (örneğin, -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

Genel olarak yazdım Kubernetes Operatörü (küme kaynaklarına erişimi olan bir uygulama), Github'daki projeye bağlantı. Eski özellik dallarına ait ad alanlarını kaldırır. Kubernetes'te bir ad alanını silerseniz o ad alanındaki diğer kaynaklar da otomatik olarak silinir.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

Özellik dallarının bir kümeye nasıl uygulanacağını okuyabilirsiniz burada и burada.

Motivasyon

Sürekli entegrasyona sahip tipik bir çekme isteği yaşam döngüsüne bakalım (continuous integration):

Şubeye yeni bir taahhüt gönderiyoruz.
Derlemede linterler ve/veya testler çalıştırılır.
Kubernetes çekme isteği yapılandırmaları anında oluşturulur (örneğin numarası bitmiş şablona eklenir).
Kubectl application kullanılarak yapılandırmalar kümeye eklenir (dağıtım).
Çekme isteği ana dalla birleştirilir.

Bir çekme isteğinde çalışırken, eski koda yönelik her yeni taahhüt geçerli dağıtımı silinir ve yeni kod için yeni dağıtım kullanıma sunulur. Ancak bir çekme isteği ana dalla birleştirildiğinde yalnızca ana dal oluşturulacaktır. Sonuç olarak, çekme isteğini zaten unuttuğumuz ve Kubernetes kaynaklarının hala kümede olduğu ortaya çıktı.

Nasıl kullanılır?

Projeyi aşağıdaki komutla yükleyin:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

Aşağıdaki içeriğe sahip bir dosya oluşturun ve aracılığıyla yükleyin kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

Parametre ad alanıSubstring diğer ad alanlarından gelen çekme istekleri için ad alanlarını filtrelemek gerekir. Örneğin, küme aşağıdaki ad alanlarına sahipse: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, o zaman silinmeye aday olacaklar habr-back-end-pr-17, habr-back-end-pr-33.

Parametre AfterDaysWithoutDeploy eski ad alanlarını silmek gerekiyor. Örneğin, ad alanı oluşturulmuşsa 3 дня 1 час geri ve parametre şunu gösterir: 3 дня, bu ad alanı silinecek. Ad alanı yaratıldığında da ters yönde çalışır. 2 дня 23 часа geri ve parametre şunu gösterir: 3 дня, bu ad alanı silinmeyecek.

Bir parametre daha var; tüm ad alanlarının ne sıklıkta taranacağından ve dağıtım yapılmayan günlerin kontrol edilmesinden sorumludur - checkEveryMinutes. Varsayılan olarak eşittir 30 минутам.

Bu nasıl çalışıyor

Pratikte ihtiyacınız olacak:

liman işçisi izole bir ortamda çalışmak için.
Miniküp yerel olarak bir Kubernetes kümesi oluşturacak.
Kubectl — küme yönetimi için komut satırı arayüzü.

Yerel olarak bir Kubernetes kümesi oluşturuyoruz:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

belirtmek kubectl varsayılan olarak yerel kümeyi kullan:

$ kubectl config use-context minikube
Switched to context "minikube".

Üretim ortamı için yapılandırmaları indirin:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

Üretim yapılandırmaları eski ad alanlarını kontrol edecek şekilde yapılandırıldığından ve yeni oluşturulan kümemizde bunlara sahip olmadığından, ortam değişkenini değiştireceğiz IS_DEBUG üzerinde true. Bu değer ile parametre afterDaysWithoutDeploy dikkate alınmaz ve ad alanları, yalnızca alt dizenin () oluşması durumunda dağıtım yapılmayan günler boyunca kontrol edilmez.-pr-).

Eğer açıksan Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

Eğer açıksan macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

Projenin kurulumu:

$ kubectl apply -f stale-feature-branch-production-configs.yml

Kümede bir kaynağın görünüp görünmediğini kontrol etme StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

Kümede bir operatörün görünüp görünmediğini kontrol ediyoruz:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

Loglarına bakarsanız kaynakları işlemeye hazır StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

Hazır kurulum yapıyoruz fixtures bir kaynak için (küme kaynaklarının modellenmesi için hazır konfigürasyonlar) StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

Yapılandırmalar, bir alt dizeye sahip ad alanlarının aranmasını belirtir -pr- bir kez 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

Operatör yanıt verdi ve ad alanlarını kontrol etmeye hazır:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

Ayarlamak fixtures, iki ad alanı içeren (project-pr-1, project-pr-2) ve onları deployments, services, ingress, ve benzeri:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

Yukarıdaki tüm kaynakların başarıyla oluşturulduğunu kontrol ediyoruz:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

Dahil ettiğimizden beri debug, ad alanları project-pr-1 и project-pr-2, bu nedenle diğer tüm kaynakların, parametre dikkate alınmadan derhal silinmesi gerekecektir. afterDaysWithoutDeploy. Bu, operatör günlüklerinde görülebilir:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

Kaynakların kullanılabilirliğini kontrol ederseniz, bunlar şu durumda olacaktır: Terminating (silme işlemi) veya zaten silinmiş (komut çıkışı boş).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

Oluşturma işlemini tekrarlayabilirsiniz fixtures birkaç kez uygulayın ve bir dakika içinde kaldırıldıklarından emin olun.

alternatifleri

Clusterda çalışan bir operatörün yerine ne yapılabilir? Birkaç yaklaşım var, hepsi kusurlu (ve eksiklikleri öznel) ve belirli bir proje için en iyisinin ne olduğuna herkes kendisi karar veriyor:

Ana dalın sürekli entegrasyon oluşturması sırasında özellik dalını silin.
- Bunu yapmak için hangi çekme isteğinin oluşturulmakta olan taahhütle ilgili olduğunu bilmeniz gerekir. Özellik dalı ad alanı, çekme isteği tanımlayıcısını - numarasını veya dalın adını - içerdiğinden, tanımlayıcının her zaman taahhütte belirtilmesi gerekecektir.
- Ana dal yapıları başarısız oluyor. Örneğin, şu aşamalara sahipsiniz: projeyi indirin, testleri çalıştırın, projeyi oluşturun, yayın yapın, bildirim gönderin, son çekme isteğinin özellik dalını temizleyin. Bir bildirim gönderilirken derleme başarısız olursa kümedeki tüm kaynakları manuel olarak silmeniz gerekir.
- Uygun bağlam olmadan ana yapıdaki özellik dallarının silinmesi açık değildir.
Web kancalarını kullanma (örnek).
- Bu sizin yaklaşımınız olmayabilir. Örneğin, Jenkins, yalnızca bir işlem hattı türü, yapılandırmalarını kaynak koduna kaydetme özelliğini destekler. Web kancalarını kullanırken bunları işlemek için kendi komut dosyanızı yazmanız gerekir. Bu betiğin bakımı zor olan Jenkins arayüzüne yerleştirilmesi gerekecek.
yazmak Cronjob ve bir Kubernetes kümesi ekleyin.
- Yazmaya ve desteğe zaman ayırma.
- Operatör zaten benzer tarzda çalışıyor, belgeleniyor ve destekleniyor.

Makaleye gösterdiğiniz ilgiden dolayı teşekkür ederiz. Github'daki projeye bağlantı.

Kaynak: habr.com

Kubernetes kümesindeki güncel olmayan bir özellik dalını kaldırma

Özellik dalları hakkında daha fazla bilgi

Motivasyon

Nasıl kullanılır?

Bu nasıl çalışıyor

alternatifleri

Yorum ekle Cevabı iptal