Kubernetesチートシート

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

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

これらのコマンドは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

SSHでKubernetesノードに接続し、コンテナに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情報

個別のポッドのログの追跡。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ネームスペース内のすべてのイベントを確認します（Helm Chartのデプロイ時に別のネームスペースを指定した場合は、ネームスペース名が異なる場合があります）:
```
kubectl get events -w --namespace=gitlab
```

ほとんどの有用なGitLabツール（コンソール、Rakeタスクなど）は、ツールボックスポッドにあります。それに入力して内部でコマンドを実行するか、外部からコマンドを実行できます。

# find the pod
kubectl --namespace gitlab get pods -lapp=toolbox

# open the Rails console
kubectl --namespace gitlab exec -it -c toolbox <toolbox-pod-name> -- gitlab-rails console

# run GitLab check. The output can be confusing and invalid because of the specific structure of GitLab installed via helm chart
gitlab-rake gitlab:check

# open console without entering pod
kubectl exec -it <toolbox-pod-name> -- gitlab-rails console

# check the status of DB migrations
kubectl exec -it <toolbox-pod-name> -- gitlab-rake db:migrate:status

トラブルシューティングインフラストラクチャ > Kubernetesクラスターインテグレーション:
- kubectl get events -w --all-namespacesの出力を確認します。
- gitlab-managed-appsネームスペース内のポッドのログを確認します。

最初の管理者パスワードを取得する方法:

# 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データベースに接続する方法。

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

Helmインストールステータスに関する情報を取得する方法:
```
helm status <release name>
```

Helm Chartを使用してインストールされた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 Chartを使用してGitLabを更新するも参照してください。

GitLabの設定への変更を適用する方法:
- gitlab.yamlファイルを変更します。
- 次のコマンドを実行して、変更を適用します:
```
helm upgrade <release name> <chart path> -f gitlab.yaml
```
リリースのマニフェストを取得する方法。すべてのKubernetesリソースと依存するチャートに関する情報が含まれているため、役立ちます:
```
helm get manifest <release name>
```

KubeSOSレポートの高速統計

KubeSOSは、GitLab Cloud NativeチャートデプロイからGitLabクラスターの設定とGitLabログを収集するツールです。メモリ使用量が最小限のツールであるfast-statsを使用して、GitLabログのパフォーマンス統計を迅速に作成および比較できます。

fast-statsを実行します:

cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats

エラーを一覧表示します:

cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats errors

fast-stats topを実行します:

cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats top

印刷される行数を変更します。デフォルトでは、10行が出力されます。
```
cut -d  ' ' -f2- <file-name> | grep ^{ | fast-stats -l <number of rows>
```

macOSでのminikube経由での最小限のGitLab設定のインストール

このセクションは、minikubeを使用したKubernetesの開発とHelmに基づいています。詳細については、これらのドキュメントを参照してください。

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コードのパッチ適用

このタスクは、定期的に実行する必要があるものではありません。ご自身の責任で使用してください。

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

toolboxポッドを使用して変更を加えた場合、ポッドが再起動されると、それらの変更は保持されません。それらは、コンテナの操作のライフサイクルでのみ存在します。

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

適用する目的の.patchファイルフェッチします:
- マージリクエストの差分をパッチファイルとして直接ダウンロードします。
- または、curlを使用して差分を直接フェッチします。次の<mr_iid>をマージリクエストのIIDに置き換えるか、rawスニペットを指すようにURLを変更します:
```
curl --output ~/<mr_iid>.patch "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<mr_iid>.patch"
```
toolboxポッドのローカルファイルをパッチします:
```
cd /srv/gitlab
busybox patch -p1 -f < ~/<mr_iid>.patch
```