0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hana_shin(hana shin)

HarborにHelmチャートを登録し、Kubernetesから利用する

0
Last updated at Posted at 2026-07-30

1 はじめに

Helmは、Kubernetesアプリケーションのデプロイや管理を行うためのパッケージマネージャです。Helmチャートを利用することで、複数のKubernetesリソースをまとめて管理し、アプリケーションを効率よくデプロイできます。

HelmチャートはBitnamiなどの公開リポジトリから取得できますが、実際の運用では、組織内で利用するチャートをHarborなどのプライベートレジストリで一元管理するケースもあります。これにより、利用するチャートのバージョンを管理しやすくなるほか、インターネットへ接続できない環境でもチャートを利用できます。

本記事では、Bitnamiリポジトリから取得したnginxのHelmチャートをHarborへ登録し、そのチャートを利用してKubernetesクラスタへnginxをデプロイする手順を紹介します。

なお、本記事は、以下の記事で紹介している手順が完了していることを前提としています。

2 検証環境

2.1 ネットワーク構成

検証環境は、VMware Workstation Pro上に構築した3台の仮想マシンでKubernetesクラスタを構成しています。各仮想マシンはブリッジ接続により、PCと同じネットワーク（192.168.1.0/24）に接続されています。

一方、10.244.0.0/16 は、CalicoのCNIプラグインによってクラスタ内に作成されるPodネットワークです。各Podにはこのアドレス帯からIPアドレスが割り当てられ、異なるノード上のPod同士が相互に通信する際に使用されます。Calicoは各ノードに経路を設定することで、Pod間通信を透過的に実現しています。

+--- control ---+    +--- worker1 ---+   +--- worker2 ---+
|AlmaLinux 10.2 |    |AlmaLinux 10.2 |   |AlmaLinux 10.2 |
|               |    |               |   |               |
|      Pod      |    |      Pod      |   |      Pod      |
|       |       |    |       |       |   |       |       |
| 10.244.x.0/24 |    | 10.244.y.0/24 |   | 10.244.z.0/24 |
| ------------- |    | ------------- |   | ------------- |
|               |    |               |   |               |
+-------+-------+    +-------+-------+   +-------+-------+
        |.14                 |.15                |.16
        |                    |                   |
        |   192.168.1.0/24   |                   |
+--------------------------------------------------------+
|        VMware Workstation Pro（Bridged networking）    |
+--------------------------------------------------------+
                             |
                    +---------------+
                    |               |
                    |       PC      |
                    |               |
                    +---------------+

それぞれの役割は以下のとおりです。
1台をコントロールノード、2台をワーカーノードとして使用します。

ホスト名 名称 役割
control コントロールノード クラスタ（control、worker1、worker2）の状態を管理し、Pod をどのノードで実行するかを決定するノード
worker1 ワーカーノード Pod を実行するノード
worker2 ワーカーノード Pod を実行するノード

2.2 ソフトウェアのバージョン

各ノードのAlmaLinuxバージョンは以下のとおりです。

[root@control ~]# cat /etc/redhat-release
AlmaLinux release 10.2 (Lavender Lion)

各ノードのカーネルバージョンは以下のとおりです。

[root@control ~]# uname -r
6.12.0-211.7.3.el10_2.x86_64

Kubernetesのバージョンは以下のとおりです。

[root@control ~]# kubectl version
Client Version: v1.36.2
Kustomize Version: v5.8.1
Server Version: v1.36.2

2.3 ノードのリソース

各ノードには4GBのメモリを割り当てています。

[root@control ~]#  free -h
               total        used        free      shared  buff/cache   available
Mem:           3.6Gi       1.3Gi       1.0Gi       5.8Mi       1.5Gi       2.3Gi
Swap:             0B          0B          0B

各ノードは 4コアのCPU（4 vCPU） を搭載しています。

[root@control ~]# lscpu -xe
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
  0    0      0    0 0:0:0:0          yes
  1    0      1    1 1:1:1:1          yes
  2    0      2    2 2:2:2:2          yes
  3    0      3    3 3:3:3:3          yes

lscpuコマンドの詳しい使い方は、以下のページをご覧ください。

3 事前準備

3.1 Harbor接続のための事前準備（CA証明書の登録）

Helmクライアントは Harbor に HTTPS で接続し、チャートの登録や取得を行います。その際、Helmクライアントは Harbor から送られてくるサーバ証明書を、CA証明書に含まれる公開鍵を用いて検証します。この検証に失敗すると、TLS証明書の検証エラー（x509エラー）が発生し、Harborへ接続できません。

