cc @ironcladlou @bgrant0607

Apa kasus penggunaan untuk me-restart pod tanpa perubahan spesifikasi?

Perhatikan bahwa tidak akan ada cara untuk mengembalikan perubahan jika pod mulai gagal ketika di-restart.

Setiap kali layanan masuk ke keadaan terjepit atau tidak diinginkan (koneksi sudah maksimal dan sekarang macet, keadaan internal buruk, dll.). Ini biasanya merupakan salah satu langkah pemecahan masalah pertama jika layanan mengalami gangguan serius.

Jika pod pertama gagal saat di-restart, saya akan mengharapkannya untuk berhenti melanjutkan atau terus mencoba lagi untuk memulai pod.

Juga, restart bergulir tanpa perubahan spesifikasi mengalokasikan pod di seluruh
gugus.

Namun, saya juga ingin kemampuan untuk melakukan ini tanpa menjadwal ulang
polong. Itu bisa menjadi perubahan label bergulir, tetapi dapat mengambil dinamika baru
config atau hapus status file lokal.

Pada hari Rabu, 2 Sep 2015 jam 12:01, Sam Ghods [email protected] menulis:

Setiap kali layanan masuk ke keadaan terjepit atau tidak diinginkan (maksimal)
koneksi dan sekarang terhenti, keadaan internal buruk, dll.). Biasanya
salah satu langkah pemecahan masalah pertama jika layanannya serius
berperilaku buruk.

Jika pod pertama gagal saat di-restart, saya berharap itu akan berhenti
melanjutkan atau terus mencoba untuk memulai pod.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

Clayton Coleman | Insinyur Utama, OpenShift

@smarterclayton Apakah itu seperti opsi 2 saya yang tercantum di atas? Meskipun mengapa label diubah?

Ulang. terjepit: Untuk itulah probe keaktifan.

Ulang. penyeimbangan kembali: lihat #12140

Jika kami mendukung ini, saya akan menggabungkannya dengan #9043 -- mekanisme yang sama diperlukan.

Saya kira ini lebih untuk situasi di mana pod masih hidup dan merespons pemeriksaan tetapi masih perlu di-restart. Salah satu contohnya adalah layanan dengan cache dalam memori atau status internal yang rusak dan perlu dibersihkan.

Saya merasa meminta aplikasi untuk di-restart adalah kasus penggunaan yang cukup umum, tapi mungkin saya salah.

Korupsi hanya akan menjadi satu pod, yang bisa saja dibunuh dan digantikan oleh RC.

Kasus lain yang disebutkan offline adalah membaca ulang konfigurasi. Itu berbahaya untuk dilakukan secara implisit, karena memulai ulang dengan alasan apa pun akan menyebabkan kontainer memuat konfigurasi baru. Akan lebih baik untuk melakukan pembaruan bergulir untuk mendorong referensi konfigurasi berversi baru (misalnya dalam env var) ke pod. Ini mirip dengan apa yang memotivasi #1353.

@ bgrant0607 sudahkah kami memutuskan bahwa kami tidak ingin melakukan ini?

@gmarek Tidak ada, untuk saat ini. Terlalu banyak hal yang sedang berlangsung.

Bisakah kita memiliki pencapaian post v1.1 (atau sesuatu) untuk hal-hal yang kita anggap penting, tetapi kita kekurangan orang untuk segera memperbaikinya?

Saya akan menjadi penggemar fitur ini juga, Anda tidak ingin dipaksa untuk mengganti tag untuk setiap pembaruan kecil yang ingin Anda luncurkan.

Saya penggemar fitur ini. Kasus penggunaan: Tingkatkan semua pod dengan mudah untuk menggunakan gambar buruh pelabuhan yang baru didorong (dengan imagePullPolicy: Always ). Saat ini saya menggunakan sedikit solusi peretasan: Pembaruan bergulir dengan atau tanpa tag :latest pada nama gambar.

Kasus penggunaan lain: Memperbarui rahasia.

Saya sangat ingin melihat fitur ini. Kami menjalankan aplikasi node di kubernetes dan saat ini memiliki kasus penggunaan tertentu di mana kami me-restart pod untuk menghapus dalam caching semu aplikasi.

Inilah yang saya lakukan untuk saat ini:

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

Ini menghapus pod 10 sekaligus dan bekerja dengan baik dalam pengaturan pengontrol replikasi. Itu tidak mengatasi masalah apa pun seperti alokasi pod atau pod baru yang gagal memulai. Ini adalah solusi cepat saat dibutuhkan.

