21/11/2020 - KUBERNETES
Bu örnekte, uygulamamızı Kubernetes'e dağıtacağız ve en son dağıtımda bir şeyler ters giderse herhangi bir revizyona geri döneceğiz.
Önemli not: Belirli bir revizyona geri dönerken, mevcut olan bir docker imaj geri çekilir, bu nedenle her imajın kendisine ait bir etiketi bulunur. Bu nedenle her dağıtım için deployment.yaml içinde benzersiz bir etiketin kullanıldığına emin olun. Her kod iletiminde, docker imaj etiketinin benzersiz olduğundan emin olun. Eğer her zaman latest kullanılırsa, önce kodu manuel olarak geri döndürmeniz gerekecek ve imajı ileteceksiniz. Bu iyi bir yöntem değildir ve rollback işlemini amaçsız hale getirir. Kısacası her iletimde docker imajını git hash gibi eklerle etiketleyin ve deployment.yaml dosyasında kullanın.
Bir dağıtımın revizyon geçmişi ReplicaSets'te saklanır.
İsteğe bağlı olan .spec.revisionHistoryLimit anahtarı, rollback için kaç ReplicaSets tutulacağını belirler. Ne kadar çok ReplicaSets tutulursa, etcd ile daha fazla kaynak tüketilir, bu nedenle değeri fazla yüksek olmasın. Varsayılan olarak, 10 eski ReplicaSets korunacaktır.
revisionHistoryLimit'i 5'e ayarladık, böylece hiçbir zaman 5'ten fazla revizyonumuz olmayacak. Bakalım şu anda kümede ne var.
$ kubectl get deployments,replicasets,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/address-finder-deployment 1/1 1 1 9m20s
NAME DESIRED CURRENT READY AGE
replicaset.apps/address-finder-deployment-68dd5b79b8 0 0 0 9m
replicaset.apps/address-finder-deployment-56847c949b 0 0 0 3m
replicaset.apps/address-finder-deployment-7f9fdc5f48 1 1 1 17s
NAME READY STATUS RESTARTS AGE
pod/address-finder-deployment-7f9fdc5f48-wr94x 2/2 Running 0 17s
Yukarıda gördüğünüz gibi 3 ReplicaSet'imiz var. Dağıtım/yayın revizyonlarının ReplicaSets tarafından kontrol edildiği göz önüne alındığında, 3 revizyon geçmişimiz de olmalıdır. Kontrol edelim.
$ kubectl rollout history deployment address-finder-deployment
REVISION CHANGE-CAUSE
1
2
3
Pod'umuz bir web sunucusudur, bu nedenle v1, v2, v3 gibi test bir dize yazdırır. Şu anda v3 yazdırıyor ancak bunun yerine v2 mesajına geri dönmek istiyoruz. Revizyonun en son ReplicaSet'e ait olduğunu varsayabilirsiniz; bu 3, çünkü en alttaki en son revizyondur. Ancak, her zaman durum böyle değildir, bu yüzden önce emin olalım.
$ kubectl describe replicaset address-finder-deployment-7f9fdc5f48 | grep revision
deployment.kubernetes.io/revision: 3
Şimdi hangi revizyonda olduğumuzdan eminiz. Önceki revizyon olan 2'ye geri dönelim.
$ kubectl rollout undo deployment address-finder-deployment --to-revision=2
deployment.apps/address-finder-deployment rolled back
Bakalım şu anda kümede ne varmış.
$ kubectl get deployments,replicasets,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/address-finder-deployment 1/1 1 1 22m
NAME DESIRED CURRENT READY AGE
replicaset.apps/address-finder-deployment-68dd5b79b8 0 0 0 22m
replicaset.apps/address-finder-deployment-56847c949b 1 1 1 15m
replicaset.apps/address-finder-deployment-7f9fdc5f48 0 0 0 13m
NAME READY STATUS RESTARTS AGE
pod/address-finder-deployment-56847c949b-vr99p 2/2 Running 0 14s
Yukarıda görebileceğiniz gibi, mevcut ReplicaSet değişti ve Pod yeniden başlatıldı. Ayrıca revizyon geçmişinin neye benzediğini de kontrol edelim.
$ kubectl rollout history deployment address-finder-deployment
REVISION CHANGE-CAUSE
1
3
4
Revizyon 2, şimdi aktif olması gereken 4'e yükseltildi. Mevcut ReplicaSet ile onaylayalım.
$ kubectl describe replicaset address-finder-deployment-56847c949b | grep revision
deployment.kubernetes.io/revision: 4
deployment.kubernetes.io/revision-history: 2
İşte burada. Bize mevcut revizyonun ne olduğunu ve geri alma geçmişini gösteriyor. Web sunucumuz artık v3 yerine v2 mesajını yazdırıyor.
// Run/restart rollout/deployment
$ kubectl rollout restart deployment address-finder-deployment
// List rollout/deployment history/revisions
$ kubectl rollout history deployment address-finder-deployment
// Rollback to revision
$ kubectl rollout undo deployment address-finder-deployment --to-revision={revision-no}