Kubernetes

HelmはKubernetes向けのパッケージマネージャーで、複雑なアプリケーションのデプロイを簡単にしてくれるツールです。 Helmコマンドをよく忘れてしまうので、基本的なコマンドを備忘録としてまとめました。 インストール方法 macOSの場合は以下のコマンドでインストールできます。 brew install helm リポジトリ管理 リポジトリの追加 # リポジトリを追加する helm repo add stable https://charts.helm.sh/stable helm repo add bitnami https://charts.bitnami.com/bitnami リポジトリの一覧表示 # 追加されているリポジトリを確認する helm repo list リポジトリの更新 # リポジトリのインデックスを更新する（新しいチャートバージョンを取得） helm repo update チャートの検索・確認 チャートの検索 # リポジトリからチャートを検索する helm search repo nginx helm search repo mysql チャート情報の表示 # チャートの詳細情報を表示する helm show chart bitnami/nginx helm show values bitnami/nginx リリース管理 インストール # チャートをインストールする helm install my-nginx bitnami/nginx # 名前空間を指定してインストール helm install my-nginx bitnami/nginx -n production --create-namespace # カスタム値でインストール helm install my-nginx bitnami/nginx --set service....

kubectl get allだとCustom Resourceが表示されないので、全てのリソースが表示できずに困りました。kubectl api-resourcesを使えば、Custom Resourceも含めてサポートされているAPIリソースを全て把握できるので、それを応用して全てのリソースを表示できるようになりました。 備忘録として雑に書いておきます。 全てのリソースを表示する 以下のコマンドで、特定のnamespaceに存在する、全てのリソース(Custom Resourceも含めて)を表示することができます。 kubectl get $(kubectl api-resources --verbs=list --namespaced -o name | grep -v "events" | tr '\n' ',' | sed 's/,$//') -n openebs 各コマンドの説明 kubectl api-resources --verbs=list --namespaced -o name kubectl api-resources: クラスター内の全てのKubernetesリソース種別を表示 --verbs=list: list操作が可能なものに絞る --namespaced: 名前空間に属するリソースに絞る (NamespaceやNodeなどのcluster-scopedリソースは除外) -o name: kubectlで直接使えるリソース名だけを出力 tr '\n' ',' 出力されたリソース名を、改行区切りからカンマ区切りに変換 sed 's/,$//' 末尾に付いてしまった余分なカンマを削除

jqコマンドとは、JSON形式のデータを処理・変換するためのコマンドです。 普段はkubectlやAWS CLIと組み合わせて使うことが多いのですが、使い方やオプションをきちんと調べたことがなかったため、本記事の執筆を機に改めておさらいしようと思います。 この記事では、知っておくと便利な関数やjqコマンドの実践的な組み合わせ例を紹介します。 インストール方法 macOSの場合は以下のコマンドでインストールできます。 brew install jq jqコマンドの関数 keys関数 これまではjq ','のように全階層をまとめて表示してキーを把握していましたが、keys関数を使うと一階層ずつキーを表示できます。 # labelのキーを取得する kubectl get pod my-pod -o json | jq '.metadata.labels | keys' select関数 select関数は条件にマッチした項目のみを抽出します。 # Running状態ではないPodの一覧を取得する kubectl get pods -A -o json | jq '.items[] | select(.status.phase != "Running") | .metadata.name' # 上記の応用として、namespace、Pod名、Podの状態も合わせて表示する kubectl get pods -A -o json | jq -r '.items[] | select(.status.phase != "Running") | "\(.metadata.namespace) \(.metadata.name) \(.status.phase)"' | column -t 2つ目のコマンドではいくつかのオプションや機能を使っているため、それらについて説明します。 -r: ダブルクォートを削除するオプション(デフォルトでは"が付いてくる) "\(filter)": 文字列の中で \(filter) を使うことで、抽出した値を文字列に埋め込める。これにより、複数の値を空白区切りで1行に表示できる columnt -t: columnコマンドの-tオプションを使うことで、区切り文字を基準に列を揃えて表形式で表示できます contains関数 contains関数は指定した文字列が含まれていればtrueを返します。...

しばらく放置していたNUC上にk8sをインストールして、おうちクラスタを運用していこうと思います。 今回はkubeadmを使ってk8sをインストールしようと思います。 前提 ベアメタル(Intel NUC11PAHi5)上に構築 Control Planex1台とWorkerx3台の4台構成 OSはRocky Linux9.3 ルーター側の設定で固定IPを割り当て 各ノードのスペックは以下 CPU メモリ ストレージ 4コア 16GB 500GB kubeadmのインストール 以下の手順を参考にします。 kubeadmのインストール 「始める前に」にSwapがオフであること、と記載がありますが、swapがオフになっていなかったので無効化します。 sudo swapoff -a ポートの開放 kubernetesのコンポーネントが互いに通信するために、これらのポートを開く必要があります。 RockyはRHEL系なのでfirewall-cmdを使って、Control Planeノードのポートを開放します。 sudo firewall-cmd --add-port=6443/tcp --permanent sudo firewall-cmd --add-port=2379-2380/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent sudo firewall-cmd --add-port=10257/tcp --permanent sudo firewall-cmd --add-port=10259/tcp --permanent ポートが開放されたことを確認します。 sudo firewall-cmd --reload sudo firewall-cmd --list-ports 続いて各Workerノードのポートを開放します。 sudo firewall-cmd --add-port=30000-32767/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent ポートが開放されたことを確認します。 sudo firewall-cmd --reload sudo firewall-cmd --list-ports コンテナランタイムのインストール コンテナランタイムの手順を参考に、各ノードに設定をしていきます。...

Kubernetes上でAlertmanagerがちゃんと通知できるか、どんな内容が通知されているのか確認してみようとすると、連携するためのSlackが必要であったり、Emailを送信するにもメールサーバが必要だったりと、意外と気軽に試せないということがありました。 なので、今回はwebhookの機能を使ってNginxにリクエストを飛ばし、リクエストの内容をログから確認してみようと思います。 webhookとは? Alertmanagerのreceiverには以下が指定できます。 Email Opesgenie PagerDuty Pushover Slack AWS SNS VictorOps Webhook Wechat Telegram Webex Webhookとは特定のエンドポイントに対してHTTP POSTリクエストでアラートの情報を送信するというものです。 外部サービスではないので、自分自身でエンドポイントを用意し、自分自身で後続の処理を実装する必要があります。 例えば、以下のように設定します。 receivers: - name: "nginx" webhook_configs: - url: 'http://nginx-svc.default:8080/' webhookの連携先としてnginxを使う 今回はwebhookの連携先としてnginxを使用します。 nginxを使って実現したいことは以下のとおりです。 エンドポイントを用意する リクエスト内容を確認する nginx.confの初期設定をベースにしていますが、そのままだとリクエスト内容を確認することができないので、設定を追加しました。 log_formatで$request_bodyを指定し、/にアクセスした時に$request_bodyがログとして標準出力に出るように設定しています。 しかし、$request_bodyを有効化するにはproxy_passなどの後続処理が必要になります。なので、proxy_passで/trashというエンドポイントにリクエストを転送し、/trashで特に意味のない処理(1x1ピクセルのgifを返す)をしています。 The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer. http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx....