Kubernetes: Dukungan yang lebih baik untuk kontainer sespan dalam pekerjaan batch

/sub

Juga menggunakan masalah liveness seperti yang disarankan di sini http://stackoverflow.com/questions/36208211/sidecar-containers-in-kubernetes-jobs tidak berfungsi karena pod akan dianggap gagal dan keseluruhan pekerjaan tidak akan dianggap berhasil.

Bagaimana kalau kita mendeklarasikan pemeriksaan keberhasilan pekerjaan sehingga Pekerjaan dapat memeriksanya untuk mendeteksi keberhasilan alih-alih menunggu pod mengembalikan 0.
Setelah probe kembali sukses, maka pod dapat dihentikan.

Dapat menyelidiki berjalan terhadap wadah yang telah keluar, atau akan ada
menjadi ras di mana ia sedang dirobohkan?

Pilihan lain adalah untuk menunjuk kode keluar tertentu sebagai memiliki arti khusus.

Baik "Sukses untuk seluruh pod" atau "gagal untuk seluruh pod" keduanya
berguna.

Ini harus berada di objek Pod, jadi itu adalah perubahan API yang besar.

Pada Thu, Sep 22, 2016 at 13:41, Ming Fang [email protected] menulis:

Bagaimana kalau kita mendeklarasikan penyelidikan keberhasilan pekerjaan sehingga Pekerjaan dapat menyelidikinya
mendeteksi keberhasilan alih-alih menunggu pod mengembalikan 0.

Setelah probe kembali sukses, maka pod dapat dihentikan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -249021627,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AHuudjrpVtef6U35RWRlZr3mDKcCRo7oks5qsugRgaJpZM4IiqQH
.

@erictune Poin bagus; kami tidak dapat menyelidiki wadah yang keluar.

Bisakah kita menunjuk container tertentu di dalam pod sebagai container "penyelesaian" sehingga ketika container itu keluar, kita dapat mengatakan bahwa pekerjaannya telah selesai?

Kontainer sespan cenderung berumur panjang untuk hal-hal seperti pengiriman kayu dan pemantauan.
Kami dapat memaksa menghentikan mereka setelah pekerjaan selesai.

Bisakah kita menunjuk container tertentu di dalam pod sebagai container "penyelesaian" sehingga ketika container itu keluar, kita dapat mengatakan bahwa pekerjaannya telah selesai?

Sudahkah Anda melihat dokumen poin 3 ini, yang dijelaskan secara rinci di sini di mana Anda pada dasarnya tidak menetapkan .spec.completions dan segera setelah wadah pertama selesai dengan 0 kode keluar, pekerjaan selesai.

Kontainer sespan cenderung berumur panjang untuk hal-hal seperti pengiriman kayu dan pemantauan.
Kami dapat memaksa menghentikan mereka setelah pekerjaan selesai.

Secara pribadi, ini bagi saya lebih mirip RS, daripada pekerjaan, tapi itu pendapat pribadi saya dan yang paling penting saya tidak tahu detail lengkap pengaturan Anda.

Secara umum, ada diskusi berikut https://github.com/kubernetes/kubernetes/issues/17244 dan https://github.com/kubernetes/kubernetes/issues/30243 yang menyentuh topik ini juga.

@soltysh tautan yang Anda kirim di atas, poin 3 referensi penyelesaian pod dan bukan penyelesaian wadah.

Kedua wadah dapat berbagi emptyDir, dan wadah pertama dan menulis pesan "Saya keluar sekarang" ke file dan yang lainnya dapat keluar ketika melihat pesan itu.

@erictune Saya memiliki kasus penggunaan yang menurut saya termasuk dalam ember ini dan saya berharap Anda dapat membimbing saya ke arah yang benar karena sepertinya tidak ada cara resmi yang direkomendasikan untuk menyelesaikan masalah ini.

Saya menggunakan perpustakaan client-go untuk mengkodekan semuanya di bawah ini:

Jadi, saya memiliki pekerjaan yang pada dasarnya menjalankan alat dalam satu wadah pod. Segera setelah alat selesai berjalan, itu seharusnya menghasilkan file hasil. Sepertinya saya tidak dapat menangkap file hasil ini karena segera setelah alat selesai berjalan, pod dihapus dan saya kehilangan file hasil.

Saya dapat menangkap file hasil ini jika saya menggunakan HostPath sebagai VolumeSource dan karena saya menjalankan minikube secara lokal, file hasil akan disimpan ke workstation saya.

Tapi, saya mengerti itu tidak direkomendasikan dan ideal untuk wadah produksi. Jadi, saya menggunakan EmptyDir seperti yang disarankan di atas. Tapi, sekali lagi, jika saya melakukannya, saya tidak bisa menangkapnya karena terhapus dengan pod itu sendiri.

Jadi, haruskah saya menyelesaikan masalah saya dengan menggunakan pola kontainer sespan juga?

Pada dasarnya, lakukan apa yang Anda sarankan di atas. Mulai 2 kontainer di pod setiap kali pekerjaan dimulai. 1 wadah menjalankan pekerjaan dan segera setelah pekerjaan selesai, menjatuhkan pesan yang diambil oleh wadah lain yang kemudian mengambil file hasil dan menyimpannya di suatu tempat?

Saya gagal memahami mengapa kita membutuhkan 2 kontainer di tempat pertama. Mengapa wadah pekerjaan tidak dapat melakukan semua ini sendiri? Artinya, selesaikan pekerjaan, simpan file hasil di suatu tempat, akses/baca dan simpan di suatu tempat.

@anshumanbh Saya sarankan Anda:

1. gunakan penyimpanan persisten, Anda menyimpan file hasil
2. gunakan hostPath mount, yang hampir sama dengan 1, dan Anda sudah mencobanya
3. unggah file hasil ke lokasi jarak jauh yang diketahui (s3, google drive, dropbox), umumnya semua jenis drive bersama

@soltysh Saya tidak ingin file disimpan secara permanen. Di setiap putaran, saya hanya ingin membandingkan hasil itu dengan hasil terakhir. Jadi, cara saya berpikir untuk melakukan ini adalah berkomitmen ke repositori github di setiap proses dan kemudian melakukan diff untuk melihat apa yang berubah. Jadi, untuk melakukan itu, saya hanya perlu menyimpan hasilnya sementara di suatu tempat sehingga saya dapat mengaksesnya untuk mengirimkannya ke Github. Masuk akal?

@anshumanbh sangat jelas, dan tetap saja itu tidak termasuk dalam kategori wadah samping mobil. Semua yang ingin Anda capai saat ini dapat dilakukan dengan pekerjaan apa yang disediakan.

@soltysh jadi mengingat saya ingin menggunakan opsi 3 dari daftar yang Anda sarankan di atas, bagaimana cara saya mengimplementasikannya?

Masalah yang saya hadapi adalah segera setelah pekerjaan selesai, wadah keluar dan saya kehilangan file. Jika saya tidak memiliki file, bagaimana cara mengunggahnya ke drive bersama seperti S3/Google Drive/Dropbox? Saya tidak dapat mengubah kode pekerjaan untuk mengunggahnya secara otomatis di suatu tempat sebelum berhenti, jadi sayangnya saya harus menjalankan pekerjaan terlebih dahulu dan kemudian menyimpan file di suatu tempat..

Jika Anda tidak dapat mengubah kode pekerjaan, Anda harus membungkusnya sedemikian rupa untuk dapat mengunggah file. Jika yang Anda kerjakan adalah gambar, cukup perpanjang dengan kode penyalinan.

@soltysh ya, itu masuk akal. Aku bisa melakukan itu. Namun, pertanyaan berikutnya yang saya miliki adalah - misalkan saya perlu menjalankan banyak pekerjaan (anggap saja sebagai menjalankan alat yang berbeda) dan tidak ada alat ini yang memiliki bagian pengunggahan di dalamnya. Jadi, sekarang, saya harus membuat pembungkus itu dan memperluas masing-masing alat tersebut dengan bagian pengunggahan. Apakah ada cara saya bisa menulis pembungkus/ekstensi sekali dan menggunakannya untuk semua alat?

Bukankah pola mobil samping cocok dalam kasus itu?

Ya, itu bisa. Meskipun saya akan mencoba dengan beberapa wadah di dalam pod yang sama, pattern. rendah. pod Anda menjalankan wadah pekerjaan dan di samping wadah tambahan menunggu output dan mengunggahnya. Tidak yakin seberapa layak ini tetapi Anda sudah bisa mencobanya.

Ping lembut -- kesadaran sespan akan membuat pengelolaan proxy layanan mikro seperti Envoy jauh lebih menyenangkan. Apakah ada kemajuan untuk dibagikan?

Keadaan saat ini adalah bahwa setiap wadah memerlukan alat yang dibundel untuk mengoordinasikan masa pakai, yang berarti kami tidak dapat langsung menggunakan gambar wadah hulu. Ini juga secara signifikan memperumit template, karena kita harus menyuntikkan titik argv dan mount ekstra.

Saran sebelumnya adalah untuk menunjuk beberapa wadah sebagai wadah "penyelesaian". Saya ingin mengusulkan yang sebaliknya -- kemampuan untuk menunjuk beberapa kontainer sebagai "sespan". Ketika container non-sidecar terakhir dalam sebuah Pod berakhir, Pod harus mengirim TERM ke sidecars. Ini akan dianalogikan dengan konsep "utas latar belakang" yang ditemukan di banyak perpustakaan threading, misalnya Thread.daemon Python.

Contoh konfigurasi, ketika container main berakhir, kubelet akan mematikan envoy :

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/my-batch-job/bin/main", "--config=/config/my-job-config.yaml"]
  - name: envoy
    image: lyft/envoy:latest
    sidecar: true
    command: ["/usr/local/bin/envoy", "--config-path=/my-batch-job/etc/envoy.json"]

Untuk referensi, inilah kegilaan bash yang saya gunakan untuk mensimulasikan perilaku sespan yang diinginkan:

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        trap "touch /tmp/pod/main-terminated" EXIT
        /my-batch-job/bin/main --config=/config/my-job-config.yaml
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
  - name: envoy
    image: gcr.io/our-envoy-plus-bash-image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        /usr/local/bin/envoy --config-path=/my-batch-job/etc/envoy.json &
        CHILD_PID=$!
        (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
        wait $CHILD_PID
        if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; fi
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
        readOnly: true
volumes:
  - name: tmp-pod
    emptyDir: {}

Saya ingin mengusulkan yang sebaliknya -- kemampuan untuk menunjuk beberapa kontainer sebagai "sespan". Ketika container non-sidecar terakhir dalam sebuah Pod berakhir, Pod tersebut harus mengirimkan TERM ke sidecars.

@jmillikin-stripe Saya menyukai ide ini, meskipun saya tidak yakin apakah ini mengikuti prinsip memperlakukan beberapa container secara berbeda dalam sebuah Pod atau memperkenalkan dependensi di antara mereka. Saya akan merujuk ke

Meskipun, sudahkah Anda memeriksa #17244, apakah jenis solusi ini sesuai dengan kasus penggunaan Anda? Inilah yang @erictune sebutkan beberapa komentar sebelumnya:

Pilihan lain adalah untuk menunjuk kode keluar tertentu sebagai memiliki arti khusus.

@jmillikin-stripe Saya menyukai ide ini, meskipun saya tidak yakin apakah ini mengikuti prinsip memperlakukan beberapa container secara berbeda dalam sebuah Pod atau memperkenalkan dependensi di antara mereka. Saya akan merujuk ke

Saya pikir Kubernetes mungkin perlu fleksibel tentang prinsip tidak memperlakukan kontainer secara berbeda. Kami (Stripe) tidak ingin memasang kembali kode pihak ketiga seperti Envoy untuk memiliki kait siklus hidup gaya Lamprey, dan mencoba mengadopsi inversi exec gaya Amplop akan jauh lebih rumit daripada membiarkan Kubelet menghentikan sidecar tertentu.

Meskipun, sudahkah Anda memeriksa #17244, apakah jenis solusi ini sesuai dengan kasus penggunaan Anda? Inilah yang @erictune sebutkan beberapa komentar sebelumnya:

Pilihan lain adalah untuk menunjuk kode keluar tertentu sebagai memiliki arti khusus.

Saya sangat menentang Kubernetes atau Kubelet yang menafsirkan kode kesalahan dengan perincian yang lebih baik daripada "nol atau bukan nol". Penggunaan nomor ajaib kode keluar oleh Borglet adalah kesalahan yang tidak menyenangkan, dan akan jauh lebih buruk di Kubernetes di mana gambar kontainer tertentu bisa menjadi "utama" atau "samping" di Pod yang berbeda.

Mungkin kait siklus hidup tambahan akan cukup untuk menyelesaikan ini?

Bisa jadi:

• PostStop: dengan sarana untuk memicu peristiwa siklus hidup pada wadah lain di pod (yaitu memicu berhenti)
• PeerStopped: menandakan bahwa wadah "peer" di pod telah mati - mungkin dengan kode keluar sebagai argumen

Ini juga dapat menentukan cara untuk menentukan kebijakan khusus untuk memulai ulang wadah - atau bahkan memulai wadah yang tidak dimulai secara default untuk memungkinkan beberapa rantai daisy wadah (ketika wadah a selesai maka mulai wadah b)

Juga merindukan ini. Kami menjalankan pekerjaan setiap 30 menit yang membutuhkan klien VPN untuk konektivitas tetapi tampaknya ada banyak kasus penggunaan di mana ini bisa sangat berguna (misalnya hal-hal yang membutuhkan proxy kubectl). Saat ini, saya menggunakan jobSpec.concurrencyPolicy: Replace sebagai solusi tetapi tentu saja ini hanya berfungsi jika a.) Anda dapat hidup tanpa pekerjaan paralel berjalan dan b.) Waktu pelaksanaan pekerjaan lebih pendek dari interval penjadwalan.

