使用Istio打造企業內的SRE
今天又是一年一度的Kubernetes Summit，時間過得真快～三年前第一次在八德大樓參加，聽著各個大拿在台上的分享。後來連續兩年感謝VMware的贊助，讓我有機會登台，跟大家分享PKS和ClusterAPI，到今年的Istio。
看著Kubernetes在這三年的時間，由一個社群裡的新技術，到已經登上企業的生產環境。猶記三年前的Keynote是由91App的CTO開場，感覺是個酷炫的新科技，到今年是由國泰金控首席架構師開場，K8S已經步上了企業的生產殿堂，一路走來真的很令人雀躍與振奮。
抒發了自己的一點心情，來跟大家分享我今天的Slide～『透過Istio，打造企業的SRE』。這個標題，主要是希望讓大家能夠了解Google開發Istio與K8S，其實一直是圍繞在Google SRE的需求為出發。今天的分享主要分為三段：
- 介紹SRE的三個內涵：
- Decision based on data: 所有的決定是以資料為基礎
- Be user centric: 即使所有的監控數據都是正常的，但客戶只要覺得系統不穩定，那系統就是不穩定
- Blameless culture & Share responsibility: 降低部門隔閡要由跨部門的責任分享開始(Developers, Operators, Leader) 系統，系統失效不僅是維運者的責任，程式碼品質，技術債等都是可能的原因
2. 透過Istio監控所預定的Service Level Objective(SLO)、拓墣、與Trace：
介紹SRE最重要的指標：SLO(Service Level Objective)/Error Budget，其實我在之前Blog有分享過，大家可以參照。其中Error Budget是一個量化指標，將原本SLO使用的機率，轉換為Stakeholder比較能理解的：可允許失效的剩餘時間。
一個好的SLO，必須是跟客戶感受相關連的，更必須以數據為依歸（別再說100%了)…Istio所提供的Kiali與Jaeger都提供了Out-of-box的UI，可以快速透視微服務的狀態。再配合LoadGenerator，少量的『黑箱監控』，就能夠盡可能的模擬使用者的使用狀態，達到SRE本身所應允的SLO。
3. 降低Error Budget的Burn Down Rate:
Error Budget會因為每次的系統失效或不如預期，而會越燒越少的成本。SRE必須努力維持這個數字不要成為負值。因此一個好的SRE應該盡一切努力，降低這個成本的燃燒率。可以努力的方向有四個：
- 減少Time to detect (TTD)與Time to repair (TTR)：越早發現問題，越快修好，就可以降低Budget Burn Rate。這個除了透過Kubernetes本身的Healing能力外，還可以透過GitOps的方式，降低手動操作所帶來的不穩定性（e.g. 誤篩負載與重要網路元件等）
- 減低Impact%：在每次有變動時，能夠縮小變動的範圍（e.g. 實施金絲雀部署，或是少量的AB Testing等），就可以縮小可能因變動所造成的不穩定性。Istio裡面的VirtualService + DestinationRules就可以很有效地做到這一點。
- 延長Time-to-Failure(TTF)：Time-to-Failure多是指客觀的不可抗力因素，讓服務不小心失效（舉例：機房停電，周邊硬體失效等）。為了要能延長這個值，Istio所帶來跨叢集(Multi-Cluster)的高可用性服務，就會是一個很重要的機制。Istio 的Multi-Cluster通常可通過Shared Control Plane or Replicated Control Plane來實現。今天透過展示打造台北+新加坡的高可用性服務，希望帶給大家一些想法和啟發。
這個Talk，希望能夠讓大家更了解Kubernetes社群設計這個產品的方向和初衷。Google相關在K8S上的開源，特別是Istio的許多功能都是為了更致能SRE，畢竟K8S平台上的自動化工具越多，SRE就能夠有更多的時間，為自己工作上，進行因企業需求，所客制的自動化。如果有任何的想法和問題，也歡迎留言給我交流討論。
