Bagaimana untuk menyelesaikan ralat 502 semasa menaik taraf aplikasi projek springboot perkhidmatan k8s

Memandangkan model pembangunan langkah kecil dan lelaran pantas diiktiraf dan diterima pakai oleh semakin banyak syarikat Internet, kekerapan perubahan dan peningkatan aplikasi menjadi semakin kerap. Untuk menampung keperluan naik taraf yang berbeza dan memastikan proses naik taraf berjalan lancar, satu siri model penggunaan dan keluaran telah dilahirkan.

• Hentikan keluaran - hentikan sepenuhnya versi lama tika aplikasi dan kemudian keluarkan versi baharu. Model keluaran ini terutamanya untuk menyelesaikan masalah ketidakserasian dan ketidakupayaan untuk wujud bersama antara versi baharu dan lama Kelemahannya ialah perkhidmatan itu tidak tersedia sepenuhnya untuk satu tempoh masa.

• Keluaran biru-hijau - gunakan bilangan contoh aplikasi versi baharu dan lama yang sama dalam talian pada masa yang sama. Selepas versi baharu lulus ujian, trafik akan ditukar kepada contoh perkhidmatan baharu sekaligus. Model penerbitan ini menyelesaikan masalah ketiadaan perkhidmatan lengkap dalam penerbitan masa henti, tetapi ia akan menyebabkan penggunaan sumber yang agak besar.

• Keluaran Berguling - Gantikan tika aplikasi secara beransur-ansur dalam kelompok. Mod keluaran ini tidak akan mengganggu perkhidmatan dan tidak akan menggunakan terlalu banyak sumber tambahan Walau bagaimanapun, memandangkan contoh versi lama dan baharu berada dalam talian pada masa yang sama, ia boleh menyebabkan permintaan daripada klien yang sama bertukar antara versi lama dan baharu, menyebabkan. isu keserasian.

• Keluaran Canary - Tukar trafik secara beransur-ansur daripada versi lama kepada versi baharu. Jika tiada masalah ditemui selepas memerhati untuk tempoh masa, trafik versi baharu akan diperluaskan lagi manakala trafik versi lama akan dikurangkan.

• Ujian A/B - lancarkan dua atau lebih versi pada masa yang sama, kumpulkan maklum balas pengguna tentang versi ini, analisa dan nilai versi terbaik untuk penerimaan rasmi.

Naik taraf aplikasi K8s

Dalam k8s, pod ialah unit asas penggunaan dan peningkatan. Secara umumnya, pod mewakili contoh aplikasi, dan pod akan digunakan dan dijalankan dalam bentuk Deployment, StatefulSet, DaemonSet, Job, dsb. Berikut menerangkan kaedah naik taraf pod dalam borang penempatan ini.

Pengerahan

Pengerahan ialah bentuk pengerahan pod yang paling biasa Di sini kita akan mengambil aplikasi java berdasarkan but spring sebagai contoh. Aplikasi ini adalah versi ringkas yang disarikan daripada aplikasi sebenar dan sangat representatif Ia mempunyai ciri-ciri berikut:

• Selepas aplikasi dimulakan, ia mengambil masa tertentu untuk memuatkan. konfigurasi Dalam masa ini, perkhidmatan tidak boleh disediakan secara luaran.

• Boleh memulakan aplikasi tidak bermakna ia boleh menyediakan perkhidmatan seperti biasa.

• Aplikasi mungkin tidak akan keluar secara automatik jika ia tidak dapat menyediakan perkhidmatan.

• Semasa proses naik taraf, adalah perlu untuk memastikan bahawa contoh aplikasi yang akan pergi ke luar talian tidak akan menerima permintaan baharu dan mempunyai masa yang cukup untuk memproses permintaan semasa.

Konfigurasi Parameter

Untuk mencapai masa henti sifar dan tiada peningkatan gangguan pengeluaran untuk aplikasi dengan ciri-ciri di atas, parameter yang berkaitan dalam Deployment perlu dikonfigurasikan dengan teliti. Konfigurasi yang berkaitan dengan peningkatan di sini adalah seperti berikut (lihat spring-boot-probes-v1.yaml untuk konfigurasi lengkap).

kind: Deployment
...
spec:
  replicas: 8
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 2
  minReadySeconds: 120
  ...
  template:
    ...
    spec:
      containers:
      - name: spring-boot-probes
        image: registry.cn-hangzhou.aliyuncs.com/log-service/spring-boot-probes:1.0.0
        ports:
        - containerPort: 8080
        terminationGracePeriodSeconds: 60
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 1
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 40
          periodSeconds: 20
          successThreshold: 1
          failureThreshold: 3
        ...

Strategi konfigurasi

Melalui strategi, anda boleh mengkonfigurasi strategi penggantian pod Parameter utama adalah seperti berikut.