EDIT: dalam kasus penggunaan saya, itu akan cukup untuk memiliki beberapa properti dalam spesifikasi pekerjaan untuk menandai wadah sebagai yang terminasi dan meminta pekerjaan memantau yang itu untuk status keluar dan membunuh yang tersisa.

Saya juga, memiliki kebutuhan untuk ini. Dalam kasus kami, ini adalah pekerjaan yang menggunakan wadah proxy cloudsql sebagai layanan sespan.

Bagaimana kalau menambahkan anotasi yang memetakan ke nama wadah 'utama' di pod? Dengan begitu spek pod tidak perlu dimodifikasi dengan cara apa pun.

Secara alami bagaimana Pod dirancang, ini sepertinya kasus penggunaan yang sangat umum. @soltysh @erictune ada rencana untuk segera mengerjakan ini? Senang bisa membantu jika memungkinkan :)

Juga membutuhkan fitur ini. Untuk kasus penggunaan kami:
pod A harus kontainer

• container A1 :
• container A2 : container sespan, yang hanya mengikuti log dari file ke stdout

Yang saya inginkan : ketika container A1 lengkap dengan sukses, pod A lengkap dengan sukses. Bisakah kita memberi label wadah A1 sebagai wadah utama , ketika wadah utama keluar, pod keluar? @erictune ( Ide ini juga dijelaskan oleh @mingfang )

Hai Guys, saya melihat masalah ini telah terbuka selama sebulan. Apa yang terbaru tentang ini? Kami memiliki kasus penggunaan, di mana kami ingin menjalankan pekerjaan. Pekerjaan menjalankan wadah main dengan beberapa mobil sampingan containers . Kami ingin pekerjaan keluar ketika wadah main keluar. Apakah seni berbagi file untuk mengirim signal antara wadah?

Saya tidak keberatan memulai pekerjaan ini, ingin tahu apakah ada yang bisa meninjau PR yang akan datang jika saya melakukannya (mungkin setelah kubecon).

cc @erictune @a-robinson @soltysh

@andrewsykim pendekatan apa yang akan Anda ambil. Juga, saya tahu saya menambahkannya di sini, apa yang diperlukan untuk menambahkan dukungan untuk dependensi. Seperti wadah main tidak boleh dimulai sampai sespan telah diinisialisasi

Seperti wadah utama tidak boleh dimulai sampai sespan telah diinisialisasi

Saya pikir kasus ini tidak menjadi masalah karena main seharusnya dapat memeriksa kapan sespan diinisialisasi (atau menggunakan probe kesiapan). Ini bukan kasus untuk masalah ini karena main akan keluar :)

Saya akhirnya menulis skrip sederhana yang mengawasi kubernetes API dan mengakhiri pekerjaan dengan anotasi yang cocok dan yang wadah utamanya telah keluar. Ini tidak sempurna tetapi memenuhi kebutuhan inti. Saya dapat membagikannya jika orang tertarik.

@ajbouh Saya pribadi akan menghargai jika Anda membagikannya sebagai inti. Saya akan menulis sesuatu yang serupa

@nrmitchi Inilah inti dari yaml yang saya tulis. Ini sangat skrip shell, tapi mungkin ini titik awal yang baik untuk Anda, dalam hal API mana yang digunakan dan cara mendapatkan sesuatu yang berfungsi. Saya dapat menjawab pertanyaan tentang apa yang dilakukannya jika Anda memiliki pertanyaan.

https://Gist.github.com/ajbouh/79b3eb4833aa7b068de640c19060d126

Saya memiliki kasus penggunaan proxy Cloud SQL yang sama dengan @mrbobbytables. Untuk terhubung dengan aman ke cloud SQL, disarankan untuk menggunakan proxy, tetapi proxy itu tidak berhenti ketika pekerjaan selesai, yang menghasilkan peretasan gila atau pemantauan yang terlihat seperti berikut ini. Apakah ada jalan ke depan untuk ini?

@ amaxwell01 Mengenai bintangi atau tonton untuk pembaruan: https://issuetracker.google.com/issues/70746902 (edit: dan saya menyesali beberapa ungkapan yang saya gunakan di sana saat panas; sayangnya saya tidak bisa mengeditnya)

Terima kasih @abevoelker saya mengikuti posting Anda di sana. Ditambah komentarmu membuatku tertawa 👍

Kami juga terpengaruh oleh masalah ini.
Kami memiliki beberapa perintah manajemen django pada layanan mikro kami yang dapat berjalan pada cronjobs k8s tetapi gagal untuk berhasil karena sidecar cloudsqlproxy yang tidak dihentikan pada penyelesaian pekerjaan.
Adakah pembaruan kapan kami bisa memiliki solusi?
Pola wadah sespan semakin banyak digunakan dan banyak dari kita tidak akan dapat menggunakan cronjobs dan pekerjaan k8s sampai ini diselesaikan.

Hanya ingin memberikan +1 saya untuk ini. Saya memiliki masalah Proxy Cloud SQL GCE yang sama dengan orang lain. Ini membunuh saya ... helm deploy gagal yang pada gilirannya gagal menerapkan terraform saya.

Benar-benar ingin melihat semacam resolusi tentang ini... jist dari @ajbouh sepertinya bisa berhasil... tapi astaga, itu retas.

Untuk orang lain yang membutuhkan cloudsql-proxy , apakah akan cocok dengan kasus penggunaan Anda untuk menjalankan cloudsql-proxy sebagai DaemonSet? Dalam kasus saya, saya memiliki Deployment yang persisten dan CronJob yang membutuhkan proxy, jadi masuk akal untuk melepaskannya dari pod individu dan sebagai gantinya melampirkan satu instance per node.

Ya,

Kami telah memutuskan untuk menghapus sidecar proxy cloudsql dan membangun kumpulan
proxy cloudsql di namespace pusatnya, ini berfungsi dengan baik dan memungkinkan
memindahkan skalabilitas dan penerapan yang lebih mudah.
Sekarang kita dapat menjalankan pekerjaan dan cronjobs tanpa masalah apapun.

Pada Rabu, 7 Februari 2018 pukul 09:37, Rob Jackson [email protected]
menulis:

