部署Kubeflow版本1.4至Kubernetes集群

2 年 ago
韵, 科
4 minutes

首先

2. 一开始

3. 首先

4. 开篇

5. 起初

我是日立制作株式会社研究开发组服务计算研究部的田中。Kubeflow的新版本1.4已于2021年10月12日发布。本文介绍了如何在云端或本地通用的Kubernetes集群上部署Kubeflow版本1.4的步骤。同时，还附带了部署上一个版本Kubeflow 1.3的步骤。值得注意的是，本文介绍的步骤参考了Kubeflow官方网站上的信息。

    • Installing Kubeflow

 

    Kubeflow Manifests – Installation

[2021年12月24日追加] 为了说明Kubeflow功能的运用示例，我们创建了一篇新的文章。

    Kubeflow 内部の MinIO サーバを使用して Kubeflow Pipelines と TensorBoard を連携させる

２．Kubeflow 是什么？

Kubeflow是一个在Kubernetes上提供机器学习运行和管理环境的开源软件，它具有将机器学习模型的创建、训练、验证、工作流建立以及模型服务等与MLOps相关的工作负载集成并执行的特点。

3. Kubeflow的部署步骤

3.1. 前提条件

前提条件是在本次流程中，Kubernetes集群已经预先部署好了以便部署Kubeflow。可以通过Master节点上的kubectl命令来操作Kubernetes集群。Kubeflow和Kubernetes的版本如下所示。

    • Kubeflow バージョン1.4.0（2021年10月12日時点の最新版）

 

    Kubernetes バージョン1.21（バージョン1.22以降ではKubeflowをデプロイできないため）

3.2. 可选条件

在执行机器学习时，由于预计会消耗大量存储空间，因此除了使用本地存储作为存储介质外，还将介绍使用 Kubernetes 外部的 NFS 服务器的步骤。

3.3. 确认部署步骤的操作

以下是使用本次流程进行操作确认的环境信息。

(1) 确定操作环境（1）

    • OS

Masterノード（1台）：Ubuntu 18.04 LTS
Workerノード（2台）：Ubuntu 18.04 LTS

Kubernetes バージョン1.21.4（kubeadmでクラスタを作成）
Kubeflow バージョン1.4.0
Dynamic Volume Provisioner：nfs-subdir-external-provisioner v4.0.2

Image01-01.png

确定运动环境

    • OS

Masterノード（1台）+Workerノード（1台）：Ubuntu 18.04 LTS

Kubernetes バージョン1.21.1（Kindでクラスタを作成）
Kubeflow バージョン1.4.0
Dynamic Volume Provisioner：local-path-provisioner v0.0.14

Image01-02.png

3.4. Kubeflow部署

部署Kubeflow到Kubernetes集群的步骤如下：

    • KubernetesクラスタへDynamic Volume Provisionerをデプロイする（3.4.1節）

ローカルストレージを利用する場合
NFSサーバを利用する場合（オプション）

KubernetesクラスタのデフォルトのStorageClassを設定する（3.4.2節）

ローカルストレージを利用する場合
NFSサーバを利用する場合（オプション）

KubeflowをKubernetesクラスタへデプロイする（3.4.3節）
Jupyter Notebook – Kubeflow Pipelines連携を設定する（3.4.4節）
ユーザごとのリソースQuotaを設定する（3.4.5節）

将Dynamic Volume Provisioner部署至Kubernetes集群3.4.1中。

作为Kubeflow部署的准备工作，我们将部署支持存储的动态卷提供程序到Kubernetes集群中。

如果使用本地存储（例如：运行确认环境（2）），

在使用本地存储时，将Local Path Provisioner作为Dynamic Volume Provisioner部署到Kubernetes集群中。

# Masterノード上で操作：
# Local Path Provisioner のデプロイ
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

（2）如若使用NFS服务器（选项）（例如：操作验证环境（1））。

首先，登录到组成Kubernetes集群的所有节点，并安装与节点操作系统相对应的NFS客户端软件包。例如，如果节点的操作系统是Ubuntu 18.04 LTS，则可以使用apt命令安装nfs-common软件包。

# Masterノード、Workerノード上で操作：
# nfs-commonパッケージのインストール（Ubuntu 18.04 LTS の場合）
sudo apt install –y nfs-common

接下来，我们将在Kubernetes集群中部署nfs-subdir-external-provisioner，它是用于将NFS作为Kubernetes存储的动态卷配置程序。
将helm命令安装到Master节点上，以便部署nfs-subdir-external-provisioner。