• .spec.strategy.type - digunakan untuk menentukan jenis dasar untuk menggantikan pod. Parameter ini boleh mengambil nilai Buat Semula atau RollingUpdate dan lalai ialah RollingUpdate.

• Buat Semula - K8s akan memadamkan semua pod asal dan kemudian mencipta pod baharu. Kaedah ini sesuai untuk senario di mana versi lama dan baharu tidak serasi antara satu sama lain dan tidak boleh wujud bersama. Walau bagaimanapun, memandangkan kaedah ini akan menyebabkan perkhidmatan tidak tersedia sepenuhnya untuk satu tempoh masa, ia mesti digunakan dengan berhati-hati di luar senario di atas.

• RollingUpdate - K8s akan menggantikan pod secara beransur-ansur dalam kelompok, yang boleh digunakan untuk melaksanakan peningkatan perkhidmatan panas.

• .spec.strategy.rollingUpdate.maxSurge - Menentukan bilangan maksimum pod tambahan yang boleh dibuat semasa proses kemas kini rolling, sama ada sebagai nombor atau peratusan. Semakin besar nilai yang ditetapkan, semakin cepat peningkatan akan dilakukan, tetapi akan menggunakan lebih banyak sumber sistem.

• .spec.strategy.rollingUpdate.maxUnavailable - Menentukan bilangan maksimum pod yang dibenarkan untuk tidak tersedia semasa proses kemas kini rolling, yang boleh menjadi nombor atau peratusan. Semakin besar nilai yang ditetapkan, semakin cepat peningkatan akan dilakukan, tetapi perkhidmatan akan menjadi lebih tidak stabil.

Dengan melaraskan maxSurge dan maxUnavailable, anda boleh memenuhi keperluan peningkatan dalam senario yang berbeza.

• Jika anda ingin menaik taraf secepat mungkin sambil memastikan ketersediaan dan kestabilan sistem, anda boleh menetapkan maxUnavailable kepada 0 dan memberikan maxSurge nilai yang lebih besar.

• Jika sumber sistem ketat dan beban pod rendah, untuk mempercepatkan peningkatan, anda boleh menetapkan maxSurge kepada 0 dan memberikan maxUnavailable nilai yang lebih besar. Perlu diingat bahawa jika maxSurge ialah 0 dan maxUnavailable adalah DIKEHENDAKI, ia boleh menyebabkan keseluruhan perkhidmatan tidak tersedia Pada masa ini, RollingUpdate akan menurun kepada keluaran penutupan.

Sampel memilih penyelesaian kompromi, menetapkan maxSurge kepada 3 dan maxUnavailable kepada 2, mengimbangi kestabilan, penggunaan sumber dan kelajuan naik taraf.

Prob konfigurasi

K8s menyediakan dua jenis probe berikut:

• ReadinessProbe - Secara lalai, sebaik sahaja semua bekas dalam pod dimulakan, k8s akan menganggap pod berada dalam keadaan sedia dan menghantar trafik ke pod. Walau bagaimanapun, selepas beberapa aplikasi dimulakan, mereka masih perlu melengkapkan pemuatan data atau fail konfigurasi sebelum mereka boleh menyediakan perkhidmatan luaran Oleh itu, adalah tidak ketat untuk menilai sama ada bekas itu telah dimulakan. Dengan mengkonfigurasi probe kesediaan untuk bekas, k8s boleh menentukan dengan lebih tepat sama ada bekas itu sudah sedia, dengan itu membina aplikasi yang lebih mantap. K8s memastikan bahawa hanya apabila semua bekas dalam pod melepasi pengesanan kesediaan, perkhidmatan dibenarkan menghantar trafik ke pod. Setelah pengesanan kesediaan gagal, k8s akan berhenti menghantar trafik ke pod.

• LivenessProbe - Secara lalai, k8s akan mempertimbangkan bekas yang dijalankan untuk tersedia. Tetapi penghakiman ini boleh menjadi masalah jika permohonan tidak boleh keluar secara automatik apabila berlaku masalah atau menjadi tidak sihat (contohnya, jalan buntu yang teruk berlaku). Dengan mengkonfigurasi kuar hidup untuk bekas, k8s boleh menentukan dengan lebih tepat sama ada bekas itu berjalan seperti biasa. Jika bekas gagal dalam pengesanan keaktifan, kubelet akan menghentikannya dan menentukan tindakan seterusnya berdasarkan dasar mulakan semula.

Konfigurasi probe sangat fleksibel. Pengguna boleh menentukan kekerapan pengesanan probe, ambang kejayaan pengesanan, ambang kegagalan pengesanan, dsb. Untuk maksud dan kaedah konfigurasi bagi setiap parameter, sila rujuk dokumen Konfigurasikan Keaktifan dan Siasatan Kesediaan.

Sampel mengkonfigurasi kuar kesediaan dan kuar hidup untuk bekas sasaran:

• DelaySecond permulaan kuar kesediaan ditetapkan kepada 30, kerana aplikasi mengambil purata masa 30 saat untuk menyelesaikan kerja permulaan.

• Apabila mengkonfigurasi probe liveness, anda perlu memastikan bahawa bekas mempunyai masa yang cukup untuk mencapai keadaan sedia. Jika parameter initialDelaySeconds, periodSeconds dan failureThreshold ditetapkan terlalu kecil, ia boleh menyebabkan bekas dimulakan semula sebelum ia bersedia, supaya keadaan sedia tidak boleh dicapai. Konfigurasi dalam sampel memastikan bahawa jika bekas itu sedia dalam masa 80 saat dari permulaan, ia tidak akan dimulakan semula, yang merupakan penimbal yang mencukupi berbanding dengan purata masa permulaan 30 saat.

• TempohDetik siasatan kesediaan ditetapkan kepada 10 dan Ambang kegagalan ditetapkan kepada 1. Dengan cara ini, apabila kontena tidak normal, tiada trafik akan dihantar kepadanya selepas kira-kira 10 saat.

• TempohDetik siasatan liveness ditetapkan kepada 20, dan Ambang kegagalan ditetapkan kepada 3. Dengan cara ini, apabila bekas tidak normal, ia tidak akan dimulakan semula selepas kira-kira 60 saat.

Konfigurasikan minReadySeconds

Secara lalai, setelah pod yang baru dibuat siap, k8s akan menganggap pod itu tersedia dan memadamkan pod lama. Tetapi kadangkala masalah mungkin terdedah apabila pod baharu sebenarnya memproses permintaan pengguna, jadi pendekatan yang lebih mantap ialah memerhati pod baharu untuk satu tempoh masa sebelum memadam pod lama.

Parameter minReadySeconds boleh mengawal masa pemerhatian apabila pod berada dalam keadaan sedia. Jika bekas dalam pod boleh berjalan seperti biasa dalam tempoh ini, k8s akan mempertimbangkan pod baharu tersedia dan memadam pod lama. Apabila mengkonfigurasi parameter ini, anda perlu menimbangnya dengan teliti Jika ia ditetapkan terlalu kecil, ia boleh menyebabkan pemerhatian tidak mencukupi. Jika ia ditetapkan terlalu besar, ia akan melambatkan kemajuan naik taraf. Contoh menetapkan minReadySeconds kepada 120 saat, yang memastikan bahawa pod dalam keadaan sedia boleh melalui kitaran pengesanan keaktifan yang lengkap.

Konfigurasikan penamatanGracePeriodSeconds

Apabila k8s bersedia untuk memadamkan pod, ia akan menghantar isyarat TERM kepada bekas dalam pod dan mengeluarkan pod daripada senarai titik akhir perkhidmatan. Jika bekas tidak boleh ditamatkan dalam masa yang ditetapkan (lalai 30 saat), k8s akan menghantar isyarat SIGKILL kepada bekas untuk menamatkan proses secara paksa. Untuk proses terperinci penamatan Pod, sila rujuk dokumen Penamatan Pod.

Memandangkan aplikasi mengambil masa sehingga 40 saat untuk memproses permintaan, untuk membolehkannya memproses permintaan yang telah tiba di pelayan sebelum ditutup, sampel menetapkan masa penutupan yang anggun selama 60 saat. Untuk aplikasi yang berbeza, anda boleh melaraskan nilai penamatanGracePeriodSeconds mengikut keadaan sebenar.

Perhatikan tingkah laku naik taraf

Konfigurasi di atas boleh memastikan peningkatan lancar aplikasi sasaran. Kami boleh mencetuskan peningkatan pod dengan menukar mana-mana medan PodTemplateSpec dalam Deployment dan memerhatikan tingkah laku naik taraf dengan menjalankan arahan kubectl get rs -w. Perubahan dalam bilangan salinan pod versi lama dan baharu yang diperhatikan di sini adalah seperti berikut:

• Buat pod baharu maxSurge. Pada masa ini, jumlah bilangan pod mencapai had atas yang dibenarkan, iaitu DESIRED + maxSurge.

• Segera mulakan proses pemadaman pod lama maxUnavailable tanpa menunggu pod baharu sedia atau tersedia. Pada masa ini, bilangan pod yang tersedia adalah DILARANG - maxUnavailable.

• Jika pod lama dipadamkan sepenuhnya, pod baharu akan ditambah serta-merta.

• Pod baharu melepasi pengesanan kesediaan dan menjadi sedia, dan k8 akan menghantar trafik ke pod. Walau bagaimanapun, memandangkan masa pemerhatian yang ditentukan belum dicapai, pod tidak akan dianggap tersedia.

• Pod sedia dianggap tersedia jika ia berjalan seperti biasa semasa tempoh pemerhatian Pada masa ini, proses pemadaman pod lama boleh dimulakan semula.

• Ulang langkah 3, 4 dan 5 sehingga semua pod lama dipadamkan dan pod baharu yang tersedia mencapai bilangan sasaran replika.

失败回滚

应用的升级并不总会一帆风顺，在升级过程中或升级完成后都有可能遇到新版本行为不符合预期需要回滚到稳定版本的情况。K8s 会将 PodTemplateSpec 的每一次变更（如果更新模板标签或容器镜像）都记录下来。这样，如果新版本出现问题，就可以根据版本号方便地回滚到稳定版本。回滚 Deployment 的详细操作步骤可参考文档 Rolling Back a Deployment。

StatefulSet

StatefulSet 是针对有状态 pod 常用的部署形式。针对这类 pod，k8s 同样提供了许多参数用于灵活地控制它们的升级行为。好消息是这些参数大部分都和升级 Deployment 中的 pod 相同。这里重点介绍两者存在差异的地方。

策略类型

在 k8s 1.7 及之后的版本中，StatefulSet 支持 OnDelete 和 RollingUpdate 两种策略类型。

• OnDelete - 当更新了 StatefulSet 中的 PodTemplateSpec 后，只有手动删除旧的 pod 后才会创建新版本 pod。这是默认的更新策略，一方面是为了兼容 k8s 1.6 及之前的版本，另一方面也是为了支持升级过程中新老版本 pod 互不兼容、无法共存的场景。

• RollingUpdate - K8s 会将 StatefulSet 管理的 pod 分批次逐步替换掉。它与 Deployment 中 RollingUpdate 的区别在于 pod 的替换是有序的。例如一个 StatefulSet 中包含 N 个 pod，在部署的时候这些 pod 被分配了从 0 开始单调递增的序号，而在滚动更新时，它们会按逆序依次被替换。

Partition

可以通过参数.spec.updateStrategy.rollingUpdate.partition实现只升级部分 pod 的目的。在配置了 partition 后，只有序号大于或等于 partition 的 pod 才会进行滚动升级，其余 pod 将保持不变。

Partition 的另一个应用是可以通过不断减少 partition 的取值实现金丝雀升级。具体操作方法可参考文档 Rolling Out a Canary。

DaemonSet

DaemonSet 保证在全部（或者一些）k8s 工作节点上运行一个 pod 的副本，常用来运行监控或日志收集程序。对于 DaemonSet 中的 pod，用于控制它们升级行为的参数与 Deployment 几乎一致，只是在策略类型方面略有差异。DaemonSet 支持 OnDelete 和 RollingUpdate 两种策略类型。

• OnDelete - 当更新了 DaemonSet 中的 PodTemplateSpec 后，只有手动删除旧的 pod 后才会创建新版本 pod。这是默认的更新策略，一方面是为了兼容 k8s 1.5 及之前的版本，另一方面也是为了支持升级过程中新老版本 pod 互不兼容、无法共存的场景。

• RollingUpdate - 其含义和可配参数与 Deployment 的 RollingUpdate 一致。

滚动更新 DaemonSet 的具体操作步骤可参考文档 Perform a Rolling Update on a DaemonSet。

Job

Deployment、StatefulSet、DaemonSet 一般用于部署运行常驻进程，而 Job 中的 pod 在执行完特定任务后就会退出，因此不存在滚动更新的概念。当您更改了一个 Job 中的 PodTemplateSpec 后，需要手动删掉老的 Job 和 pod，并以新的配置重新运行该 job。

总结

K8s 提供的功能可以让大部分应用实现零宕机时间和无生产中断的升级，但也存在一些没有解决的问题，主要包括以下几点：

• 目前 k8s 原生仅支持停机发布、滚动发布两类部署升级策略。如果应用有蓝绿发布、金丝雀发布、A/B 测试等需求，需要进行二次开发或使用一些第三方工具。

• K8s 虽然提供了回滚功能，但回滚操作必须手动完成，无法根据条件自动回滚。

• 有些应用在扩容或缩容时同样需要分批逐步执行，k8s 还未提供类似的功能。

实例配置：

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /user/service/test
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 40
  periodSeconds: 20
  successThreshold: 1
  timeoutSeconds: 1
name: dataline-dev
ports:
  - containerPort: 8080
    protocol: TCP
readinessProbe:
  failureThreshold: 1
  httpGet:
    path: /user/service/test
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 30
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 1

经测试 ， 再对sprintboot 应用进行更新时， 访问不再出现502的报错。

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan ralat 502 semasa menaik taraf aplikasi projek springboot perkhidmatan k8s. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!