4.1 Kubeflow 的安装与部署
4.1.1 Kubeflow 的部署工具Kfctl
Kfctl 是Kubeflow 的部署工具，使用它可以部署Kubeflow 的应用到现有的Kubernetes集群中或指定的公有云平台上。Kfctl 的前身是kfctl.sh 脚本，在低于Kubeflow 0.5 的版本中，使用kfctl.sh 脚本部署Kubeflow。目前，Kfctl 已经发展成基于Go 语言编写的可执行文件。在后续的发展规划中，Kfctl 不仅是Kubeflow 的部署工具，还会成为Kubeflow的管理工具。
Kfctl 常用的子命令有以下几种。
· build：用于生成Kubeflow 各个组件的定义配置，一般为YAML 格式的文件。需要注意的是，在低于Kubeflow 0.6.2 的版本中，这个子命令为generate。
· apply：按照生成的YAML 配置文件在Kubernetes 集群中部署Kubeflow，在默认情况下，会创建名为Kubeflow 的Namespace，所有的部署（除了Cluster 级别的资源）会都部署到名为Kubeflow 的Namespace 中。
· delete：删除Kubeflow 的所有应用，同时删除名为Kubeflow 的Namespace 及创建的所有资源。
· set-image-name：设置用户自己定制的镜像。例如，用户为某些Kubeflow Component构建的自己的Docker 镜像可以使用set-image-name 更换镜像，当用户无法访问GCR 镜像仓库时也可以使用set-image-name 更换镜像。
· init <[path/]name>：此子命令在Kubeflow 0.7 中被移除了。在低于Kubeflow 0.6.2的版本中，此子命令用于在指定目录下创建Kubeflow 的应用配置文件，path 可以是绝对路径或当前目录下的一个子目录。
4.1.2 Kubeflow Manifests 与kustomize
Kubeflow Manifests 是Kubeflow 组件的配置仓库，Kfctl 会使用Kubeflow Manifests中的配置文件安装Kubeflow 组件。Kubeflow 组件是使用kustomize 工具的格式定义的，因此可以使用Kfctl 安装，也可以使用kustomize 安装。
kustomize 是sig-cli 的一个子项目，它的设计目的是给Kubernetes 的用户提供可以重复使用同一套配置的声明式应用管理，从而使用户在配置工作中只需管理和维护Kubernetes 的API 对象。Kustomize 在Kubernetes 1.14 及更高版本中成为kubectl 的一部分。
kustomize 采用Base+Overlay 的方式对应用的原始YAML 文件进行派生。kustomize的Overlay 可以在Base 的基础上，通过对Resource、Generator、Transformer 等进行定义，形成新的应用定义，Base 和Overlay 都可以使用kustomize build 命令生成有效的YAML 文件。
如果用户需要为不同的场景搭建不同的环境，那么至少需要搭建开发环境、测试环境和正式的生产环境。对一个应用来说，这3 个环境有很多相同之处，用户可以将相同的地方定义到Base 文件夹中，将不同的地方定义到Overlay 文件夹中。相同的地方，如Docker 镜像，如果发生变化，那么其他环境也需要跟着变化，如果将其定义到Base 文件夹中，那么只需变动一处，从而减少工作量，降低出错的概率。
在每个组件中，都需要有一个kustomization.yaml 文件，可以在含有kustomization.yaml文件的目录下运行kustomize build 命令。下面我们通过实例进行讲解。kustomize 的文件组织结构如下所示，包含开发、测试、生产环境。
Base 和Overlay 文件夹中都必须包含一个kustomization.yaml 文件。Base 文件夹中的kustomization.yaml 文件如下：
dev、qa、production 文件夹中的文件都可以定义一些自有的、独特的内容。例如，在dev 文件夹中的kustomization.yaml 文件在定义时可以在名字前加“dev-”，如下所示。
kustomize 的功能简单清晰，安装也很简单，只需下载二进制文件到自己的系统中，此处不再赘述。在Kubeflow Manifests 中，kustomize 文件的定义大致如下所示。为了便于理解，这里只列举了两个组件。
4.1.3 Kubeflow 与Kubernetes 版本的兼容性
Kubeflow 可以安装到任何基于Kubernetes 部署的平台上，包括混合云平台和公有云平台。本节以原生Kubernetes 为例，讲解Kubeflow 的安装步骤，Kubeflow 在其他平台上的安装步骤与此类似。
在安装Kubeflow 之前，首先确保Kubernetes 已经部署成功，并且能正常运行。注意Kubeflow 与Kubernetes 的版本兼容性，Kubeflow 0.4 要求Kubernetes 的版本不得低于1.11，而Kubeflow 0.6 及更高的版本要求Kubernetes 版本不低于1.14。Kubeflow 与Kubernetes 的版本兼容情况如表4-1 所示。
表4-1 Kubeflow 与Kubernetes 的版本兼容情况
4.1.4 Kubeflow 的安装过程
在准备好Kubernetes 之后，就可以安装Kubeflow 了，具体安装步骤如下。
（1）从GitHub 的kubeflow/kubeflow 仓库下载最新版本的Kubeflow 安装工具Kfctl。
（2）在下载完成后，解压安装包，命令如下：
（3）安装Kubeflow，安装过程比较简单。
首先将Kfctl 所在的目录添加到PATH 中（或者直接将Kfctl 复制到/usr/local/bin 目录下，并且赋予其执行权限），以便在任何目录下，都可以运行安装Kubeflow，并且创建安装过程中应用的安装目录。
关联配置文件，如果有不需要安装的组件，就可以直接在配置文件中注释掉相关的Section。例如，Istio 在有些环境中已经安装了，无须重复安装，只需在配置文件中注释掉Istio 组件。
可以先将此配置文件下载到本地，然后根据用户的需求，在编辑后使用。如果要将此配置文件下载到本地，那么需要将下面的环境变量的路径修改为本地路径。
如果没有激活Kubernetes 集群动态存储，则需要创建4 个PV（Persistent Volume），一些Kubeflow 组件需要使用PV 存储数据（如MinIO、MySQL、Katib 等）。我们需要提前为PVC（Persistent Volume Claim）创建PV。PV 的定义文件（假设存储为pv.yaml 文件）如下（此处采用NFS 模式，需要一个NFS Server，并且使集群中的所有界面都可以访问）。
在PV 的定义文件中，NFS_SERVER_IP 是NFS Server 的IP。为了方便起见，可以将管理节点设置成NFS Server，使Kubernetes 集群中的所有节点都可以访问管理节点。NFS_SHARED_DIR 可以是由Kubernetes 集群中的其他节点挂载的NFS 共享路径。需要注意的是，用户需要确保上述定义的子文件夹（pv1、pv2、pv3、pv4）存在，并且具有读/写权限。
运行以下命令创建PV。
正式安装，创建Kubeflow Namespace 和各种资源。在安装过程中，如果出现错误，那么这些错误一般是配置文件不匹配、网络问题或环境问题导致的。在解决问题之后，可以再次运行以下命令进行安装。
4.1.5 安装后检查
检查Kubeflow 是否安装成功。一般在几分钟后，Kubeflow 的各种Resource 就会创建成功，特别是各个组件的Pod 都会进入Running 状态，运行以下命令检查Kubeflow 是否正常启动，如果有Pod 没有进入Running 状态，那么可以查看Pod 的日志并具体分析问题。需要注意的是，某些Pod 没有进入Running 状态，是因为Kubeflow 需要PV/PVC，在安装过程中，已经创建了PVC，如果用户没有激活动态存储，则需要手动创建PV；如果用户安装了所有组件，则需要手动创建多个PVC。如果Kubernetes 集群中有多个节点，笔者建议使用NFS 的PV，从而使所有节点都可以访问指定的存储设备。
在安装完成之后，打开Kubeflow 用户界面，在低于Kubeflow 0.6 的版本中，通过Ambassador 访问Kubeflow Dashboard；在Kubeflow 0.6 及更高版本中，通过Istio 访问Kubeflow Dashboard，具体方法如下所示。
Kubeflow 的卸载方法非常简单，运行以下命令即可将Kubeflow Namespace 中的资源全部删除。
