部署参考：
预先准备
部署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镜像缓存（持续更新）》的方法和脚本就可以了。