建立目標規則和預設路由
使用istio來管理這兩個服務的流量
定義乙個名稱為nginx-web的destinationrule 目標規則,
利用pod標籤把nginx-web服務分成兩個subset, 分別命名為v1和v2
# nginx-destinationrule.yaml
apiversion: networking.istio.io/v1alpha3
kind: destinationrule
metadata:
name: nginx-web
spec:
host: nginx-web
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
#### 部署到集群上
定義乙個virtualservice物件，它負責接管對 「nginx-web」這一主機名的訪問，
將流量都**到destinationrule定義的v2 subset上
#### 部署到集群上再次進入客戶端pod， 看看新定義的流量管理規則是否生效
### 結果可以看出，訪問只返回 v2 版本
# kubectl exec -it sleep-7995b95fdb-8vzmx sh
defaulting container name to sleep.
use 'kubectl describe pod/sleep-7995b95fdb-8vzmx -n default' to see all of the containers in this pod.
/ # while true; do curl http://nginx-web:80 ; sleep 1; done
借助這一過程能夠驗證新版本是否存在問題，然後能夠確保以更高的質量發布給更多的受眾
將 20% 的使用者傳送至帶有缺陷的 v2 版本（這就是金絲雀發布），
並將 80% 的使用者傳送至正常的服務 v1 版本
這可以通過如下的 virtualservice 來實現
#### 部署到集群上再次進入客戶端pod， 看看新定義的流量管理規則是否生效
### 結果可以看出，大部分結果返回 v1 版本
# kubectl exec -it sleep-7995b95fdb-8vzmx sh
defaulting container name to sleep.
use 'kubectl describe pod/sleep-7995b95fdb-8vzmx -n default' to see all of the containers in this pod.
/ # while true; do curl http://nginx-web ; sleep 1; done
三分之一的概率遇到伺服器內部錯誤，其餘的請求均能正常完成。
為了降低這些缺陷的影響並給使用者帶來更好的使用者體驗，我們會採取如下的措施：
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...
流量管理 不同環境服務訪問
這個沒有實現 使用 istio 的路由規則管理，還可以配置對不同環境 prod,staging,dev等 的同一服務的訪問規則。由於我的實驗環境沒有搭建多環境的集群，這裡指使用官方的demo來做描述。通常在乙個集群中如果搭建多環境的情況可以使用namespace來進行劃分，而使用上面的方式就可以實現...