Untuk siapa pun yang membutuhkan cloudsql-proxy, apakah itu sesuai dengan kasus penggunaan Anda untuk
menjalankan cloudsql-proxy sebagai DaemonSet? Dalam kasus saya, saya memiliki keduanya yang gigih
Deployment dan CronJob membutuhkan proxy, jadi masuk akal untuk melepaskannya
itu dari pod individu dan sebagai gantinya melampirkan satu instance per node.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment-363710890 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ACAWMwetx6gA_SrHL_RRbTMJVOhW1FKLks5tSW7JgaJpZM4IiqQH
.

Menarik, menggunakan deamonset terdengar seperti pilihan yang bagus. @RJacksonm1 & @devlounge - bagaimana cara menemukan proxy cloud sql bekerja saat menggunakan daemonset?

Menemukan ini yang sepertinya akan berhasil...
https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

Pada dasarnya melibatkan penggunaan sesuatu seperti ini untuk mendapatkan ip Host:

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

@RJacksonm1 - Apakah ada sesuatu yang istimewa yang Anda lakukan untuk membuat hostPort berfungsi? Saya terus-menerus mendapatkan connection refused saat menggunakannya bersama dengan pendekatan fieldPath: spec.nodeName

Sunting: Saya telah memastikan spec.nodeName berjalan dengan benar dan saya menggunakan GKE v1.9.2-gke.1

@cvallance Saya telah menyiapkan Layanan untuk mengekspos DaemonSet, yang kemudian dapat diakses oleh aplikasi saya melalui DNS. Ini tidak menjamin aplikasi akan berbicara dengan instance cloudsql-proxy berjalan pada Host yang sama dengan dirinya sendiri, tetapi itu menjamin cloudsql-proxy akan diskalakan dengan cluster secara keseluruhan (awalnya saya memiliki proxy sebagai Deployment dan HorizontalPodAutoscaler, tetapi ternyata skalanya naik/turun terlalu banyak – menyebabkan kesalahan MySQL has gone away di aplikasi). Kurasa ini bukan semangat DaemonSet yang sebenarnya...

@RJacksonm1 - membuatnya bekerja dengan hostPort dan spec.nodeName ... sekarang mereka akan terhubung langsung ke DaemonSet di node mereka

Perintah Proxy CloudSql tidak berfungsi:
-instances={{ .Values.sqlConnectionName }}=tcp:{{ .Values.internalPort }}
Bekerja:
-instances={{ .Values.sqlConnectionName }}=tcp:0.0.0.0:{{ .Values.internalPort }}

️

Adakah yang bisa kita lakukan untuk mendapatkan daya tarik tentang masalah ini?
Sudah buka selama hampir 2 tahun dan kami masih memiliki solusi

Saya curiga bahkan jika saya mengajukan diri untuk mengimplementasikan ini, saya tidak akan dapat melakukannya karena perlu persetujuan dari orang-orang internal mengenai solusi mana yang harus diterapkan, perubahan API, dll.

Adakah yang bisa saya lakukan untuk membantu menyelesaikan ini?

Untuk referensi, saya membuat versi sespan cloud-sql-proxy dari solusi @ jmillikin-stripe di mana file dalam volume bersama mengomunikasikan status ke sespan.

Ini berfungsi dengan baik, tetapi sejauh ini merupakan peretasan paling buruk dalam konfigurasi K8 saya :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

Adakah yang bisa internal proyek tolong beri komentar tentang kemajuan masalah ini?

Masalah yang sama di sini

cc @kubernetes/sig-apps-feature-requests @kubernetes/sig-node-feature-requests

Apakah masuk akal untuk mengizinkan pengguna menentukan (berdasarkan nama) wadah dalam Pekerjaan yang ingin mereka lihat selesai dengan sukses untuk menandai pod pekerjaan sebagai selesai (dengan wadah lain dihentikan), seperti:

apiVersion: batch/v2beta1
kind: Job
metadata:
  name: my-job
  namespace: app
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-job-image
          ...
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.11
          ...
  backoffLimit: 2
  jobCompletedWith:
    - my-container

Yaitu pod akan berjalan, tunggu sampai my-container keluar dengan sukses, dan kemudian hentikan cloudsql-proxy .

EDIT: Menggulir utas ini, sekarang saya melihat ini telah diusulkan sebelumnya. Bisakah @erictune atau orang lain menjelaskan kembali mengapa ini tidak berhasil?

ya saya pikir itu akan menjadi sempurna. Hanya sesuatu yang memungkinkan Anda untuk melihat status pekerjaan, dan melanjutkan alur setelah selesai

Ya, itu akan sempurna.

Saya suka ide ini @jpalomaki

Satu kekhawatiran yang saya miliki dengan pendekatan penyelesaian ini murni di dalam pengontrol Job adalah bahwa Pod akan terus berjalan setelah Pekerjaan selesai. Saat ini, Pod memasuki fase Terminated dan Node dapat mengosongkan resource tersebut.

Anda dapat meminta pengontrol Pekerjaan menghapus Pod ketika pengontrol memutuskan bahwa itu sudah selesai, tetapi itu juga akan berbeda dari perilaku saat ini, di mana catatan Pod yang Dihentikan tetap ada di server API (tanpa menggunakan sumber daya Node).

Untuk alasan ini, tampaknya lebih bersih bagi saya untuk mengatasi hal ini di tingkat API Pod, jika memang ada. Node adalah satu-satunya hal yang harus menjangkau dan membunuh wadah individu karena wadah "penyelesaian" yang Anda pedulikan sudah dihentikan. Ini bisa berupa API level-Pod yang memungkinkan Anda menentukan gagasan kontainer mana yang harus ditunggu, atau API level-Pod yang memungkinkan agen eksternal (misalnya pengontrol Job) memaksa Pod untuk berhenti tanpa benar-benar menghapus Pod.

Saya juga mencari solusi untuk mengunggah file yang dihasilkan oleh wadah jika wadah prosesor berhasil keluar.

Saya tidak yakin saya memahami argumen yang dibuat oleh @mingfang terhadap penampung sespan yang melihat status penampung melalui k8s API untuk mengetahui apakah dan kapan harus mulai mengunggah atau keluar. Saat kontainer sespan keluar dari pod dan pekerjaan harus berhasil keluar.

Pikiran lain, yang memang tampak seperti peretasan, tetapi saya ingin tahu seberapa buruknya membuat wadah penghasil data menjadi wadah init, dan memiliki wadah pengunggah data (yang tidak lagi perlu menjadi wadah sespan ) secara otomatis dimulai hanya setelah wadah prosesor berhasil keluar. Dalam kasus saya, saya juga memerlukan wadah pengunduh data sebagai wadah init pertama, untuk menyediakan data ke wadah pemrosesan.. Jika ini adalah ide yang sangat buruk, saya ingin mengetahui alasannya.

Tidakkah mempromosikan sespan ke konsep k8s kelas satu menyelesaikan masalah ini? Kubelet akan dapat menghentikan pod jika semua container yang berjalan di dalamnya ditandai sebagai sidecar.

FWIW, saya mengatasi ini dengan hanya menggunakan proxy Cloud SQL sebagai penerapan reguler ( replicas: 1 ) dan membuat Job dan CronJob menggunakannya melalui type: ClusterIP melayani. Pekerjaan selesai dengan baik sekarang.

Saya ingin posisi resmi dalam hal ini.

Jika kita tidak akan mendapat dukungan dari API, setidaknya kita harus memiliki solusi alternatif yang didokumentasikan secara resmi sehingga orang tahu apa yang harus dilakukan ketika mereka menghadapi masalah ini.

Saya tidak yakin siapa yang harus di-ping atau bagaimana mendapatkan perhatian ini...

Ini akan sangat bagus untuk ditangani. Selain Job yang tidak pernah hilang, status Pod secara keseluruhan ternyata salah:

Init Containers:
  initializer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:52:57 -0500
      Finished:     Wed, 21 Mar 2018 17:52:57 -0500
    Ready:          True
Containers:
  sideCar:
    State:          Running
      Started:      Wed, 21 Mar 2018 17:53:40 -0500
    Ready:          True
  mainContainer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:53:41 -0500
      Finished:     Wed, 21 Mar 2018 17:55:12 -0500
    Ready:          False
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 

Yang menarik adalah perhatikan Status dan Siap untuk initContainer (Dihentikan, Selesai, Siap=Benar) dan wadah aplikasi utama (Dihentikan, Selesai, Siap=Salah). Itu tampaknya mendorong status Pod Ready of False - menurut saya, salah. Hal ini menyebabkan Pod ini ditandai memiliki masalah di dasbor kami.

Saya memiliki pelanggan lain yang mengalami masalah ini dengan proxy Cloud SQL secara khusus. Mereka tidak ingin menjalankannya sebagai layanan persisten untuk mengizinkan tugas cron mengakses Cloud SQL.

@yuriatgoogle Solusi termudah masih bash dan emptyDir "ajaib" seperti: https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -365924958

Ini adalah peretasan, tetapi itu harus dilakukan. Tidak ada maksud menyinggung @phidah.

Sepertinya banyak orang menginginkan ini karena berbagai alasan. Akan lebih baik jika ada dukungan resmi. Saya memiliki masalah yang sama dengan sespan dan pekerjaan kami sendiri, jadi saya meminta sespan menggunakan kube api untuk melihat status wadah lain di pod, jika diakhiri dengan completed sespan akan keluar 0, jika kesalahan bahwa sespan akan keluar 1. Mungkin bukan solusi yang paling elegan tetapi berhasil tanpa perlu banyak perubahan dari pengembang kami. kode di sini jika ada yang tertarik: https://github.com/uswitch/vault-creds/blob/master/cmd/main.go#L132.

Ini mengingatkan saya pada lagu Gorillaz M1 A1...

Halo? Halooooo? Apakah ada orang di sana?

Ya, mari dapatkan daya tarik +1

Jadi solusi yang diusulkan yang membutuhkan perubahan hulu adalah:

1. sidecar: true oleh @jmillikin-stripe
2. Kait siklus hidup tambahan oleh @msperl
3. jobCompletedWith oleh @jpalomaki

Solusi sementara untuk sespan, yang retas (tetapi berfungsi):

1. Untuk cloudsql-proxy sespan oleh @phidah

Saya ingin melihat tanggapan dari pengelola Kubernetes mengenai solusi yang diusulkan dan tolong beri kami rekomendasi tentang cara menyelesaikan kasus penggunaan ini menggunakan versi kubernetes yang ada. Terima kasih!

Baru saja menemukan utas ini setelah menghabiskan satu hari mencoba menulis agen log yang akan mengunggah stdout / stderr dari tugas rendering saya ke database, hanya untuk menemukan bahwa kehadiran agen di pod akan berarti bahwa pekerjaan itu tidak akan pernah berakhir.

Dari saran yang diberikan di atas, saya menyukai 'sidecar: true' yang terbaik, karena sederhana dan to the point - sangat dapat dimengerti oleh pengembang seperti saya. Saya mungkin akan menyebutnya sesuatu yang sedikit berbeda, karena 'sespan' sebenarnya adalah pola desain pod yang berlaku untuk lebih dari sekadar pekerjaan dan menyiratkan hal-hal lain selain persyaratan penyelesaian. Jika Anda memaafkan saya karena kehilangan sepeda, saya mungkin akan menyebutnya seperti 'ambient: true' untuk menunjukkan bahwa Pekerjaan dapat dianggap selesai meskipun tugas ini masih berjalan. Kata lain mungkin 'tambahan' atau 'dukungan'.

Saya juga mengalami masalah ini, untuk alur kerja yang sama seperti yang dijelaskan banyak orang lainnya (wadah sespan yang digunakan untuk koneksi proxy atau mengumpulkan metrik, dan tidak memiliki tujuan setelah penampung lain di pod berhasil keluar).

Saran sebelumnya adalah untuk menunjuk beberapa wadah sebagai wadah "penyelesaian". Saya ingin mengusulkan yang sebaliknya -- kemampuan untuk menunjuk beberapa kontainer sebagai "sespan". Ketika container non-sidecar terakhir dalam sebuah Pod berakhir, Pod tersebut harus mengirimkan TERM ke sidecars.

Ini adalah solusi ideal saya juga. Saya mungkin menyarankan SIGHUP alih-alih SIGTERM - ini tampaknya merupakan kasus penggunaan yang tepat di mana semantik SIGHUP relevan! - tapi aku akan senang dengan salah satunya.

Karena itu, menjalankan pekerjaan di Kubernetes memerlukan patch image container upstream secara manual untuk menangani komunikasi antar-kontainer khusus Kubernetes ketika container non-sidecar selesai, atau campur tangan secara manual untuk menghentikan sidecar untuk setiap pekerjaan sehingga zombie pod tidak berkeliaran. Tidak ada yang sangat menyenangkan.

Saya bersedia membuat tambalan untuk ini tetapi ingin beberapa panduan dari @kubernetes/sig-apps-feature-requests sebelum menggali kode apa pun. Apakah kita baik-baik saja dengan menambahkan bidang sidecar ke spesifikasi pod agar ini berfungsi? Saya ragu untuk membuat perubahan apa pun pada spesifikasi pod tanpa memastikan kami menginginkannya. Mungkin menggunakan anotasi untuk saat ini?

@andrewsykim Saya telah mengikuti masalah ini untuk sementara waktu (hanya belum sempat mencoba mengatasinya sendiri), tetapi saya sarankan hanya menggunakan anotasi untuk saat ini.

Alasan saya adalah bahwa:

• Masalah ini telah ada selama hampir 2 tahun, dan belum benar-benar menarik banyak perhatian dari inti kubernetes. Oleh karena itu, jika kita menunggu untuk melakukan perubahan pada spesifikasi pod, atau menunggu input langsung, kita mungkin akan menunggu lama.
• PR yang bisa diterapkan jauh lebih mudah untuk diperhatikan daripada masalah lama.
• Seharusnya cukup bagus untuk mengganti pendekatan anotasi untuk menggunakan atribut pod di masa mendatang

Pikiran?

Hai, Saya berbicara dengan beberapa aplikasi sig di kubecon tentang masalah ini, pada dasarnya itu bukan sesuatu yang ada di peta jalan langsung mereka tetapi itu adalah sesuatu yang menurut mereka adalah kasus penggunaan yang valid. Mereka sangat terbuka untuk seseorang dari komunitas yang menangani ini.

Saya telah membuat PR untuk proposal peningkatan untuk menyelesaikan ini, jadi saya harap ini menghasilkan beberapa diskusi https://github.com/kubernetes/community/pull/2148 .

Terima kasih telah menyatukannya @Joseph-Irving! Sepertinya ada lebih banyak detail yang perlu ditangani untuk ini jadi saya akan menunda melakukan pekerjaan apa pun sampai saat itu :)

masalah jangka panjang yang persisten :(

cc @ kow3ns @janetkuo

Tanpa bermaksud memperumit masalah lebih lanjut, juga berguna untuk dapat menjalankan wadah gaya "sespan" bersama initContainers .

Kasus penggunaan saya mirip dengan orang-orang di sini, saya perlu menjalankan proxy cloud sql secara bersamaan dengan initContainer yang menjalankan migrasi database. Karena initContainers dijalankan satu per satu, saya tidak dapat melihat cara untuk melakukan ini, kecuali menjalankan proxy sebagai layanan + penerapan, tetapi saya berharap ada kasus penggunaan lain (manajemen log, dll.) di mana itu tidak akan menjadi pekerjaan yang cocok sekitar.

@mcfedr Ada proposal peningkatan yang cukup aktif yang mungkin menghargai pengamatan mengenai perilaku wadah init. Tidak jelas bagi saya apakah itu dalam lingkup proposal ini, atau peningkatan terkait, tetapi saya pikir itu cukup terkait sehingga masuk akal untuk diajukan untuk dipertimbangkan.

Meskipun demikian, potensi masalah implementasi/kompatibilitas, model ideal Anda mungkin adalah agar container init sespan berjalan bersamaan dengan container init non-sidecar, yang terus berjalan secara berurutan seperti sekarang, dan untuk sidecars berhenti sebelum container deret utama dimulai?

untuk apa nilainya, saya juga ingin mengungkapkan perlunya mengabaikan sidecars yang masih berjalan seperti CloudSQL Proxy et.al.

Saya berhasil mematikan wadah cloudsql setelah 30 detik karena saya tahu skrip saya tidak akan memakan waktu selama ini. Inilah pendekatan saya:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: schedule
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  startingDeadlineSeconds: 40
  jobTemplate:
    spec:
      completions: 1
      template:
        spec:
          containers:
          - image: someimage
            name: imagename
            args:
            - php
            - /var/www/html/artisan
            - schedule:run
          - command: ["sh", "-c"]
            args:
            - /cloud_sql_proxy -instances=cloudsql_instance=tcp:3306 -credential_file=some_secret_file.json & pid=$! && (sleep 30 && kill -9 $pid 2>/dev/null)
            image: gcr.io/cloudsql-docker/gce-proxy:1.11
            imagePullPolicy: IfNotPresent
            name: cloudsql
            resources: {}
            volumeMounts:
            - mountPath: /secrets/cloudsql
              name: secretname
              readOnly: true
          restartPolicy: OnFailure
          volumes:
          - name: secretname
            secret:
              defaultMode: 420
              secretName: secretname

Dan itu bekerja untuk saya.
Apakah kalian melihat ada kekurangan dalam pendekatan ini?

Karena saya pikir mereka terkait dan mudah beradaptasi untuk CronJobs juga, ini adalah solusi saya: https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/128#issuecomment -413444029

Ini didasarkan pada salah satu solusi yang diposting di sini tetapi menggunakan preStop karena itu dimaksudkan untuk penyebaran. Menjebak sespan akan bekerja dengan sangat baik.

Menyusul masalah ini. Juga menggunakan wadah cloud_sql_proxy sebagai mobil sampingan di cronjob
Saya menggunakan implementasi batas waktu oleh @stiko

Hanya menambahkan ke percakapan solusi yang diusulkan oleh @oxygen0211 tentang penggunaan Ganti adalah solusi yang layak untuk saat ini, pastikan untuk memeriksanya jika Anda mengalami masalah ini seperti yang saya lakukan.

https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -327396198

Kami telah mendapatkan KEP ini untuk sementara disetujui https://github.com/kubernetes/community/pull/2148 , kami masih memiliki beberapa hal yang perlu kami setujui tetapi mudah-mudahan itu akan sampai ke tempat di mana pekerjaan dapat dimulai relatif segera . Catatan KEP akan dipindahkan ke https://github.com/kubernetes/enhancements pada tanggal 30, jadi jika Anda ingin mengikutinya, itu akan ada di sana.

Hingga dukungan sespan tiba, Anda dapat menggunakan solusi tingkat buruh pelabuhan yang dapat dengan mudah dihapus nanti: https://Gist.github.com/janosroden/78725e3f846763aa3a660a6b2116c7da

Ia menggunakan wadah istimewa dengan soket buruh pelabuhan terpasang dan label kubernetes standar untuk mengelola wadah dalam pekerjaan.

Kami mengalami masalah yang sama dengan Istio dan mobil sampingnya, dan apa yang kami putuskan untuk dilakukan adalah menghapus pod melalui curl + preStop hook seperti ini

berikan pekerjaan Anda aturan RBAC minimal seperti ini

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myservice-job
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-job-rolebinding
subjects:
  - kind: ServiceAccount
    name: myservice-job
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myservice-role

dan POD_NAME dan POD_NAMESPACE ke ENV Anda seperti itu

   env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

dan akhirnya, tambahkan pengait preStop seperti

 lifecycle:
      preStop:
        exec:
          command: 
            - "/bin/bash" 
            - "-c"
            - "curl -X DELETE -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$POD_NAMESPACE/pods/$POD_NAME?gracePeriodSeconds=1"

Agak berantakan tetapi sedikit lebih aman dan tidak terlalu rewel daripada mencoba membunuh wadah buruh pelabuhan yang tepat.

Hanya melemparkan ini di sini, tetapi saya mengumpulkan pengontrol beberapa waktu lalu yang dimaksudkan untuk memantau perubahan pod yang sedang berjalan, dan mengirim SIGTERM ke wadah sespan dengan tepat. Ini jelas bukan yang paling kuat, dan sejujurnya saya sudah lama tidak menggunakannya, tetapi mungkin bisa membantu.

https://github.com/nrmitchi/k8s-controller-sidecars

Terima kasih kepada @jpalomaki di https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -371469801 atas saran untuk menjalankan cloud_sql_proxy sebagai penerapan dengan layanan ClusterIP , dan kepada @ cvallance di https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -364255363 untuk tip pengaturan tcp:0.0.0.0 di cloud_sql_proxy instances parameter untuk mengizinkan non -koneksi lokal ke proses. Bersama-sama mereka membuatnya tidak sulit untuk membiarkan pekerjaan cron menggunakan proxy.

masalah jangka panjang (catatan untuk diri sendiri)

Masalah yang sama. Mencari cara atau dokumen resmi tentang cara menggunakan GKE cron job dengan Cloud SQL

Catatan samping:
Google memperbarui Cloud SQL -> Menghubungkan dari dokumentasi Connecting using the Cloud SQL Proxy Docker image Anda dapat Connecting using a private IP address
Jadi jika Anda berada di sini untuk alasan yang sama dengan saya di sini (karena cloud_sql_proxy), Anda sekarang dapat menggunakan fitur baru dari Private IP

Catatan samping:
Google memperbarui Cloud SQL -> Menghubungkan dari dokumentasi Connecting using the Cloud SQL Proxy Docker image Anda dapat Connecting using a private IP address
Jadi jika Anda berada di sini untuk alasan yang sama dengan saya di sini (karena cloud_sql_proxy), Anda sekarang dapat menggunakan fitur baru dari Private IP

Fitur IP pribadi tampaknya perlu menghapus seluruh cluster dan membuatnya kembali........?

@cropse Itu hanya diperlukan jika cluster Anda bukan VPC-native.

Saya membuat solusi untuk masalah ini, bukan solusi yang bagus tetapi berhasil, semoga bantuan ini sebelum fitur ditambahkan, dan VPC adalah salah satu cara untuk sloved, tetapi menghapus seluruh cluster masih menyakitkan.

Hanya untuk menambahkan dua sen saya: tes helm juga rusak jika injeksi istio sespan terjadi karena pod tidak pernah selesai.

@dansiviter Anda dapat memeriksa solusi saya, saya sudah menguji proyek saya dengan helm.

berharap untuk melihat ini diterapkan! :)

kami memiliki masalah yang sama dengan pekerjaan normal ketika proxy Istio disuntikkan ke dalamnya, di atas itu kami juga menginginkan ini karena kami ingin menjalankan pekerjaan CI dengan Prow.
misalnya wadah aplikasi Rails + wadah basis data sespan untuk tujuan pengujian.

@cropse Terima kasih. Saya belum mencobanya karena kami perlu mengonfigurasi ini untuk semua tes. Kami hanya mengizinkan Pod (Sayangnya, Tes Helm tidak mengizinkan Job) gagal dan mengandalkan pemeriksaan log secara manual hingga masalah ini diperbaiki dalam jangka panjang. Namun, itu juga menjadi masalah bagi Pekerjaan lain, jadi kami mungkin harus mempertimbangkan kembali posisi itu.

FYI, masalah pelacakan untuk fitur ini ada di sini https://github.com/kubernetes/enhancements/issues/753 jika orang ingin mengikuti, kami punya KEP, melakukan beberapa prototyping (ada cabang/video POC ), masih perlu menyelesaikan beberapa detail implementasi sebelum statusnya dapat diimplementasikan.

Catatan samping:
Google memperbarui Cloud SQL -> Menghubungkan dari dokumentasi Connecting using the Cloud SQL Proxy Docker image Anda dapat Connecting using a private IP address
Jadi jika Anda berada di sini untuk alasan yang sama dengan saya di sini (karena cloud_sql_proxy), Anda sekarang dapat menggunakan fitur baru dari Private IP

Saya di sini karena alasan yang sama, namun, Cloud SQL kami disediakan sebelum fitur ini siap. Saya menggabungkan saran sebelumnya dan menghasilkan ini (mungkin tidak ideal, tetapi berhasil) untuk bagan helm migrasi dbmate saya.

      containers:
      - name: migrator
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/bin/bash", "-c"]
        args:
          - |
            /cloud_sql_proxy -instances={{ .Values.gcp.project }}:{{ .Values.gcp.region }}:{{ .Values.gcp.cloudsql_database }}=tcp:5432 -credential_file=/secrets/cloudsql/credentials.json &
            ensure_proxy_is_up.sh dbmate up
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: DATABASE_URL
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials

ensure_proxy_is_up.sh

#!/bin/bash

until pg_isready -d $(echo $DATABASE_URL); do
    sleep 1
done

# run the command that was passed in
exec "$@"

Apakah ini saat yang tepat untuk memahami container sespan di Kubernetes dan mengizinkan pembersihan pod berdasarkan apakah container non-sidecar telah selesai?

@Willux Saya menggunakan atm ponsel saya, jadi lebih sulit untuk menemukan tautan untuk referensi, tetapi apa yang baru saja Anda usulkan sudah berjalan dengan baik.

@krancour terima kasih atas pembaruannya. Aku pasti melewatkan detail itu. Tidak banyak aktivitas yang terjadi di sini akhir-akhir ini, jadi hanya ingin memastikan ada sesuatu yang sedang berlangsung :)

Untuk referensi, saya membuat versi sespan cloud-sql-proxy dari solusi @ jmillikin-stripe di mana file dalam volume bersama mengomunikasikan status ke sespan.

Ini berfungsi dengan baik, tetapi sejauh ini merupakan peretasan paling buruk dalam konfigurasi K8 saya :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

Adakah yang bisa internal proyek tolong beri komentar tentang kemajuan masalah ini?

Apakah adil untuk berasumsi bahwa ini adalah opsi terbaik bagi kita yang bekerja di saluran rilis stabil GKE, yang mungkin tidak akan mengejar Kubernetes 1.18 setidaknya selama beberapa bulan?

@Datamance pada titik ini KEP untuk mengatasi masalah ini sepertinya ditangguhkan tanpa batas waktu .

Saya memposting beberapa waktu lalu komentar ini , yang merupakan solusi lama saya. Saya tidak mencoba untuk mendorong barang-barang saya sendiri di sini, hanya saja komentar itu telah hilang di "100 komentar lagi ..." dari github dan menemukan pelapisan ulang mungkin berguna lagi.

@nrmitchi terima kasih telah memposting ulang itu. Saya salah satu yang telah mengabaikannya di lautan komentar dan ini terlihat seperti solusi jangka pendek yang fantastis.

Kami menemukan pendekatan yang berbeda, jika Anda menambahkan yang berikut ke container Pod Anda:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