Saya benar-benar ingin dapat melakukan restart bergulir.
Alasan utamanya adalah kita akan memasukkan variabel ENV ke dalam pod menggunakan ConfigMap dan kemudian jika kita mengubah konfigurasi, kita perlu me-restart konsumen ConfigMap tersebut.

Ya, ada banyak kasus ketika Anda benar-benar ingin me-restart pod/container tanpa perubahan di dalamnya...
Konfigurasi, cache, sambungkan kembali ke layanan eksternal, dll. Saya sangat berharap fitur ini akan dikembangkan.

Penyelesaian kecil (saya menggunakan penerapan dan saya ingin mengubah konfigurasi tanpa perubahan nyata pada gambar/pod):

• buat configMap
• buat penerapan dengan variabel ENV (Anda akan menggunakannya sebagai indikator untuk penerapan Anda) di wadah apa pun
• perbarui configMap
• perbarui penyebaran (ubah variabel ENV ini)

k8s akan melihat bahwa definisi penerapan telah diubah dan akan memulai proses penggantian pod
PS:
jika seseorang memiliki solusi yang lebih baik, silakan bagikan

Terima kasih @paunin

@paunin Itulah kasus yang kami butuhkan saat ini - Kami harus mengubah nilai ConfigMap yang sangat penting untuk layanan dan perlu diluncurkan ke wadah dalam beberapa menit hingga beberapa jam. Jika tidak ada penerapan yang terjadi sementara itu, semua kontainer akan gagal pada saat yang sama dan kami akan memiliki waktu henti sebagian setidaknya beberapa detik

