Google Distributed Cloud(GDC)エアギャップ Managed Harbor Service(MHS)を使用して、各プロジェクトに Harbor レジストリ インスタンスを作成します。Harbor レジストリ インスタンスは、クラウドネイティブ環境でコンテナ イメージを保存および管理するための中央リポジトリとして機能します。オープンソースの Docker ディストリビューションの機能を拡張します。次の制限が適用されます。
- プロジェクトごとに最大 1 つのインスタンスを作成できます。
- インスタンスは分離されており、データやコンピューティング リソースを共有しません。
始める前に
Harbor レジストリ インスタンスの作成を担当している場合は、IAM プロジェクト管理者に連絡して、Harbor インスタンス管理者(harbor-instance-admin)ロールをリクエストしてください。このロールにより、プロジェクトの名前空間内で Harbor インスタンス、バックアップ リポジトリ、バックアップ プラン、バックアップ、復元の取得、一覧表示、監視、作成、更新、パッチ適用、削除を行うことができます。このロールには、新しい Harbor インスタンスをプロビジョニングするために必要な権限が含まれています。
Harbor レジストリ インスタンスを作成する
GDC コンソールまたは gdcloud CLI で Harbor レジストリ インスタンスを作成します。
コンソール
GDC コンソールで、次の手順を行います。
- ナビゲーション メニューの [CI/CD] セクションで、[Harbor Container Registry] をクリックします。
- [インスタンスを作成] をクリックします。
- [インスタンス名] フィールドに、インスタンスの名前を入力します。
- 省略可: [プロジェクト] セクションで、この Harbor インスタンスのデフォルト プロジェクトを作成するには、[このインスタンスの作成時にデフォルト プロジェクトを作成する] をオンにして、次の操作を行います。
- [Project Name] 欄にプロジェクト名を入力します。
- Harbor マネージド サービス利用規約を読み、利用規約に同意する場合はチェックボックスをオンにします。
- [作成] をクリックします。[ステータス] には [進行中] と表示され、[名前] には、新しく作成された Harbor インスタンスの名前を含む外部リンクが表示されます。
- インスタンスが作成され、[ステータス] に [準備完了] と表示されたら、ページ上の外部リンクをクリックして Harbor インスタンスのウェブ UI にアクセスします。
gdcloud
Harbor レジストリ インスタンスを作成します。
gdcloud harbor instances create INSTANCE \
--project=PROJECT
次のように置き換えます。
INSTANCE: インスタンスの名前PROJECT: インスタンスを作成する GDC プロジェクトの名前
Harbor レジストリ インスタンスのクラスタノードの信頼
Harbor レジストリ インスタンスの準備が整うと、GDC は、組織の信頼できるルート認証局(CA)によって発行されたインスタンスの TLS 証明書を信頼するように、組織内の共有 Kubernetes クラスタと標準 Kubernetes クラスタのノードを自動的に構成します。インスタンスからイメージを pull するために、ルート CA をインストールしたり、クラスタノードのコンテナ ランタイム構成を変更したりする必要はありません。
自動構成の動作は次のとおりです。
- ノードの更新タイミング: GDC は、各クラスタの非公開レジストリ構成にインスタンスを追加し、クラスタ内のすべてのノードを更新します。ノードがインスタンスからイメージを pull できるのは、そのノードで更新が完了した後です。すべてのノードで更新が完了するまでに最大 60 分かかることがあります。
- 新しいクラスタとクロスゾーン クラスタ: GDC は、インスタンスの準備ができた後に作成するクラスタと、組織の他のゾーンのクラスタも構成します。
- 信頼できるホスト名: ノードは、インスタンスのホスト名のみを信頼します。これは、
https://接頭辞のないインスタンス URL(harbor-1-my-project.org-1.zone1.google.gdc.testなど)です。インスタンス URL は、GDC コンソールのインスタンス リンク、またはgdcloud harbor instances describeコマンド出力のstatus.urlフィールドで確認できます。イメージ参照でインスタンスのホスト名(INSTANCE_HOSTNAME/HARBOR_PROJECT/IMAGE:TAGなど)を使用します。ここで、HARBOR_PROJECTはイメージを保存する Harbor プロジェクトです。 - ワークステーションの Docker クライアント: 自動信頼はクラスタノードにのみ適用されます。ワークステーションから Docker を使用してイメージを push または pull するには、ルート CA を信頼するようにローカル Docker クライアントを構成する必要があります。詳細については、Harbor ルート CA を信頼するように Docker を構成するをご覧ください。
クラスタノードがインスタンスを信頼していない場合は、イメージの pull 時の証明書エラーのトラブルシューティングをご覧ください。
イメージの pull 時の証明書エラーのトラブルシューティング
クラスタノードがイメージ参照のホスト名の証明書を信頼していない場合、Pod はイメージを pull できません。Pod に ErrImagePull または ImagePullBackOff ステータスが表示され、Pod イベントに次のようなエラーが表示されます。
failed to pull and unpack image "INSTANCE_HOSTNAME/HARBOR_PROJECT/IMAGE:TAG": ... x509: certificate signed by unknown authority
証明書エラーのトラブルシューティングを行うには、次のものが必要です。
- インスタンスを含む GDC プロジェクトの Harbor インスタンス閲覧者(
harbor-instance-viewer)ロールまたは Harbor インスタンス管理者(harbor-instance-admin)ロール。 - 影響を受けるクラスタで Pod イベントを表示し、Pod を削除できるロール。
- 共有クラスタの場合、ワークロードのプロジェクト名前空間の名前空間管理者(
namespace-admin)ロール。 - 標準クラスタの場合、クラスタを含むプロジェクトのクラスタ デベロッパー(
cluster-developer)ロール。
- 共有クラスタの場合、ワークロードのプロジェクト名前空間の名前空間管理者(
- 影響を受ける Kubernetes クラスタの kubeconfig ファイル。
- 共有クラスタの場合は、ログインをご覧ください。
- 標準クラスタについては、標準クラスタへのアクセスを管理するをご覧ください。
この問題を解決するには、次の操作を行います。
Pod イベントと Pod を実行するノードを表示します。
kubectl --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE describe pod POD_NAME次のように置き換えます。
CLUSTER_KUBECONFIG: 影響を受ける Kubernetes クラスタの kubeconfig ファイルのパス。NAMESPACE: Pod の名前空間。共有クラスタの場合、これはプロジェクトの名前空間です。POD_NAME: Pod の名前。
出力の
Nodeフィールドには Pod を実行するノードが表示され、Eventsセクションにはエラー メッセージとイメージ参照が表示されます。インスタンスの準備ができており、エラーコードがないことを確認します。
- GDC コンソールで、インスタンスの [ステータス] に [準備完了] と表示されていることを確認します。[ステータス] に [準備完了] と表示されている場合でも、gdcloud CLI を使用してエラーコードを確認します。
gdcloud CLI を使用して、インスタンスのステータスとエラーコードを確認します。
gdcloud harbor instances describe INSTANCE \ --project=PROJECT次のように置き換えます。
INSTANCE: Harbor レジストリ インスタンスの名前。PROJECT: インスタンスが含まれている GDC プロジェクトの名前。
出力で、
status.conditionsリストのtype: Readyを含む条件にstatus: "True"が設定されていることを確認します。出力は次のようになります。# Several lines of code are omitted here. status: conditions: - message: HarborInstance reconciled reason: Reconciled status: "True" type: Ready # Several lines of code are omitted here. url: https://harbor-1-my-project.org-1.zone1.google.gdc.test
[ステータス] が [進行中] のままになっているか、[不明] または [エラー] と表示されている場合、または
Ready条件にstatus: "True"がない場合は、インフラストラクチャ オペレーター(IO)にお問い合わせください。gdcloud harbor instances describe出力のstatusセクションに、HAAS0008などのエラーコードを含むerrorStatusフィールドが含まれている場合は、Ready条件がTrueであっても、IO に連絡してください。エラーコードとメッセージを記載します。ワークロードのイメージ参照で、
https://接頭辞なしで、インスタンス URL に表示されているとおりにインスタンスのホスト名が使用されていることを確認します。ノードは、IP アドレスなど、インスタンスの他の名前を信頼しません。イメージ参照で別の名前を使用している場合は、インスタンスのホスト名を使用するように参照を更新してから、ワークロードを再デプロイします。インスタンスが準備完了ステータスになってから、またはクラスタを作成してから 60 分未満の場合は、GDC がクラスタノードの更新を完了するまで待ちます。
- 部分的なノードの更新: 一部のノードでイメージの pull が成功し、他のノードで失敗した場合、更新は進行中です。
- バックアップと復元: インスタンスのバックアップまたは復元が進行中の場合、ノードの更新は待機します。バックアップまたは復元が完了してから 60 分後に開始します。
- 新しいクラスタまたはクロスゾーン クラスタ: インスタンスの準備ができた後に作成するクラスタと、インスタンスとは異なるゾーンにあるクラスタの場合、インスタンスの準備完了ステータスには、クラスタノードが更新されているかどうかは表示されません。
ノードの更新が完了したら、ワークロードがイメージを pull できることを確認します。Kubernetes は、失敗したイメージの pull を自動的に再試行します。すぐに再試行するには、失敗した Pod を削除して、
Deploymentなどのコントローラが再作成するようにします。kubectl --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE delete pod POD_NAMEPod を管理するコントローラがない場合は、Pod を再作成します。問題が解決したことを確認するには、新しい Pod に
ErrImagePullまたはImagePullBackOffではなくRunningステータスが表示されていることを確認します。kubectl --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE get podsインスタンスが準備完了ステータスを示してから、またはクラスタを作成してから(どちらか遅い方)60 分以上エラーが続く場合は、IO にお問い合わせください。次の情報をお知らせください。
- インスタンスと影響を受けるクラスタの組織とゾーン
- インスタンス名と、インスタンスを含む GDC プロジェクト
- 影響を受ける Kubernetes クラスタの名前(共有クラスタか標準クラスタか)、標準クラスタの場合はクラスタを含むプロジェクト
- 完全なイメージ参照と Pod イベントからの完全なエラー メッセージ
- イメージの pull が失敗したノードの名前と、他のノードでイメージの pull が成功したかどうか
- インスタンスが準備完了ステータスを示した日時、クラスタを作成した日時、インスタンスのバックアップまたは復元が進行中かどうか
gdcloud harbor instances describe出力のstatusセクション(errorStatusエラーコードを含む)
次のステップ
Harbor レジストリ インスタンスの準備ができたら、イメージ コレクションをホストするプロジェクトを作成するか、既存のインスタンスを管理できます。