部署參考：
預先準備
部署Istio服務網格
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.9.4
#設置路徑，可加入~/.profile
#export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y
#Add a namespace label to instruct Istio to automatically inject Envoy sidecar proxies when you deploy your application later:
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled
部署metallb本地負載均衡服務
部署local path本地存儲服務
快速安裝：
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
部署 hostPath 的 Persistent Volume 和使用 pod樣例：
kubectl create -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pvc/pvc.yaml
kubectl create -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/examples/pod/pod.yaml
KubeFlow 1.2部署遺留問題
部署完了有一些問題，部分服務無法啓動。經檢查發現幾個主要問題：
- pvc未正常創建，導致相關的服務pod運行失敗。
- 部分鏡像的下載策略被設置爲了always，但是其位於gcr.io上，導致下載失敗。
- 缺失鏡像kfam/kfserving。
下面針對這幾個問題逐一解決。
1、pvc刪除和重建
因爲沒有網絡存儲服務，使用local path。
將namespace爲kubeflow下的pvc全部刪除，主要包括：
- katib-mysql
- metadata-mysql
- minio-pvc
- mysql-pv-claim
然後添加StorageClass配置參數（這裏使用local-path），重新創建pvc。
然後到pod列表中刪除相關的pod，讓系統自動重新創建，過一段時間就恢復正常了。
2、鏡像下載策略修改
部分鏡像的下載策略被設置爲了always，但是其位於gcr.io上，導致下載失敗。
先手工修改，驗證是否可行。
- 查看pod中狀態爲“ImagePullBackOff”的。
- 然後找到對應的deployment或stateful set。
- 在k8s dashboard選擇“編輯”或者使用命令kubectl edit進行參數修改。
- 刪除對應的pod，系統會自動按照新的策略進行pod重建。
- 等待一段時間，相應pod的狀態恢復正常運行狀態。
⚠️注意：要修改deployment和stateful set裏面的參數。如果只修改pod和replica set/control set的參數，重建後會被覆蓋而失效。
回頭通過配置參數來進行修改，在部署時就可以完成。
3、補齊缺失的鏡像
經過上面處理後，發現還有兩個pod無法啓動：
- kfserving-controller-manager，鏡像爲：
- gcr.io/kfserving/kfserving-controller:v0.4.1
- profiles-deployment，鏡像爲：
- gcr.io/kubeflow-images-public/kfam:vmaster-g9f3bfd00
經查是之前的自動產生腳本遺漏了（在一個pod中有兩個鏡像，只提取了一個）。單獨下載，docker save爲tar文件，然後下載回來docker load到每一個節點上就可以了。
- 已經在aliyun的鏡像庫和腳本中補正：
- 直接使用《KubeFlow 1.2.0鏡像緩存（持續更新）》的方法和腳本就可以了。