Kubernetesチートシート

GitLabサポートチームがトラブルシューティング中に使用することのある、Kubernetesに関する便利な情報のリストです。GitLabでは、サポートチームが収集した知識を誰でも活用できるように、これを公開しています。

caution
これらのコマンドはKubernetesコンポーネントを変更したり壊したりする可能性があるので、自己責任で使用してください。

もしあなたが有料ティアにいて、これらのコマンドの使い方がわからない場合は、サポートに連絡するのがベストです。

一般的なKubernetesコマンド

  • GCPプロジェクトへの作成者認証方法（異なるGCPアカウントでプロジェクトがある場合に特に役立ちます）：

     gcloud auth login

  • Kubernetesダッシュボードへのアクセス方法：

     # for minikube:
 minikube dashboard —url
 # for non-local installations if access via Kubectl is configured:
 kubectl proxy

  • KubernetesノードにSSH接続してコンテナにrootで入る方法https://github.com/kubernetes/kubernetes/issues/30656 ：

    • GCPの場合は、ノード名を検索して、gcloud compute ssh node-name 。
    • docker ps を使用してコンテナを一覧表示します。
    • docker exec --user root -ti container-id bash を使ってコンテナを入力。

  • ローカルマシンからポッドにファイルをコピーする方法：

     kubectl cp file-name pod-name:./destination-path

  • CrashLoopBackoff 状態のポッドをどうするか：

    • Kubernetesダッシュボードでログを確認。

    • Kubectlでログを確認します：

       kubectl logs <webservice pod> -c dependencies

  • Kubernetesクラスタのすべてのイベントをリアルタイムで追跡する方法：

     kubectl get events -w --all-namespaces

  • 以前に終了したポッドインスタンスのログを取得する方法：

     kubectl logs <pod-name> --previous

    コンテナ/ポッド自体にはログは残りません。全てはstdout に書き込まれます。 これはKubernetesの原則で、詳細はTwelve-factor appをお読みください。

  • クラスターでcronジョブを設定する方法

     kubectl get cronjobs

    cronベースのバックアップを設定すると、ここに新しいスケジュールが表示されます。スケジュールに関する詳細はRunning Automated Tasks with a CronJobに記載されています。

GitLab固有のKubernetes情報

  • Kubernetes Helm Chartのテストに使用できる最小限の設定。

  • 別ポッドのログをテーリングします。webservice ポッドの例：

     kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice

  • ラベル (この場合はwebservice) を共有するすべてのポッドを追跡します：

     # all containers in the webservice pods
 kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50
   
 # only the webservice containers in all webservice pods
 kubectl logs -f -l app=webservice -c webservice --max-log-requests=50

  • Linux のパッケージインストールにおけるコマンドgitlab-ctl tail のように、すべてのコンテナからログを一度にストリームできます：

     kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100

  • gitlab 名前空間内のすべてのイベントをチェックします（デプロイ時に別の名前空間を指定した場合は、名前空間名が異なる可能性があります）：

     kubectl get events -w --namespace=gitlab

  • GitLabの便利なツール（コンソール、Rakeタスクなど）のほとんどはtoolboxポッドにあります。この中に入ってコマンドを実行することも、外から実行することもできます。

    note
    task-runner ポッドはGitLab 14.2（チャート5.2）でtoolbox に改名されました。
     # find the pod
 kubectl --namespace gitlab get pods -lapp=toolbox
   
 # enter it
 kubectl exec -it <toolbox-pod-name> -- bash
   
 # open rails console
 # rails console can be also called from other GitLab pods
 /srv/gitlab/bin/rails console
   
 # source-style commands should also work
 cd /srv/gitlab && bundle exec rake gitlab:check RAILS_ENV=production
   
 # run GitLab check. The output can be confusing and invalid because of the specific structure of GitLab installed via helm chart
 /usr/local/bin/gitlab-rake gitlab:check
   
 # open console without entering pod
 kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails console
   
 # check the status of DB migrations
 kubectl exec -it <toolbox-pod-name> -- /usr/local/bin/gitlab-rake db:migrate:status

    /usr/local/bin/gitlab-rake の代わりにgitlab-rake を使うこともできます。

  • インフラストラクチャーのトラブルシューティング> Kubernetesクラスターのインテグレーション：

    • kubectl get events -w --all-namespaces の出力を確認してください。
    • gitlab-managed-apps 名前空間内のポッドのログを確認します。
    • GitLab側ではSidekiqのログとKubernetesのログを確認します。GitLab が Helm chart 経由でインストールされている場合、kubernetes.log は Sidekiq pod 内にあります。

  • 初期管理者パスワードの取得方法https://docs.gitlab.com/charts/installation/deployment.html#initial-login ：

     # find the name of the secret containing the password
 kubectl get secrets | grep initial-root
 # decode it
 kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo

  • GitLabのPostgreSQLデータベースに接続する方法。

    note
    task-runner ポッドはGitLab 14.2（チャート5.2）でtoolbox に改名されました。

    GitLab 14.2 (chart 5.2)以降では：

     kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main

    GitLab 14.1（チャート5.1）以前の場合：

     kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password

  • Helmのインストール状況に関する情報を取得する方法：

     helm status name-of-installation

  • Helmチャートを使ってインストールされているGitLabを更新する方法：

     helm repo update
   
 # get current values and redirect them to yaml file (analogue of gitlab.rb values)
 helm get values <release name> > gitlab.yaml
   
 # run upgrade itself
 helm upgrade <release name> <chart path> -f gitlab.yaml

    Helmチャートを使ったGitLabのアップデートも参照してください。

  • GitLab 設定に変更を適用する方法：

    • gitlab.yaml ファイルを変更します。

    • 以下のコマンドを実行して変更を適用します：

       helm upgrade <release name> <chart path> -f gitlab.yaml

  • リリースのマニフェストを取得する方法。マニフェストには、すべてのKubernetesリソースと依存するChartに関する情報が含まれているので便利です：

     helm get manifest <release name>

MacOSでminikubeを使ったGitLab最小設定のインストール

このセクションはDeveloping for Kubernetes with minikubeandHelmに基づいています。詳細はこれらのドキュメントを参照してください。

  • Homebrew経由でKubectlをインストールします：

     brew install kubernetes-cli

  • Homebrew経由でminikubeをインストールします：

     brew cask install minikube

  • minikubeを起動して設定します。minikubeが起動できない場合は、minikube delete && minikube start ：

     minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
 minikube addons enable ingress

  • Homebrew経由でHelmをインストールし、初期化します：

     brew install helm

  • minikubeの最小値YAMLファイルをワークステーションにコピーします：

     curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"

  • minikube ip の出力から IP アドレスを見つけ、この IP アドレスで YAML ファイルを更新します。

  • GitLab Helmチャートをインストールします：

     helm repo add gitlab https://charts.gitlab.io
 helm install gitlab -f <path-to-yaml-file> gitlab/gitlab

    GitLabの設定をいくつか変更したい場合は、上記の設定をベースにして独自のYAMLファイルを作成することができます。

  • helm status gitlab とminikube dashboard を使ってインストールの進捗を監視しましょう。インストールには、ワークステーションのリソース量にもよりますが、20～30分ほどかかります。

  • すべてのポッドがRunning またはCompleted のステータスを示したら、初期ログインで説明したように GitLab のパスワードを取得して、UI から GitLab にログインします。https://gitlab.domain からアクセスできるようになります。domain は YAML ファイルで提供された値です。

toolbox ポッドの Rails コードにパッチを適用します。

caution
この作業は定期的に行うべきものではありません。自己責任で行ってください。

GitLabのサービスポッドにパッチを適用するには、変更したソースコードを含む新しいイメージをビルドする必要があります。これらは直接パッチを当てることは_できません_。toolbox /task-runner ポッド には、他の通常のサービスオペレーションを妨げることなく、Rails ベースのポッドとして動作するために必要なものがすべて入っています。独立したタスクを実行したり、いくつかのタスクを実行するために一時的にソースコードを変更したりするのに使うことができます。

note
toolbox ポッドを使って変更を加えた場合、ポッドを再起動してもその変更は永続化されません。コンテナのオペレーションが続く間だけ存在します。

toolbox ポッドのソースコードにパッチを適用するには：

  1. 適用したい.patch ファイルを取得します：

    • マージリクエストの差分をパッチファイルとして直接ダウンロードします。

    • または、curl を使って直接 diff を取得してください。以下の<mr_iid> をマージリクエストの IID に置き換えるか、URLを生のスニペットを指すように変更してください：

       curl --output ~/<mr_iid>.patch "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<mr_iid>.patch"

  2. toolbox ポッド上の内部ファイルにパッチを適用します：

    cd /srv/gitlab
busybox patch -p1 -f < ~/<mr_iid>.patch