本記事の検証環境では、Harbor のサーバ証明書は自己署名したCA証明書によって署名されています。そのため、Helmクライアントがサーバ証明書を正しく検証できるよう、事前にそのCA証明書をシステム（今回の場合、コントロールノード）へ登録する必要があります。

コントロールノードには、HarborをHTTPS化した際に作成したCA証明書がすでに配置されています。まずは、そのCA証明書の保存場所を確認します。

[root@control ~]# find . -name ca.crt
./harbor-certs/ca.crt

CA証明書の作成方法は、以下の記事で説明していますので参考にしてください。

HarborのCA証明書を、システムが信頼するCA証明書を配置するディレクトリにコピーします。

[root@control ~]# cp ./harbor-certs/ca.crt /etc/pki/ca-trust/source/anchors/

証明書が正しく配置されたことを確認します。

[root@control ~]# ls -l /etc/pki/ca-trust/source/anchors/
合計 4
-rw-r--r--. 1 root root 2033  7月 27 09:36 ca.crt

追加したCA証明書をHelmクライアントが利用できるようにするため、update-ca-trust を実行します。このコマンドは、システム標準のCA証明書と /etc/pki/ca-trust/source/anchors/ に配置したCA証明書を入力として受け取り、アプリケーションが利用する信頼ストアを /etc/pki/ca-trust/extracted/pem/ 配下に生成します。HelmやcurlなどのHTTPS通信を行うアプリケーションは、この信頼ストアを参照してサーバ証明書を検証します。

[root@control ~]# update-ca-trust
[root@control ~]#

tls-ca-bundle.pem は、システム標準のCA証明書と追加したCA証明書をまとめたCA証明書バンドルです。HelmやcurlなどのHTTPS通信を行うアプリケーションは、このCA証明書バンドルを参照してサーバ証明書を検証します。

[root@control ~]# ls -l /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
-r--r--r--. 1 root root 225804  7月 30 13:51 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

ちなみに、CA証明書バンドルには147枚のCA証明書が連結されています。BEGIN CERTIFICATE の数を数えることで、含まれているCA証明書の枚数を確認できます。

[root@control anchors]# grep "BEGIN CERTIFICATE" /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem |less
[root@control anchors]# grep "BEGIN CERTIFICATE" /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem |wc -l
147

3.2 外部リポジトリからチャートのダウンロード

nginxのチャートが格納されているリポジトリをbitnamiという名前で登録します。

[root@control ~]# helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories

登録したリポジトリの一覧を確認します。bitnami という名前のリポジトリが登録されていることが分かります。

[root@control ~]# helm repo list
NAME            URL
metallb         https://metallb.github.io/metallb
ingress-nginx   https://kubernetes.github.io/ingress-nginx
harbor          https://helm.goharbor.io
bitnami         https://charts.bitnami.com/bitnami

ローカルにキャッシュされているチャート情報を最新の状態に更新します。この操作を行わないと、最新のチャート情報がローカルに反映されず、最新バージョンの検索や取得ができない場合があるため、事前に実行します。

[root@control ~]# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "metallb" chart repository
...Successfully got an update from the "harbor" chart repository
...Successfully got an update from the "ingress-nginx" chart repository
...Successfully got an update from the "bitnami" chart repository
Update Complete. ?Happy Helming!?

bitnamiリポジトリで公開されている nginx チャートのバージョン一覧を確認します。

[root@control ~]# helm search repo bitnami/nginx --versions
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION
bitnami/nginx                           25.0.15         1.31.3          NGINX Open Source is a web server that can be a...
bitnami/nginx                           25.0.14         1.31.3          NGINX Open Source is a web server that can be a...
bitnami/nginx                           25.0.13         1.31.2          NGINX Open Source is a web server that can be a...
-snip-

bitnamiリポジトリから、バージョン 25.0.15 のnginxチャートをカレントディレクトリにダウンロードします。

[root@control ~]# helm pull bitnami/nginx --version 25.0.15

ダウンロードしたチャートを確認します。

[root@control ~]# ls -l nginx-25.0.15.tgz
-rw-r--r--. 1 root root 62091  7月 27 08:56 nginx-25.0.15.tgz

4 Harborへのチャート登録

HarborのOCIレジストリに対してhelmクライアントから認証を行い、ログインします。

[root@control ~]# helm registry login harbor.home.lab
Username: admin
Password:
Login Succeeded

ダウンロードしたチャートを、Harborの library プロジェクト内のOCIリポジトリへ push します。

[root@control ~]# helm push nginx-25.0.15.tgz oci://harbor.home.lab/library
Pushed: harbor.home.lab/library/nginx:25.0.15
Digest: sha256:d2156f93e0e6e9b3d2f4975117aef39b1a874f26192ed391dc8c0aefac1437ec

HarborのWeb画面を確認すると、pushしたチャートが登録されていることが確認できます。
aa-01.jpg

詳細を確認すると以下のようになります。
aa-02.jpg

5 Harborに登録したチャートのインストール

Harborに登録したチャートをHelmでインストールします。STATUS が deployed となっていることから、Helmリリースが正常に作成されたことが分かります。

[root@control ~]# helm install my-nginx oci://harbor.home.lab/library/nginx --version 25.0.15
Pulled: harbor.home.lab/library/nginx:25.0.15
Digest: sha256:d2156f93e0e6e9b3d2f4975117aef39b1a874f26192ed391dc8c0aefac1437ec
NAME: my-nginx
LAST DEPLOYED: Mon Jul 27 11:42:59 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
CHART NAME: nginx
CHART VERSION: 25.0.15
APP VERSION: 1.31.3

? WARNING: Since August 28th, 2025, only a limited subset of images/charts are available for free.
    Subscribe to Bitnami Secure Images to receive continued support and security updates.
    More info at https://bitnami.com and https://github.com/bitnami/containers/issues/83267

** Please be patient while the chart is being deployed **
NGINX can be accessed through the following DNS name from within your cluster:

    my-nginx.default.svc.cluster.local (port 80)

To access NGINX from outside the cluster, follow the steps below:

1. Get the NGINX URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w my-nginx'

    export SERVICE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].port}" services my-nginx)
    export SERVICE_IP=$(kubectl get svc --namespace default my-nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    echo "http://${SERVICE_IP}:${SERVICE_PORT}"
WARNING: Rolling tag detected (bitnami/nginx:latest), please note that it is strongly recommended to avoid using rolling tags in a production environment.
+info https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/apps-tutorials-understand-rolling-tags-containers-index.html
WARNING: Rolling tag detected (bitnami/git:latest), please note that it is strongly recommended to avoid using rolling tags in a production environment.
+info https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/apps-tutorials-understand-rolling-tags-containers-index.html
WARNING: Rolling tag detected (bitnami/nginx-exporter:latest), please note that it is strongly recommended to avoid using rolling tags in a production environment.
+info https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-doc/apps-tutorials-understand-rolling-tags-containers-index.html

WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. For production installations, please set the following values according to your workload needs:
  - cloneStaticSiteFromGit.gitSync.resources
  - resources
+info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
[root@control ~]# ls

Helmでインストールしたリリースの一覧を確認します。my-nginx のSTATUSが deployed になっていることから、リリースが正常にデプロイされたことが分かります。

[root@control ~]# helm list
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
my-nginx        default         1               2026-07-27 11:42:59.189915516 +0900 JST deployed        nginx-25.0.15   1.31.3

Podの状態を確認します。STATUSが Running、READYが 1/1 であることから、nginxのPodが正常に起動していることが分かります。

[root@control ~]# kubectl get pods
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-9cfd89585-tzlzr   1/1     Running   0          101s

Serviceの割り当て状況を確認します。TYPEが LoadBalancer、EXTERNAL-IP に 192.168.116.201 が割り当てられていることから、MetalLB によって LoadBalancer型Service に外部公開用のIPアドレスが割り当てられ、クラスタ外部から nginx にアクセスできる状態になっていることが分かります。

[root@control ~]# kubectl get svc my-nginx
NAME       TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
my-nginx   LoadBalancer   10.104.112.245   192.168.116.201   80:31346/TCP,443:30172/TCP   114s

6 あと始末

検証用にデプロイした nginx のリリースをアンインストールします。

[root@control ~]# helm uninstall my-nginx
release "my-nginx" uninstalled

Helmのリリース一覧を確認します。リリースが表示されていないことから、my-nginx のリリースが削除されたことが分かります。

[root@control ~]# helm list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION

Podの存在確認を行います。nginxのPodが削除されていることが確認できます。

[root@control ~]# kubectl get pods
No resources found in default namespace.

Serviceの割り当て状況を確認します。Serviceも正常に削除されていることが分かります。

[root@control ~]# kubectl get svc my-nginx
Error from server (NotFound): services "my-nginx" not found
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?