Kubernetesベースのコア機能導入プロセス


このドキュメントでは、KubernetesクラスタにNucleio機能を導入する手順について説明します.

1.クベルネディスクラスタ構造


nucleio機能を導入したクバーネディスクラスタの構造は、次のとおりです.

プロセス内のクラスタは、3つのプライマリノードと3つのワークノードで構成されます.1番マスターノードはポート転送機能を持っているため、32222番ポートで外部から接続できるが、残りのノードにアクセスできないため、仮想デスクトップ情報(VDI)で接続されている.VDIは、クボニスクラスタ内にインストールされているノードと同じエリアネットワークを提供する.さらに、ポート転送が有効なnucleio dashboardまたはnexus repositoryは外部からアクセスでき、cvat dashboardはingressで設定したURL規則に従ってVDIからcvatにアクセスする.example.com:30000.

2、核機能分布過程


nucleio関数の配置手順は正式な書類を参照し、順序に従って説明します.

1)Docker Registryの構築


nucleio機能を導入する最初のことは、画像を格納するディレクトリツリーを構築することです.nucleio関数は、function.yamlで定義されたメタデータに基づいて生成される画像である.デプロイ中にイメージがレジストリにプッシュされ、引き寄せられますが、この操作を実行するには、まずドッキングレジストリを作成する必要があります.
デフォルトでは、リポジトリを構築する方法は2つあります.
  • 登録イメージに基づいてローカル環境でDocker登録を構築する方法
  • Nexusが専用Docker登録をどのように構築するか
  • 最初は、最初の方法でディレクトリツリーを構築しましたが、モデルの導入中に次のエラーが発生しました.

    画像をローカルレジストリにプッシュするには、画像の名前をlocalhost:5000/<image>:<tag>に変更する必要があります.ローカル環境で核機能を導入する場合、核コンテナは同じドッキングネットワークに接続されているため、ローカルレジストリを識別できるため、最初の方法でレジストリを構築しても正常に導入できます.しかし、クバーネディス環境では、nucleo関数を配置して生成したpodが実際に特定のワークノードに割り当てられるため、すべてのワークノードがカーネルツリーを認識できるように環境を構築する必要があります.
    したがって、localhost:5000とマークされた画像では、同じワークノードにレジストリコンテナがないとレジストリが認識されないため、上記のエラーが発生します.(たとえば、レジストリコンテナが1番ワークノードで実行され、2番ワークノードにnucleio関数podが割り当てられている場合、localhostは2番ワークノードを指すため、1番ワークノードで実行されている複数のディレクトリツリーにアクセスできません.)
    ただし、nexusベースで構築されたレジストリは、そのレジストリを構築したノードのクラスタIPでアクセスできるため、コンテナのないノードでもレジストリにアクセスできる.

    2)認証情報の作成


    クバーネディグクラスタセットにprivatedocker registryが構築されている場合は、レジストリにアクセスするために必要な個人情報をsecretオブジェクトとして作成する必要があります.実際、nucleio function deploymentのspec.container.imagePullSecretsは、どの秘密オブジェクトに基づいてレジストリにアクセスするかを示す.

    したがって、registry-credentialという名前の秘密オブジェクトを作成する必要があります.secretオブジェクトを作成する手順は、次のとおりです.
    read -s mypassword
    <enter your password>
    
    kubectl create secret docker-registry registry-credential \
        --namespace nuclio \
        --docker-username <username> \
        --docker-password $mypassword \
        --docker-server <URL> \
        --docker-email [email protected]
    
    unset mypassword
    nexusレジストリのアカウント、パスワード、Eメールアドレス、レジストリのurlを入力します.urlはレジストリとして機能するコンテナのクラスタIPとポート番号からなる.ex) 172.30.45.153:5000
    すべてのオプションが入力されると、情報はbase-64として符号化され、秘密オブジェクトとして格納されます.なお、生成するには、本書のregistry-credentialsregistry-credentialに変更する必要があります.名前が一致しない場合は、デプロイ・オブジェクトで指定したsecretを参照できないため、次のno basic auth credentialsエラーが発生します.

    3)Nuclio helmパッケージのインストール


    helmグラフでnucleio dashboardとcontrollerをインストールします.
    まずnucleio helm chartをリポジトリに追加します.
    helm repo add nuclio https://nuclio.github.io/nuclio/charts
    前に入力したDocurrigeツリーのURLとsecretを各オプションに追加します.
    helm install nuclio \
    --set registry.pushPullUrl=<URL> nuclio/nuclio \
    --set registry.secretName=registry-credential -n nuclio
    kubernetesのnucleio namespaceで次の配置を作成した場合は、通常のインストールが完了しています.

    核インジケータボードを露出させるためのサービスオブジェクトを作成します.yamlファイルを作成し、kubectl applyコマンドを使用してリソースを作成するか、kubectl exposeコマンドを使用します.サービスタイプはNodePortとして指定されます.
  • kubectl exposeコマンドによるクラスタ外への展開
  • kubectl expose deployment -n nuclio nuclio-dashboard --type=NodePort --name=nuclio-nodeport
  • serviceobject作成
  • apiVersion: v1
    kind: Service
    metadata:
      labels:
        app.kubernetes.io/managed-by: Helm
      name: nuclio-nodeport
      namespace: nuclio
    spec:
      clusterIP: 10.99.69.2
      clusterIPs:
      - 10.99.69.2
      externalTrafficPolicy: Cluster
      ipFamilies:
      - IPv4
      ipFamilyPolicy: SingleStack
      ports:
      - nodePort: 32002
        port: 8070
        protocol: TCP
        targetPort: 8070
      selector:
        app: nuclio
        nuclio.io/app: dashboard
        nuclio.io/class: service
        nuclio.io/name: nuclio-dashboard
        release: nuclio
      sessionAffinity: None
      type: NodePort
    status:
      loadBalancer: {}

    4)Nuclio CLIに基づくプロジェクトの作成と機能配置


    これで、核機能を導入するためのすべての環境が構築されました.nucleio CLInuctlを使用して、機能を配布するアイテムを作成します.
    nuctl create project cvat -n nuclio
    nucleio関数を次のコマンドで配置します.git cloneでコピーしたcvatフォルダで作業しているとします.
    nuctl deploy --project-name cvat \
    --path `pwd`/serverless/tensorflow/faster_rcnn_inception_v2_coco/nuclio \
    --volume `pwd`/serverless/common:/opt/nuclio/common \
    --platform kube \
    --namespace nuclio \
    --kubeconfig /etc/kubernetes/admin.conf \
    --registry 172.16.156.21:5000 \
    --http-trigger-service-type NodePort
    各オプションの説明は次のとおりです.
    OptionDescriptionpathは、配備するnucleio関数のフォルダパスvolumenuclio関数コンテナ内のボリュームのマウントパスを定義します.platformnucleio関数を配備する環境(kube,ローカル)ネーミングスペース配備するnucleoプロジェクトのネーミングスペースkubeconfigkubernetesのkubeconfigファイル(admin.conf)registrydocker registryのURLttp-trigger-service-typenucleo関数のpodに適用されるサービスのタイプ.
    クラスタの外部からnucleio関数にアクセスできるようにするには、nucleio関数のtypeをNodePortに設定し、任意のポートに露出する必要があります.NodePortは、30000~32767の範囲で使用可能なポートを指定します.

    5)機能配置結果


    上記で作成したコマンドで機能が正常に配備されている場合、最終的にFunctionDeploy Completeメッセージが出力されます.
    nuctl get functions配置された核機能のリストをコマンドで表示できます.NODE PORTが指定されており、STATEが準備完了している場合は正常に配備されています.
    replicasetのデフォルト値は1です.このデプロイで作成したpodも表示できます.


    nucleio dashboardおよびcvatは、この関数の正常な動作を検証することもできます.


    3.エラー


    1.frame unit automatic labelingは正常に行われていますが、task単位で行うとエラーが発生します。

  • PostmanはRestAPIをBasic authに送信すると正常に応答するが、同じRestAPIがAuto Annotationボタンをクリックして送信されると500エラーが発生する.これは認証の問題です.


  • 2.Nuclio Dashboardでモデルを配備中にエラーが発生しました

  • NodePortオプションが指定されていない場合(クラスタIP)Dashboardも正常に配備できますが、NodePortに変更すると配備中にエラーが発生します
  • Nucleio CLI(nuctl)配備時、NodePortタイプも正常に配備可能
  • CaseClusterIPタイプ(Dashboard)ノードポートタイプ(Dashboard)モデル配置成功エラー自動タグエラー成功自動タグエラー(5枚の画像のみ)
    またnuctlでパブリッシュされた関数ログがnucleio dashboardでチェックされると、エラーメッセージが出力されますが、モデル自体は正常に動作します.