maka Anda akan dapat mengambil Pid di wadah lain, kami akan menjalankan berikut di akhir wadah utama kami:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@krancour senang itu membantu. Jika Anda melihat jaringan di repositori itu, ada beberapa garpu yang hampir pasti berada di tempat yang lebih baik daripada garpu asli saya, dan mungkin lebih baik untuk dibangun/digunakan.

IIRC garpu lemonade-hq memiliki beberapa tambahan yang berguna.

@nrmitchi , saya telah melirik kodenya, tetapi mungkin lebih cepat untuk bertanya kepada Anda ...

Bisakah Anda memberi komentar singkat tentang prasyarat apa pun yang mungkin ada yang tidak disebutkan dalam README?

Misalnya, apakah gambar yang menjadi dasar sespan Anda memerlukan kesadaran khusus tentang solusi ini? misalnya Apakah mereka perlu mendengarkan pada port tertentu untuk sinyal dari pengontrol? Atau mungkin mereka harus menyertakan shell tertentu (bash?)

@krancour Saya akan

Itu dirancang pada saat itu sehingga wadah yang dimaksud tidak perlu mengetahui penyelesaiannya. Kami menggunakan aplikasi pihak ketiga terutama di sespan (misalnya, saya percaya stripe/veneur adalah salah satunya), dan tidak ingin bercabang/memodifikasi.

Satu-satunya persyaratan dari sespan adalah bahwa mereka benar mendengarkan sinyal SIGTERM, dan kemudian dimatikan. Saya ingat memiliki beberapa masalah dengan kode pihak ketiga yang berjalan di sespan yang mengharapkan sinyal yang berbeda dan harus diselesaikan, tetapi sebenarnya pengontrol seharusnya mengizinkan sinyal yang dikirim untuk ditentukan (yaitu, SIGINT alih-alih SIGTERM).

Mereka tidak perlu mendengarkan port mana pun untuk sinyal, karena pengontrol menggunakan exec untuk memberi sinyal ke proses utama sespan secara langsung. IIRC pada saat fungsionalitas tersebut disalin dari kode kubernetes karena tidak ada di klien. Saya percaya ini ada di klien resmi sekarang dan mungkin harus diperbarui.

Kami menemukan pendekatan yang berbeda, jika Anda menambahkan yang berikut ke container Pod Anda:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

maka Anda akan dapat mengambil Pid di wadah lain, kami akan menjalankan berikut di akhir wadah utama kami:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ruiyang2015 terima kasih untuk peretasan ini.
Jika ada yang mengimplementasikannya, pastikan untuk memahami implikasi dari berbagi proses ns di antara wadah

@nrmitchi

menggunakan eksekutif untuk memberi sinyal proses utama sespan secara langsung

Itu adalah bagian dari mengapa saya bertanya... Saya kira, secara khusus, saya bertanya-tanya apakah ini tidak berfungsi untuk wadah berdasarkan gambar yang dibuat FROM scratch .

@krancour Poin yang adil, saya tidak pernah pergi dan mengujinya dengan wadah yang keluar dari scratch . Melihat kode (atau versi asli saya; ini bisa berubah dalam fork) sepertinya akan tergantung pada bash , tetapi harus dapat dimodifikasi.

itu akan tergantung pada bash, tetapi harus dapat dimodifikasi

Tentu, tetapi selama dijalankan, itu akan selalu bergantung pada beberapa biner yang ada di wadah dan untuk wadah awal, tidak ada _apa pun_ di sana kecuali apa pun yang Anda taruh di sana secara eksplisit. 🤷♂.

Mengingat batasan itu, saya tidak dapat menggunakan ini untuk kasus penggunaan di mana wadah yang sedang berjalan mungkin benar-benar arbitrer dan ditentukan oleh pihak ketiga. Oh-- dan kemudian saya juga memiliki wadah Windows.

Saya akan menyebutkan apa yang akan saya selesaikan sebagai gantinya. Ini mungkin terlalu berat untuk sebagian besar kasus penggunaan, tetapi saya menyebutkannya jika kasus penggunaan orang lain cukup mirip dengan milik saya untuk lolos dari ini ...

Saya dapat membeli kemewahan hanya dengan _menghapus_ pod yang wadah "primer"-nya telah keluar, selama saya mencatat status keluar terlebih dahulu. Jadi pada akhirnya saya akan menulis pengontrol yang akan memantau beberapa wadah yang ditunjuk (melalui anotasi) untuk penyelesaian, mencatat keberhasilan atau kegagalannya di penyimpanan data yang sudah melacak status "pekerjaan", dan kemudian menghapus pod seluruhnya.

Untuk ukuran yang baik, saya mungkin akan menunda penghapusan pod untuk memaksimalkan peluang agregasi log pusat saya untuk mendapatkan beberapa baris terakhir dari keluaran wadah utama sebelum ditorpedo.

Tangan berat, tetapi mungkin berhasil untuk beberapa orang.

@krancour Benar sekali. Seperti, pengontrol tidak akan berfungsi untuk basis penggunaan yang sewenang-wenang. Sejujurnya saya tidak pernah kembali dan mencoba untuk mengabstraksikan beberapa implementasi untuk mendukung kasus lain karena saya benar-benar berpikir bahwa KEP yang disebutkan sebelumnya akan digabungkan dan membuat kebutuhan akan fungsi ini diperdebatkan.

Mengingat bahwa masalah ini seperti berusia 4 tahun, KEP belum pergi ke mana pun, dan keadaan seni adalah skrip shell inline hacky yang menggantikan setiap titik masuk, saya memutuskan untuk mengkodifikasi peretasan "standar" (batu nisan dalam volume bersama ) menjadi biner Go yang dapat dengan mudah dimasukkan ke dalam gambar container menggunakan build multi-tahap.

https://github.com/karlkfi/kubexit

Ada beberapa cara untuk menggunakannya:

1. Panggang ke dalam gambar Anda
2. Muat samping menggunakan wadah init dan volume sementara.
3. Sediakan di setiap node dan muat di samping ke dalam wadah menggunakan host bind mount

Sunting: v0.2.0 sekarang mendukung "ketergantungan kelahiran" (mulai tertunda) dan "ketergantungan kematian" (penghentian sendiri).

Komentar drive-by: ini terlihat persis seperti https://github.com/kubernetes/enhancements/issues/753

@vanzin seperti yang telah dicatat sebelumnya , bahwa KEP ditahan tanpa batas waktu.

Kasus penggunaan saya untuk ini adalah bahwa Vault menyediakan kredensial untuk menjalankan CronJob. Setelah tugas selesai, sespan Vault masih berjalan dengan Pekerjaan dalam status tertunda dan itu memicu sistem pemantauan berpikir bahwa ada sesuatu yang salah. Sayang sekali apa yang terjadi pada KEP.