# Masterノード上で操作：
# helmコマンドのインストール
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

安装helm命令后，使用helm命令指定NFS服务器的主机名（或IP地址），来部署nfs-subdir-external-provisioner。

# Masterノード上で操作：
# リポジトリの追加
helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/

# nfs-subdir-external-provisioner のデプロイ
helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=＜NFSサーバのホスト名あるいはIPアドレス＞ --set nfs.path=/ --set storageClass.name=nfs

设置Kubernetes集群的默认StorageClass。

为了准备Kubeflow部署，我们将在3.4.1章节中部署的动态卷提供程序与Kubernetes集群的默认StorageClass对应起来。

（1）如果使用本地存储（例如：在操作环境（2）中进行验证），

将StorageClass（local-path）配置为Kubernetes集群的默认选项，以支持Dynamic Volume Provisioner（local-path-provisioner）。

# Masterノード上で操作：
# KubernetesクラスタのデフォルトのStorageClassとして’local-path’を設定
kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

# 標準のデフォルトのStorageClass（standard）を解除
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

(2) 使用NFS服务器（选项）（例如：操作确认环境(1)）

将Dynamic Volume Provisioner（nfs-subdir-external-provisioner）对应的StorageClass（nfs）设置为Kubernetes集群的默认选项。

# Masterノード上で操作：
# KubernetesクラスタのデフォルトのStorageClassとして’nfs’を設定
kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

# 標準のデフォルトのStorageClass（standard）を解除
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

3.4.3. Kubeflow的部署

将Kubeflow部署到Kubernetes集群上。

(1) 安装Kustomize命令

安装用于Kubeflow部署的Kustomize命令。

# Masterノード上で操作：
# Kustomizeコマンドのインストール
curl -Lo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.2.0/kustomize_3.2.0_linux_amd64 && chmod +x kustomize && sudo mv kustomize /usr/local/bin/

获取用于Kubeflow部署的Manifest文件。

从GitHub仓库中克隆Kubeflow的Manifest文件集合。然后使用部署版本v1.4的标签（v1.4.0）进行检出。

# Masterノード上で操作：
# Kubeflow Manifestファイル一式のクローン
git clone https://github.com/kubeflow/manifests.git
# クローン先へディレクトリを移動
cd manifests
# バージョン1.4.0でチェックアウト
git checkout v1.4.0

执行Kubeflow部署脚本

使用已检出的文件来运行Kubeflow的部署脚本。脚本将循环执行，但如果没有发生错误并且回到命令行提示符，则表示Kubeflow的部署成功。

# Masterノード上で操作：
# Kubeflowのデプロイ用スクリプトの実行
while ! kustomize build example | kubectl apply -f -; do echo "Retrying to apply resources"; sleep 10; done

(4) 确认Kubeflow正常运行。

成功部署后，请稍等片刻来确认Kubeflow的Pod的执行状态。如果所有Pod的状态都变为Running，则表示Kubeflow正常运行。请注意，根据Kubernetes环境的不同，即使正常运行，所有Pod变为Running可能需要几分钟到几十分钟的时间，请注意。

# Masterノード上で操作：
# クラスタ内の全てのPodsを表示
kubectl get pods --all-namespaces

(5) Kubeflow仪表盘的发布

完成确认正常操作后，执行端口转发设置命令，以通过Web浏览器访问Kubeflow仪表盘（CentralDashboard）。

# Masterノード上で操作：
# Masterノードのポート8080へのアクセスをKubeflowダッシュボード（istio-ingress ポート80）に転送
kubectl port-forward svc/istio-ingressgateway -n istio-system 8080:80 --address 0.0.0.0

在执行端口转发设置命令时，当从Web浏览器访问Kubernetes集群的Master节点的主机名或IP地址的8080端口时，可以访问Kubeflow的仪表板界面。

Image01-04.png

3.4.4. Jupyter Notebook与Kubeflow Pipelines的集成设置。

为了让Jupyter Notebook能够控制Kubeflow Pipelines，需要在同时部署的服务网格“Istio”中添加访问权限授权策略和网络过滤器配置，并进行创建和注册。下面是对Kubeflow的默认用户（user@example.com）在Jupyter Notebook中控制Kubeflow Pipelines的授权策略和网络过滤器配置的示例设置。需要注意的是，由于不存在为Kubeflow用户整体进行Istio授权策略和网络过滤器配置的机制，因此在Kubeflow运营时，如果要分配Jupyter Notebook对Kubeflow Pipelines的控制权限，需要针对每个用户单独进行Istio策略和网络过滤器配置。

# Masterノード上で操作：
# Istioに対するKubeflowユーザ（user@example.com）のポリシーとフィルタを設定
cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: bind-ml-pipeline-nb-kubeflow-user-example-com
 namespace: kubeflow
spec:
 selector:
   matchLabels:
     app: ml-pipeline
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/kubeflow-user-example-com/sa/default-editor"]
---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: add-header
  namespace: kubeflow-user-example-com
spec:
  configPatches:
  - applyTo: VIRTUAL_HOST
    match:
      context: SIDECAR_OUTBOUND
      routeConfiguration:
        vhost:
          name: ml-pipeline.kubeflow.svc.cluster.local:8888
          route:
            name: default
    patch:
      operation: MERGE
      value:
        request_headers_to_add:
        - append: true
          header:
            key: kubeflow-userid
            value: user@example.com
  workloadSelector:
    labels:
      istio.io/rev: default
EOF

设定每个用户的资源配额。

在Kubeflow中，您可以为每个用户设置CPU数量、内存大小、存储容量等机器资源分配的配额（上限）。您可以通过将与Kubeflow用户关联的配置文件注册到Kubernetes集群来实现配额的设置。
在这里，我们展示了为Kubeflow默认提供的用户（user@example.com）设置Kubernetes配置文件的配额示例。
请注意，由于不存在为Kubeflow用户设置全局配额的机制，因此如果需要为Kubeflow用户设置资源配额，您需要为每个用户创建和注册独立的Kubernetes配置文件。

# Masterノード上で操作：
# Kubeflowユーザ（user@example.com）のQuotaを設定
cat <<EOF | kubectl apply -f - -n kubeflow
apiVersion: kubeflow.org/v1beta1
kind: Profile
metadata:
  name: kubeflow-test-example-com
spec:
  owner:
    kind: User
    name: user@example.com
  resourceQuotaSpec:
   hard:
     cpu: "2"
     memory: 2Gi
     requests.nvidia.com/gpu: "1"
     persistentvolumeclaims: "1"
     requests.storage: "20Gi"
EOF

3.4.6. 添加额外配置到使用Kind创建的Kubernetes集群中。

如果在动作确认环境（2）的情况下，在使用Kind创建的Kubernetes集群上部署Kubeflow 1.4并执行Kubeflow Pipelines，需要进行额外的配置以将容器执行方式从默认设置的docker更改为其他方式（例如k8sapi、kubelet、pns）。下面提供的额外配置示例是将容器执行方式更改为pns（进程命名空间共享）。

# Masterノード上で操作：
# Kubeflow Pipelinesのコンテナ実行形式（containerRuntimerExecutor）を’pns’に設定
kubectl patch configmap workflow-controller-configmap -n kubeflow -p '{"data": {"containerRuntimeExecutor": "pns"}}'

如果要部署Kubeflow 1.3版本，请执行以下操作。

本次介绍了Kubeflow版本1.4的部署步骤，但通过在第3章的步骤中进行以下更改，可以部署Kubeflow版本1.3。

（1）在获取Kubeflow部署用Manifest文件时的更改。

在第3.4.3节(2)中，从GitHub代码库克隆并获取Kubeflow的全部Manifest文件后，将检出标签更改为v1.3.1。

# Masterノード上で操作：
# Kubeflow Manifestファイル一式のクローン
git clone https://github.com/kubeflow/manifests.git
# クローン先へディレクトリの移動
cd manifests
# バージョン1.3.1でチェックアウト
git checkout v1.3.1

(2) 执行故障回避补丁命令

在Kubeflow版本1.3中，在第3.4.3节(3)中执行Kubeflow部署脚本并成功部署后，仍然存在由于故障而无法启动的Pod。由于解决方法已在社区中公开发布，我们将执行补丁命令来避免故障并成功启动。

# Masterノード上で操作：
# dex の Deployment を修正
kubectl patch deployment dex -n auth -p '{"spec":{"template":{"spec":{"containers":[{"name":"dex","env":[{"name":"KUBERNETES_POD_NAMESPACE","value":"default"}]}]}}}}'

# mpi-operator の Deployment を修正
kubectl patch  deployment mpi-operator -n kubeflow -p '{"spec":{"template":{"spec":{"containers":[{"name":"mpi-operat

5. 结束时

这次我们介绍了在常规Kubernetes集群上部署Kubeflow版本1.4的步骤。Kubeflow具有各种功能，可以实现MLOps。未来，我们计划介绍Kubeflow功能的应用示例和技巧。

✖
广告
将在 10 秒后关闭
bannerAds