from (agak terkait #9043): satu baris pendekatan @paunin , di mana RESTART_ adalah variabel lingkungan, dan disetel ke stempel waktu ISO:

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(perhatikan untuk beberapa alasan variabel lingkungan yang dimulai dengan _ sepertinya menghilang, dan numerik env value s menyebabkan kesalahan, mereka harus berupa string)

@paunin @rcoup Kami melakukan sesuatu yang sangat mirip saat ini, kami memiliki env var yang secara harfiah disebut "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT".

Sepertinya solusi yang tepat di sini akan memungkinkan Anda untuk memulai kembali penerapan, dan menggunakan kembali sebagian besar parameter penerapan untuk peluncuran seperti MinReadyCount, sementara memungkinkan penggantian baris perintah seperti meningkatkan paralelisme untuk situasi darurat di mana Anda membutuhkan segalanya untuk segera bangkit.

ada kemajuan dalam hal ini?

Saya merasa penambahan ini adalah kembung yang tidak perlu dari CLI API. Ini dapat dengan mudah dicapai dengan memperbarui nilai variabel lingkungan penerapan seperti yang disarankan oleh @paunin .

Kami juga ingin melihat ini untuk penerapan yang mungkin seperti kubectl restart deployment some-api

Kubernetes diizinkan untuk me-restart Pod karena berbagai alasan, tetapi admin cluster tidak diizinkan.
Saya memahami pendirian moral bahwa 'mematikan dan menghidupkan lagi' mungkin bukan cara yang diinginkan untuk beroperasi... tetapi saya juga berpikir tidak apa-apa untuk membiarkan orang-orang yang ingin, memulai kembali Deployment tanpa menggunakan jangkauan trik yang kurang menggugah selera seperti:

• menghapus pod
• label boneka
• variabel lingkungan dummy
• peta konfigurasi dummy dipetakan ke variabel lingkungan
• me-reboot node pekerja
• memotong daya ke pusat data

'Tidak, tidak, saya tidak memulai ulang apa pun, hanya mengoreksi kesalahan ketik pada label ini di sini'

Fitur ini akan berguna jika dipasangkan dengan kubectl apply : apply akan mengupdate konfigurasi, termasuk Replication Controller, tetapi pod tidak akan direstart.

Jadi kita membutuhkan metode untuk me-restart pod ini dengan cara Blue-Green.

@DmitryRomanenko bagaimana dengan beralih dari ReplicationControllers ke Deployments? Itu akan memungkinkan Anda untuk menjalankan pembaruan ReplicaSets (penerus ReplicationController).

@kargakis itu tidak mungkin: Deployment hanya memperbarui Replika Set dan Pod.
Dengan kubectl apply kami juga memperbarui ConfigMaps, Layanan, dll.

@DmitryRomanenko jika masalahnya adalah "Saya ingin me-restart Pod ketika ConfigMap/Secret diperbarui" maka solusi yang mungkin adalah memiliki versi untuk ConfigMap dan Secrets Anda, dan menjadikan versi itu bagian dari spesifikasi Deployment Anda. Jadi dengan kubectl apply spesifikasi Deployment diubah dan Pod dibuat ulang.
Dalam situasi lain saya tidak mengerti mengapa Pod harus di-restart (maksud saya pembaruan Service/Ingress/etc).

@tyranron , terima kasih! Apa cara terbaik untuk versi ConfigMap s? Haruskah saya membuat peta konfigurasi baru dengan nama berbeda untuk penerapan baru?

@DmitryRomanenko sebenarnya bisa, kenapa tidak? Tetapi dalam hal ini Anda harus berhati-hati untuk menghapus yang lama. Di sisi lain mungkin berguna untuk rollback. Tetapi dalam kebanyakan kasus menentukan versi melalui label sudah cukup.

Saya percaya bahwa solusi terbaik di sini adalah semacam pengamat atau pemeriksa hash-sum pada objek configmap . Yang seharusnya memicu restart objek/pod terkait (apa pun menggunakan configmap , secret ). Tidak yakin itu sesuatu yang dapat diakses dalam arsitektur k8s ...

Saya juga berpikir bahwa lebih baik memiliki kontrol dari objek configmap|secret untuk memicu restart pada perubahan atau tidak.

@tirani ,

Jadi dengan kubectl yang menerapkan spesifikasi Deployment diubah dan Pod dibuat ulang.

Bisakah Anda menjelaskan? Haruskah saya menggunakan kubectl apply -f new_config.yml dengan penerapan yang diperbarui, dan penerapan ini akan dimulai ulang secara bergulir?

@DmitryRomanenko ya, tepatnya.

@DmitryRomanenko dengan menerapkan spesifikasi baru Anda memperbarui Deployment , dan pada pembaruan Deployment restart dipicu jika spesifikasinya diubah.

Secara default strategi restart adalah RollingUpdate , tetapi Anda juga dapat menentukan yang lain secara eksplisit.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Cegah masalah dari penutupan otomatis dengan komentar /lifecycle frozen .

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau @fejta .
/siklus hidup basi

Perubahan kecil pada solusi @rcoup : pastikan date dievaluasi di dalam Shell:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/hapus siklus hidup basi
/siklus hidup dibekukan

Telah menggunakan mode Swarm untuk beberapa waktu yang dianggap kurang fleksibel daripada Kubernetes, saya dapat memulai kembali tugas layanan (baca: pod penyebaran), hanya dengan melakukan pembaruan paksa (tanpa perubahan spesifikasi) seperti pada docker service update --force <service-name> . Saya berharap Kubernetes melakukan ini juga.
Untuk configmaps dan secret, swarm tidak mengizinkan Anda untuk mengeditnya, Anda harus memutarnya sebagai gantinya. Anda melakukan ini dengan membuat configmaps/rahasia baru, memperbarui spesifikasi layanan untuk menggunakan yang baru, lalu menghapus yang lama. Saya melihat ini biasanya yang direkomendasikan di atas dengan membuat versi configmaps/secerts Anda dan memperbarui penerapan yang menggunakannya. Sejujurnya, perilaku rotasi ini adalah salah satu alasan utama saya meninggalkan swarm! Sangat merepotkan untuk memiliki salinan lokal, perbarui kemudian buat sumber daya baru dan akhirnya perbarui sumber daya yang bergantung. Selain itu, rahasia dalam swarm tidak dapat dibaca dari api, Anda harus memasangnya di dalam wadah apa pun (atau exec di dalam wadah yang menggunakannya), lalu cat file mereka.
Pada catatan terkait, saya menggunakan openshift untuk beberapa waktu dan saya yakin ini akan memulai ulang pod secara otomatis pada perubahan env/configmap/secret? Aku berdiri dikoreksi sekalipun.

harus menjadi tanggung jawab aplikasi untuk mengawasi sistem file untuk perubahan, seperti yang disebutkan Anda dapat menggunakan checksum pada configmap/rahasia dan memaksa restart seperti itu

tetapi jika Anda tidak ingin mengubah konfigurasi sama sekali dan hanya melakukan restart bergulir dengan jeda sewenang-wenang, pipa sederhana melakukan pekerjaan (yang ini tidur 30 detik antara pod yang dihentikan)

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

perhatikan bahwa jika Anda menekan ctrl + c, tidak mudah untuk memulai kembali dari tempat Anda tinggalkan

@so0k , perintah alternatif:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

Dua setengah tahun kemudian dan orang-orang masih membuat solusi baru, dengan dummy env vars, dummy labels, ConfigMap dan Secret watcher sidecars, penskalaan ke nol, dan langsung meluncurkan skrip shell pembaruan untuk mensimulasikan kemampuan memicu pembaruan bergulir. Apakah ini masih sesuatu yang tidak boleh dilakukan oleh admin cluster dengan jujur, tanpa trik?

27081 #33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

Trik lain adalah menjalankan:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

lalu:

kubectl set image deployment/my-deployment mycontainer=myimage

Ini sebenarnya akan memicu pembaruan bergulir tetapi pastikan Anda juga telah menetapkan imagePullPolicy: "Always".

trik lain yang saya temukan, di mana Anda tidak perlu mengubah nama gambar, adalah mengubah nilai bidang yang akan memicu pembaruan bergulir, seperti terminasiGracePeriodSeconds. Anda dapat melakukannya menggunakan kubectl edit deployment your_deployment atau kubectl apply -f your_deployment.yaml atau menggunakan patch seperti ini:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrade/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@so0k @KIVagant menghapus pod berarti downtime, bahkan ketika menjalankan beberapa instance. Ketika seseorang menjalankan satu pod dengan strategy.rollingUpdate.maxUnavailable = 0 penerapan reguler terlebih dahulu membuat pod baru sebelum menghentikan yang sudah ada. Trik kubectl patch deployment memicu perilaku ini, menghapus pod tidak. Saya sangat menyukai cara non-retas untuk memicu perilaku ini sesuai permintaan.

Misalnya, saat menjalankan gambar dari hub.docker.com, tag yang sama dapat ditambal untuk pembaruan keamanan. Saya benar-benar ingin "menarik gambar terbaru", dan melakukan pembaruan bergulir untuk gambar yang sudah ketinggalan zaman.

Peluncuran pembaruan ConfigMap/Secret adalah #22368
Peluncuran gambar baru yang lebih mudah adalah #1697
Pembaruan bergulir di tempat adalah #9043

Mulai ulang pada pembuatan gambar: https://github.com/GoogleCloudPlatform/freshpod
Presentasi puncak puncak sebuah trik menggunakan anotasi bertemplat untuk memicu peluncuran penerapan: https://www.youtube.com/watch?v=dSw0w1x96ak

@bgrant0607 Saya pikir kasus penggunaan penting yang tidak tercakup oleh tiket lain adalah yang ini: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

@ghodss menulis:
Saya kira ini lebih untuk situasi di mana pod masih hidup dan merespons pemeriksaan tetapi masih perlu di-restart. Salah satu contohnya adalah layanan dengan cache dalam memori atau status internal yang rusak dan perlu dibersihkan.

Saya merasa meminta aplikasi untuk di-restart adalah kasus penggunaan yang cukup umum, tapi mungkin saya salah.

Saya ingin memaksa restart bergulir untuk menghapus semua status aplikasi tanpa trik manual.

Saya memiliki one-liner serupa berdasarkan pendekatan yang dijelaskan oleh @paunin , tetapi seharusnya berfungsi untuk kasus yang lebih umum. Itu bergantung pada output JSON dan menggunakan jq untuk parsing. Saya telah memuat ini ke bashrc saya sebagai fungsi sehingga saya dapat memanggilnya di mana saja

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

Ini memungkinkan saya untuk hanya mengatakan: kubectl-restart my-deployment-name dan itu akan "memperbarui" RESTART_ env var di wadah pertama ke stempel waktu saat ini. Saya jauh dari ahli jq jadi mungkin ada cara yang lebih baik untuk melakukannya, tetapi pada dasarnya itu menghapus RESTART_ env var lama dari output (jika ada) dan kemudian menambahkannya kembali ke sana dengan waktu saat ini.

Rasanya sangat aneh bagi saya bahwa tidak ada cara asli untuk melakukan ini... Tentu saja ruangan yang penuh dengan insinyur akan setuju bahwa kemampuan untuk "mematikan dan menghidupkannya kembali" adalah sesuatu yang kami ingin miliki.

Itu adalah peretasan yang bagus dan semuanya, tetapi memiliki kerugian besar. Lain kali Anda menerapkan, menggunakan kubectl apply -f , komponen itu akan dimulai ulang jika memiliki RESTART_xxx env var meskipun tidak ada yang berubah. Dengan kata lain, ini menyebabkan restart palsu pada penerapan berikutnya jika pernah dimulai ulang antara penerapan terakhir dan penerapan ini. Tidak ideal...

Itulah sebabnya fungsionalitas rolling-restart harus dimasukkan ke dalam pengontrol Deployment, bukan dibangun di atas.

Saya menulis fungsi bash untuk menyelesaikan strategi "penempatan patch terminationGracePeriodSeconds " @whereisaaron dikutip dalam komentarnya di atas (sumber: https://stackoverflow.com/a/40368520/90442).

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

Komentar / update melalui inti di sini . Saya akan menggemakan komentar orang lain bahwa akan lebih baik jika ini tidak perlu.

Hanya dengan alasan yang lebih spesifik terkait kube, restart juga memungkinkan menjalankan kembali init-container, yang dapat digunakan untuk memutar kunci, memperbarui konfigurasi, atau apa pun yang Anda gunakan untuk wadah init.

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro Apakah Anda memiliki RESTART_xxx env var dalam konfigurasi yang Anda terapkan, atau tidak? Jika tidak, maka saya berharap berlaku untuk mengabaikan env var tambahan dalam keadaan langsung.

cc @apelise

@gjcarneiro Ya, masalah dengan skrip @mattdodge adalah menggunakan apply, jadi perubahannya akan disimpan di anotasi LastApplied. Skrip dapat diperbaiki dengan menggunakan tambalan atau metode lain untuk memperbarui penerapan.

Ingin sekali memiliki fitur ini. Tampaknya sangat mendasar dan dibutuhkan.

Tidak ada kemajuan di sini atau di #22368, le sigh :-(

Adakah yang bisa merekomendasikan solusi cepat dan kotor untuk memulai kembali DaemonSet setelah ConfigMap yang dipasang telah diperbarui (nama masih identik)?

@alcohol , periksa yang ini https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

Terima kasih atas tipnya :-)

Openshift memiliki konsep pemicu penerapan, yang memicu peluncuran pada perubahan gambar, webhook, atau perubahan konfigurasi. Ini akan menjadi fitur yang sangat bagus untuk dimiliki di Kubernetes. Serta peluncuran manual tentu saja.

Lebih jauh lagi, repositori Docker memiliki riwayat sehingga tidak ada alasan mengapa rollback tidak dapat bekerja - pod yang muncul dari .spec.template dapat menggunakan format image-tag:@digest saat menarik gambar untuk container. Rollback akan menggunakan ID intisari dari peluncuran sebelumnya.

Tidak yakin apakah saya mengerti dengan benar. Kalau-kalau ini membantu siapa pun.

Tampaknya jika Anda memperbarui nilai label di bawah pod > template > metadata, maka pembaruan bergulir terjadi setelah Anda kubectl apply -f file.yaml

Jadi Anda selalu dapat memiliki label untuk versi Anda dan kapan pun Anda ingin menggulirkan pembaruan, ubah versi dan terapkan file.

Tentu, kelemahannya adalah lain kali Anda ingin melakukan penerapan, Anda melakukannya kubectl apply -f some.yaml , bukan? Biasanya, jika tidak ada perubahan pada some.yaml maka tidak ada yang dimulai ulang, itulah salah satu hal terbaik tentang Kubernetes.

Tapi bayangkan apa yang terjadi setelah Anda mengubah label untuk memulai ulang Deployment. Pada penerapan perangkat lunak normal berikutnya, Anda melakukan kubectl apply -f some.yaml seperti biasa, tetapi karena file yaml tidak berisi label yang sama, Deployment akan dimulai ulang secara tidak perlu.

@gjcarneiro Jika Anda tidak apply saat melakukan perubahan, anotasi kubectl.kubernetes.io/last-applied-configuration tidak akan diperbarui, sehingga apply tidak akan menyebabkan restart lagi.

Saya sangat mendukung untuk menambahkan perintah rolling restart ke kubectl, tetapi sementara itu saya menggunakan yang berikut (berdasarkan solusi di atas):

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

Parameterisasi ini dan tambahkan sebagai fungsi di .bashrc Anda dan ini adalah solusi sementara yang baik.

Ah, keren, saya tidak tahu itu, terima kasih!

Saya tidak memerlukan alias bash, di perusahaan saya, kami membuat antarmuka web saya sendiri untuk mengelola Kubernetes menggunakan Python+aiohttp dan sudah menggunakan patch. Saya berpikir tentang open source, hanya malas ...

Sepertinya orang mengulangi solusi solusi yang sama di utas ini - harap baca utas lengkap sebelum memposting di sini

@joelittlejohn Saya menjalankan makro Anda dan itu memicu reboot pod saya, tetapi semuanya dimulai ulang pada saat yang bersamaan. Saya pikir ini akan memicu reboot bergulir, bukan?

@Macmee Itu tergantung pada konfigurasi penyebaran Anda. Perintah di atas hanya mengubah penyebaran. Pod-pod tersebut kemudian diperbarui sesuai dengan peluncuran strategy ditentukan oleh penerapan Anda. Ini sama seperti perubahan lain pada penerapan.

Satu-satunya cara ini akan menggantikan semua pod pada saat yang sama adalah jika .spec.strategy.rollingUpdate.maxUnavailable mengizinkannya.

Kami juga membutuhkan fitur ini. Satu kasus penggunaan juga di pihak kami adalah kami menggunakan spring-cloud-config-server yang didukung oleh dan scm, untuk aplikasi spring-boot kami. Saat kita mengubah properti konfigurasi, aplikasi spring-boot perlu di-restart untuk dapat mengambil perubahan konfigurasi baru sehingga kita juga memerlukan pemicu restart yang anggun ini tanpa harus melakukan penempatan ulang.

@japzio Seperti yang disarankan oleh Helm , checksum dari configmap dalam anotasi adalah cara yang baik untuk menangani kasus itu.

Apakah ada pembaruan tentang ini? Kami juga ingin memiliki fitur ini. @bgrant0607 @nikhiljindal

@bholagabbar-mt Apa kasus penggunaan Anda?

cc @kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo Usecase untuk sistem kami adalah multifold.

1. Pembaruan rahasia - Saya yakin Anda menyadari bahwa ada banyak perusahaan seperti saya, yang telah membangun abstraksi mereka sendiri di atas kubernet. Kami memiliki sistem manajemen kontainer kami sendiri yang diatur melalui kubernetes. Jadi komentar saran rahasia helm dan lainnya tidak berlaku. Untuk memuat ulang rahasia dari ConfigMaps di kluster dev, kita harus memaksa mematikan pod, yang mengakibatkan beberapa detik waktu henti. Ini tidak seharusnya terjadi. Ini adalah kasus penggunaan nyata untuk pembaruan bergulir.

2. Ini agak rumit, tetapi cakupan keseluruhannya, seperti yang disarankan seseorang, adalah untuk memperbaiki perilaku abnormal. Kami memiliki 4-5 aplikasi Java berat yang berjalan pada kerangka kerja Play. Kami menghadapi situasi di mana konsumsi memori pod java kami meningkat secara linier dan kemudian memulai ulang pod ketika batas memori tercapai. Ini adalah masalah Java yang terdokumentasi dengan masalah stackoverflow dan Masalah Kubernetes yang terkait dengannya. Rolling-restart semua pod dalam periode 3-4 jam akan mengatur ulang konsumsi memori dan memungkinkan aplikasi kami berfungsi dengan lancar tanpa lonjakan.

Semoga ini cukup meyakinkan dan fitur ini dapat digunakan oleh seseorang untuk pengembangan?

@bholagabbar-mt cukup ubah variabel lingkungan dan itu akan memicu penyebaran bergulir:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn Ini sempurna. Kami mengintegrasikan perubahan ini ke dalam sistem kami hari ini dan itu berjalan dengan baik. Terima kasih banyak!

cc @huzhengchuan

Kasus penggunaan lain untuk ini: karena masalah keamanan di containerd, saya ingin memulai ulang semua pod. https://seclists.org/oss-sec/2019/q1/119 Baik cluster turun sepenuhnya, atau melakukan restart bergulir. Memiliki perintah restart akan membuat perbedaan besar!

perbarui , solusi:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh Anda adalah praktik terbaik. tambahkan annotation:{creatTime: 12312312} di peternak!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

tampaknya menjadi perintah minimal yang melakukan pekerjaan untuk satu penyebaran. Ini adalah contoh penggunaan konfigurasi imperatif.

cc @monopole @apelise

~Dua~ Tiga setengah tahun dan orang-orang masih membuat solusi baru, dengan dummy env vars, label dummy ,

Pembaruan bergulir masih merupakan aktivitas yang cukup populer untuk sesuatu yang tampaknya tidak memiliki kasus penggunaan

masalah jangka panjang (catatan untuk diri sendiri)

1. Saya tidak melihat cara untuk melakukan ini tanpa membiarkan logika imperatif mengalir ke API deklaratif, dengan demikian, melanggar konvensi kami untuk menjaga deklaratif API dan menerapkan perilaku imperatif di pengontrol, dan memperkenalkan ketidakcocokan dengan sebagian besar praktik CI/CD.
2. Saya dapat membayangkan RollingRestart API dan pengontrol di mana pembuatan sumber daya RollingRestart menyebabkan pengontrol me-restart Pod 1 per 1 melalui penggusuran (dengan demikian menghormati anggaran gangguan), tetapi pengontrol seperti itu dapat diimplementasikan sebagai CRD (yaitu saya tahu alasan mengapa kita harus melakukan ini di pohon).
3. Pendekatan deklaratif, misalnya menambahkan anotasi lastRestartedAt=TIMESTAMP tidak tampak seperti peretasan bagi saya.
4. Jika ada yang ingin menawarkan desain deklaratif dan kontribusi untuk mengimplementasikan fitur ini (dalam struktur pohon atau lainnya), harap pertimbangkan untuk membuat KEP PR terhadap peningkatan repo . Jika deklaratif, implementasi bawaan, dapat dirancang, saya akan dengan senang hati meninjau/menyimpan di API beban kerja. Jika pengontrol CRD seperti [2] ditawarkan, kami dapat mensponsorinya di Aplikasi SIG sebagai ekstensi yang disponsori komunitas.

Pendekatan deklaratif, misalnya menambahkan anotasi lastRestartedAt=TIMESTAMP tidak tampak seperti peretasan bagi saya.

Ini bukan peretasan, seharusnya hanya ada baris perintah singkatan untuk itu.

Seseorang dapat membuat plugin krew yang mengirimkan tambalan. kubectl restart-deployment <deployment_name> ?

kubectl rollout restart yang menambal penyebaran/daemonset/statefulset untuk memicu 'peluncuran' baru?

Itu sejalan dengan pendekatan @kow3ns (3), dan masuk akal karena Anda kemudian dapat menonton/menjeda/melanjutkan peluncuran yang baru saja Anda mulai dengan perintah kubectl rollout .

@whereisaaron Saya akan melihat apakah saya dapat mengirim tambalan untuk itu (permainan kata-kata tidak dimaksudkan)

Untuk meluncurkan rahasia dan peta konfigurasi baru, rekomendasi saya masih #22368: buat yang baru. Itu menyediakan sarana untuk mengontrol peluncuran dan juga memutar kembali. Kita hanya perlu menyelesaikan GC objek lama:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

Mendokumentasikan dan/atau mendukung (dalam kustomisasi, kubectl, atau plugin kubectl) cara yang disarankan untuk melakukan rolling restart dengan API yang ada adalah wajar.

cc @monopole

Untuk gambar baru, CI/CD atau pengontrol yang menyelesaikan tag untuk dicerna: #1697.

Memindahkan pod yang tidak menyenangkan dimaksudkan untuk dilakukan oleh descheduler (https://github.com/kubernetes-incubator/descheduler) atau semacamnya, yang dapat menggunakan status penampung, metrik inti, dan bahkan metrik khusus:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

Juga, dokumentasi resmi tentang cara menangani rahasia dan peta konfigurasi: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

Rolling restart sangat dibutuhkan. 1 contohnya adalah kita mendapatkan semua rahasia dari SSM dari AWS. Jika kami mengubah beberapa rahasia dari SSM, kami ingin melakukan rolling restart sehingga pod sekarang mengambil yang terbaru saat mereka boot. Juga beberapa kali ada masalah aplikasi yang perlu bergulir ulang hingga perbaikan aktual mendarat di produksi.

Oke, kubectl rollout restart telah bergabung!

Itu bagus untuk didengar setelah hampir 4 tahun, terima kasih!

Saya yakin PR yang digabungkan hanya mendukung penerapan, apakah itu benar?

Beberapa orang dalam masalah ini telah menyatakan perlunya memulai kembali daemonset dan statefulsets juga.

@apelisse apakah ada juga cara untuk melakukan ini melalui SDK atau hanya kubectl?

@e-nikolov Apa itu SDK?

Maksud saya klien Go yang dapat digunakan untuk berbicara dengan kubernet dari program Go.

Tidak, Anda harus mengimplementasikan kembali logika (sangat sederhana) yang diimplementasikan di kubectl.

Oke, peluncuran ulang kubectl telah digabungkan!

Versi kubectl akan memilikinya?

Versi kubectl apa yang akan memilikinya?

Kubernet 1.15

Cluster GKE kami di saluran rilis "cepat" telah mengupgrade dirinya ke Kubernetes 1.16 dan sekarang kubectl rollout restart telah berhenti berfungsi:

kubectl luncurkan mulai ulang aplikasi saya
kesalahan: perintah tidak dikenal "mulai ulang penerapan myapp"

@nikhiljindal bertanya beberapa waktu lalu tentang kasus penggunaan untuk memperbarui penyebaran tanpa perubahan spesifikasi. Mungkin kami melakukannya dengan cara yang tidak optimal, tetapi ini dia: model ML kami yang telah terlatih dimuat ke dalam memori dari Google Cloud Storage. Saat file model diperbarui di GCS, kami ingin meluncurkan ulang penerapan K8S kami, yang menarik model dari GCS.

Saya menghargai kami tidak dapat memutar kembali penyebaran dengan file model sebelumnya dengan mudah, tapi itulah trade-off yang kami adopsi untuk membawa model sedekat mungkin ke aplikasi dan menghindari panggilan jaringan (seperti yang mungkin disarankan beberapa orang).

hai @dimileeh

Apakah Anda tahu versi kubectl yang Anda gunakan sekarang? dan versi apa yang Anda gunakan sebelumnya? Saya ingin tahu apakah ada regresi, tetapi pada saat yang sama saya akan terkejut jika fitur tersebut benar-benar hilang.

Berkenaan dengan hal GCS, dan mengetahui sedikit tentang kasus penggunaan Anda, mohon maaf jika tidak masuk akal: Saya akan menyarankan agar model gcs mendapatkan nama yang berbeda setiap kali mereka dimodifikasi (mungkin akhiran dengan hash mereka), dan itu nama akan disertakan dalam penerapan. Memperbarui penerapan untuk menggunakan file baru akan secara otomatis memicu peluncuran. Ini memberi Anda kemampuan untuk melakukan roll-back ke penerapan/model sebelumnya, memiliki pemahaman yang lebih baik tentang perubahan yang terjadi pada model, dll.

hai @apelise , terima kasih atas tanggapan Anda!

Ketika saya menjalankan kubectl version dari Google Cloud Terminal, saya mendapatkan yang berikut:

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

Ketika saya mencoba memutakhirkan kubectl melalui gcloud components update , dikatakan bahwa saya sudah menggunakan versi terbaru dari semua produk. Oleh karena itu, saya pikir versi kubectl saya tetap sama sementara cluster K8S ditingkatkan dari 1,15 menjadi 1,16.

Dokumentasi Kubenetes 1.17, 1.16 dan 1.15 tidak memiliki apa-apa tentang fitur kubectl rollout restart . Jadi saya ingin tahu apakah kontribusi berharga Anda bisa hilang dari 1,16?

Terima kasih atas saran Anda tentang pembuatan versi model, itu sangat masuk akal. Kami memikirkannya tetapi kemudian, karena kami melatih kembali model kami setiap hari, kami pikir kami akan mulai mengumpulkan terlalu banyak model (dan itu cukup berat). Tentu saja, kami dapat menggunakan beberapa skrip untuk membersihkan versi lama setelah beberapa waktu, tetapi sejauh ini kami telah memutuskan untuk membuatnya tetap sederhana dengan mengandalkan kubectl rollout restart dan tidak peduli dengan pembuatan versi model :)

Saya dapat melihat dokumen di sini:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

Ah, terima kasih, saya mencari di sini:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

Terima kasih banyak untuk tautan itu, saya akan memastikan itu diperbarui!

Pada Kam, 19 Des 2019 pukul 12:40 Dmitri Lihhatsov [email protected]
menulis:

Ah, terima kasih, saya mencari di sini:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMSAVBW63LNMVXW67
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (Saya akan memilih cabang yang relevan setelah ini digabungkan).

@dimileeh Saya pikir saya menemukan apa yang salah dengan versi kubectl Anda, kami akan mengerjakannya.

Ya, kami juga memiliki kasus penggunaan untuk memulai kembali pod tanpa perubahan kode, setelah memperbarui configmap. Ini untuk memperbarui model ML tanpa menerapkan kembali layanan.

@anuragtr dengan versi terbaru yang dapat Anda jalankan

kubectl rollout restart deploy NAME

Saya menggunakan perintah khusus untuk itu [1], senang sekarang ada di kubectl standar! Terima kasih

[1] https://github.com/mauri870/kubectl-renew

@anuragtr dengan versi terbaru yang dapat Anda jalankan

kubectl rollout restart deploy NAME

@negara