在Kubernetes中，Probe探針是一種實用的功能，可以用於控制應用程式的優雅上線和監控其健康狀況。本篇文章將深入探討Probe探針的相關概念和用法。

就緒探針

就緒探針主要用於確認容器是否已準備好接受流量。當Service與多個Pod關聯時，如果其中一個Pod正在重新啟動或尚未準備好提供服務，就緒探針可以防止流量被錯誤地導向該Pod，避免服務的中斷。

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /ping
    port: 8081
    scheme: HTTP
  periodSeconds: 3
  successThreshold:1
  timeoutSeconds: 1
  

這個配置中的各項參數如下：

• failureThreshold ：連續失敗的探測次數，達到此閾值後容器將被重新啟動。
• httpGet ：使用HTTP GET請求進行探測，指定路徑、埠號和協定。
• periodSeconds ：探測間隔，單位為秒。
• successThreshold ：連續成功的探測次數，達到此閾值後容器被視為就緒。
• timeoutSeconds ：HTTP請求的超時時間，單位為秒。

啟動探針

啟動探針與就緒探針通常搭配使用。如果一個Pod的啟動時間過長，啟動探針可以檢測並確保Pod已正確啟動，直到啟動成功後才進行後續探測。

startupProbe:
  failureThreshold: 30
httpGet:
    path: /ping
    port: 8081
    scheme: HTTP
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 1
  

存活探針

存活探針用於確保應用程式的持續可用性。雖然Kubernetes可以自動重新啟動退出的Pod，但它無法檢測應用的假死狀態。存活探針可以幫助在這種情況下自動重新啟動Pod。

livenessProbe:
  failureThreshold: 3
  httpGet:
    path: /ping
    port: 8081
    scheme: HTTP
  periodSeconds: 3
  successThreshold: 1
  timeoutSeconds: 1
  

如果應用程式對探測請求的響應失敗，Kubernetes將嘗試重新啟動Pod。

探針配置的最佳實踐

建議將探針配置可視化在開發平台上，以方便維護。探針是保持應用程式健康的必要手段，強烈建議定期配置和監控探針的運行狀況。

• 就緒探針：確保Pod在被導向流量之前已準備好提供服務。
• 啟動探針：防止Pod因過長的啟動時間而無限重新啟動。
• 存活探針：確保應用程式在假死狀態時被自動重新啟動。

通过使用Probe探针，可以有效地控制应用优雅上线，并保障应用的高可用性。建议在日常运维中积极应用Probe探针，以提升应用的稳定性和可靠性。

一文让你全面了解K8s(Kubernetes)

深入探索Kubernetes：全面指南

Kubernetes（K8S），由Google于2014年开源，如今已成为企业级应用和云计算的基石。它专为部署、扩展和管理容器化应用而设计，支持微服务架构、自动化部署、弹性伸缩、多租户和持续集成/持续交付（CI/CD）等场景。K8S集群由Master节点和Worker节点构成，Master负责集群管理和智能调度。

Master节点的基石

K8S的广泛应用

关键组件与功能

K8S生态系统丰富，包括Pod、Service、Namespace等核心概念，以及Controller（如Deployment、StatefulSet）和扩展工具（如Ingress Controller、DNS和监控工具）。

实战部署与配置

实用工具与最佳实践

Kubernetes凭借其强大且灵活的框架，为企业级应用提供了可靠和高效的容器化解决方案。不断发展的社区和丰富的开源项目，如Grafana和Fluentd，确保了K8S的持续优化和扩展性。

k8s 上 go 微服务实战: go 实现 istio bookinfo 微服务

在完成k8s 上快速部署 go 服务和k8s: istio 入门后, 继续 膨胀 , 使用 go 来实现 istio 提供的 bookinfo 微服务 demo

快速回顾之前的 blog:

涉及到的问题:

简单实践步骤:

先回顾一下 bookinfo 微服务应用的端到端架构:

包含 4 个微服务:

可以参考k8s 上 go 服务实战: 使用 helm 快速构建云原生应用快速部署 rating 服务

同理, 实现productpage detail服务

istio 几乎涵盖了 服务治理/流量控制 的方方面面, 作为服务治理层的基础设施 完全够用 , 问题开始从 行不行 , 转向 用哪些 , 让 业务层/devops工作流/k8s基础设施 用起来更爽

还需要解决的问题: