• minikubeを始める
  • kubectlのインストール
  • minikubeのインストール
  • VMドライバの選択
  • minikubeの起動/停止
• minikubeの使用
  • ガッチャ：永続ボリューム
  • アドオンの有効化
  • ダッシュボードへの接続
• チャートのデプロイ
  • GitLab チャートリポジトリをクローンします。
  • GitLabのデプロイと推奨設定
  • 最小限の設定で GitLab をデプロイします。
  • DNSの処理
  • 自己署名 CA の組み込み
  • ログイン

minikubeを使ったKubernetesの開発者

このガイドは、ローカルのKubernetes開発環境をセットアップするためのクロスプラフォームリソースとしての役割を果たすことを意図しています。このガイドでは、標準として受け入れられているminikubeを使用します。

minikubeを始める

Kubernetesプロジェクトの公式ドキュメント「Running Kubernetes Locally with minikube」を抜粋して解説します。

kubectlのインストール

公式ドキュメントにはいくつかのオプションが記載されていますが、結果としては以下の3つのうちの1つを行うことになります：

• Google Cloud PlatformのCloud SDKページからGoogle Cloud SDKの一部としてダウンロードします。gcloud をインストールしたら、kubectl ：

   sudo gcloud components install kubectl
  

  この方法ですでにkubectl をインストールしている場合は、更新されていることを確認してください：

   sudo gcloud components update
  

• cURLまたは各OSの適切なパッケージ管理システムを使ってインストールしてください：

  • Linux
  • MacOS
  • Windows

minikubeのインストール

Kubernetesのドキュメントでは、GitHub上のリリースから直接インストールすることを推奨しています。

VMドライバの選択

このガイドでは、クロスプラットフォームの互換性のために、VirtualBoxにこだわりますが、VMware Fusion、HyperV、KVM、Xhyve用のドライバがあります。

minikubeの起動/停止

GitLabチャートの開発には、minikubeリソースリクエストをデフォルトより高く設定する必要があります。主要な設定項目は、minikube start --help 。以下に、テスト対象や要件に応じて変更したい項目を抜粋します：

• --cpus int:minikube VMに割り当てるCPU数（デフォルト2 ）。最低限必要なCPUは3 。_完全な_Chartをデプロイするには、4 が必要です。
• --memory int:minikube VMに割り当てられるRAMの量（デフォルト2048 ）。絶対的な最小値は6144 (6 GB)。推奨は10240 (10 GB)。

• --disk-size string:minikube VMに割り当てられるディスクサイズ (フォーマット:<number>[<unit>], unit =b,k,m org) (デフォルト20g)。GitLabのストレージと データベースの要件を参照してください。

  ホームディレクトリの~/.minikube/machines/minikube/ に作成されます。
• --kubernetes-version string:minikube VMが使用するKubernetesのバージョン（例：v1.2.3 ）。
• --registry-mirror stringSlice:Dockerデーモンに渡すレジストリミラー。

全てのツールのインストールと設定が完了したら、minikubeの起動と停止を行います：

minikube start --cpus 4 --memory 10240

このコマンドは、以下のような出力をするはずです：

Starting local Kubernetes v1.7.0 cluster...
Starting VM...
Downloading Minikube ISO
 97.80 MB / 97.80 MB [==============================================] 100.00% 0s
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Starting cluster components...
Connecting to cluster...
Setting up kubeconfig...
Kubectl is now configured to use the cluster.
[helm.gitlab.io]$ minikube ip
192.168.99.100
[helm.gitlab.io]$ minikube stop
Stopping local Kubernetes cluster...
Machine stopped.

minikube ip コマンドを実行した結果に注意してください。出力が192.168.99.100 でない場合、出力IPが後で必要になります。

minikubeの使用

minikubeは、Kubernetesインストールとして直接使用でき、シングルノードクラスターとして扱われます。Google Container Engine(GKE) のような本格的なKubernetesクラスターとminikubeでは若干異なる動作があります。

異なります：

• Persistent Volumes:hostPath のみ。

利用できません：

• ロードバランサー（クラウドプロバイダーが必要です。）
• 高度なスケジューリング・ポリシー（複数のノードが必要です。）

ガッチャ：永続ボリューム

minikubeは、hostPath 、VM内部のディレクトリにマッピングされるタイプのPersistentVolumesをサポートしています。minikubeはtmpfs 、ほとんどのディレクトリはminikube stop 。

永続するディレクトリの詳細と一覧は、minikubeのスタートガイドに記載されています。

アドオンの有効化

minikubeは、基本設定とは別にいくつかの機能を扱います。このプロジェクトの開発には、Ingress にアクセスする必要があります：

minikube addons enable ingress

ダッシュボードへの接続

ダッシュボードのURLは、電話で確認できます：

minikube dashboard --url

チャートのデプロイ

このチャートをminikubeにデプロイする場合、一部のチャートリソースを削減または無効にする必要があります。nginx-ingress チャートを使用してポート22,80,443 を提供することはできません。無効にし、nginx-ingress.enabled=false,global.ingress.class="nginx" を設定してIngressクラスを設定するのがベストです。

certmanager のChartはminikubeでは使用できません。certmanager.install=false,global.ingress.configureCertmanager=false を設定して無効にする必要があります。その結果、独自のSSL証明書を提供しない場合、自己署名証明書が生成されます。gitlab-runner Chartは、gitlab-runner.certsSecretNameを介して自己署名証明書を受け入れます。リリース名をgitlabとすると、証明書名はgitlab-wildcard-tls-chainとなります。

gitlab-shell Chartはminikubeでも使用できますが、minikubeで既に使用されている22以外のポートにマッピングする必要があります。gitlab.gitlab-shell.service.type=NodePort とgitlab.gitlab-shell.service.nodePort=<high-numbered port> を設定すると、指定したポート経由でリポジトリのクローンを作成できます。UIのクローンリンクにこのポートが反映されるようにするには、global.shell.port=<high-numbered port>を設定します。

以下のセクションでは、ローカルの Git クローンからこれらのチャートをインストールする方法を示します。目的のブランチやタグをチェックアウトし、そのチェックアウトのベースフォルダーにいることを確認してください。

GitLab チャートリポジトリをクローンします。

git clone https://gitlab.com/gitlab-org/charts/gitlab.git
cd gitlab

GitLabのデプロイと推奨設定

推奨の4CPU、10GBのRAMを使用する場合は、values-minikube.yaml 。

helm dependency update
helm upgrade --install gitlab . \
  --timeout 600s \
  -f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube.yaml

最小限の設定で GitLab をデプロイします。

3CPUと6GBのRAMという_絶対的に最小の_リソースを使う場合、すべてのレプリカを減らし、不要なサービスを無効にする必要があります。妥当なベースとしてvalues-minikube-minimum.yaml を参照してください。

helm dependency update
helm upgrade --install gitlab . \
  --timeout 600s \
  -f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml

minikube ip の出力が192.168.99.100 でなかった場合は、これらの引数を追加して、例の設定ファイルのIPエンドポイントを上書きします：

  --set global.hosts.domain=$(minikube ip).nip.io \
  --set global.hosts.externalIP=$(minikube ip)

DNSの処理

提供されている設定例では、ホストファイルやその他のドメイン名解決サービスの変更処理のオーバーヘッドを減らすために、ドメインを192.168.99.100.nip.io として設定しています。しかし、これはnip.ioのネットワーク到達性に依存しています。

これが利用できない場合は、/etc/hosts ファイルを変更するか、別の DNS 解決手段を提供する必要があるかもしれません。

/etc/hosts ファイルの追加例：

192.168.99.100 gitlab.some.domain registry.some.domain minio.some.domain

自己署名 CA の組み込み

Chartがデプロイされると、自己署名証明書を使用している場合、ユーザーには生成されたCA証明書を取得する方法が通知されます。この証明書をシステム・ストアに追加することで、すべてのブラウザ、Dockerデーモン、git コマンドがデプロイされた証明書を信頼できるものとして認識できるようになります。方法はオペレーションシステムによって異なります。

BounCAには、ほとんどのオペレーティングシステムをカバーする良いチュートリアルがあります。

ログイン

指定されたドメインにアクセスすることで、GitLabインスタンスにアクセスすることができます。これらのインスタンスでは、https://gitlab.192.168.99.100.nip.io 。rootの初期パスワードのシークレットを手動で作成した場合は、それを使ってrootユーザーとしてサインインできます。そうでない場合、GitLabは自動的にrootユーザー用のランダムなパスワードを作成します。これは次のコマンドで抽出できます（<name> をリリース名で置き換えます - 上のコマンドを使った場合はgitlab となります）。

kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo