はてなブックマーク

Kubernetes クラスタのトラブルシュートで、ssh でノードに直接アクセスしてデバッグしたい場面があります。しかし、OS アカウントやネットワーク管理の都合で、ssh の利用が難しい場合があります。そんなとき、 kubectl debug node を利用すると、ssh に相当する操作をkubectl で簡単に行えます。 デモ kubectl debug node でノードに Pod を作成し、ホスト上のコマンド(systemctl, htop) を実行したデモです。 kubectl debug node の使い方 kubectl debug pod (Ephemeral Containers) と違い、kubectl debug node は特権を持った Pod を作成しているだけなので、権限さえあれば Kubernetes クラスタ側の設定は不要です。 使い方は非常にシンプルで

Docker で NVIDIA GPU を利用する場合は、NVIDIA Container Toolkit (NVIDIA Docker) が必要になります。この記事では、なぜ NVIDIA Container Toolkit がなぜ必要か、どう動くかについて個人的に調べたことを記載します。2021 年 4 月時点での情報になります。今後のバージョンアップで内容が古くなっている可能性がある点にご注意ください (#確認した環境)。 NVIDIA Container Toolkit (NVIDIA Docker) 自体のインストール方法や歴史については、NVIDIA Japan のNVIDIA Docker って今どうなってるの？ (20.09 版) という記事が非常によくまとまっているため、そちらをご覧ください。 内容が長いため、「まとめ」の章を目次として見ていただければと思います。 なぜ

kubectl で Pod を表示した場合、Running や Terminating などのステータスが表示されます。しかし、このステータスは Pod オブジェクトの単一フィールドを表示しているわけではなく、いくつかのフィールドと条件によって表示が分けられています。 この記事ではよく見る Pod のステータス表記について整理してみます。 kubectl のステータスの出し分け ご存じの通りkubectl で Pod を表示したとき、下記のように STATUS カラムで Pod のステータスを見ることができます。 $ kubectl get pods -w NAME READY STATUS RESTARTS AGE myapp 0/1 Pending 0 0s myapp 0/1 ContainerCreating 0 0s myapp 1/1 Running 0 1s myapp 1/

この記事では conftest というツールを使って、Kubernetes のマニフェストをテストする方法を紹介します。conftest のバージョンは v0.11.0 で確認しています。 マニフェストのテスト 本番環境向けの Kubernetes のマニフェストでは様々な点を考慮する必要があります。考慮する点は環境や組織ごとに違うと思いますが、例えば以下のようなものが挙げられます。 privileged の利用を禁止したい 新しい API Version を利用することを推奨する livenessProbe / readinessProbe の設定を推奨する resource request / limit の設定を推奨する この記事では conftest というツールを使って、これらのポリシーを定義し、マニフェストがそれを満たしているかテストする方法を紹介します。 なお、PodSecu

Kubernetes ではすべての API オブジェクトは kube-apiserver を通して etcd に保存されています。etcd にはデータサイズの制限(クォータ)がありますが、compaction 前の履歴データや断片化のサイズも含むなど、いくつか留意すべき点があります。この記事では etcd の容量管理について知っておくと良さそうな情報をまとめました。etcd のバージョンは 3.2.24 で確認しています。 etcd の容量制限 (クォータ) etcd はデフォルトで 2GB のクォータ が設定されています。これを超過すると etcd が Alarm があがった状態となり、アラームを解除 (disarm) しない限り、etcd にデータの書き込みができない状態になります。容量超過の場合は mvcc: database space exceeded というエラーメッセージが表

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

kubernetes-incubator で開発が進められている、Kubernetes Descheduler という Pod の再スケジューリングを行うためのコンポーネントについて調べてみました。v0.6.0 時点での情報をもとに記載しています。 Kubernetes Descheduler とは Kubernetes のスケジューラは Pod の作成時にしかスケジューリングを行わないため、長期的に見ると下記のような課題があります。 ノードのリソース使用率に偏りがでてしまう スケジュール後に taints, label などが変更されても、スケジュール済みの Pod には反映されない 新しくノードが追加されても、その時点では Pod は分散されない Kubernetes Descheduler はスケジュール済みの Pod 削除 (evict) し再スケジュールさせることでこの問題を解決

Kubernetes で Pod をノードに割り当てるスケジューラ kube-scheduler の動作についてまとめてみました。動作の検証やソースコードの参照は kubernetes v1.9.2 のものを使っています1。 スケジューラのお仕事 Kubernetes のスケジューラの仕事は、新規に Pod が作成されたときに最適なノードを選択して割り当てることです。スケジューラで重要なのは最適なノードをどう選択をするかで、様々なフィルタと優先度付けが実装されています。 スケジューラは kube-scheduler という独立したバイナリになっています。Policy ファイルにより柔軟なカスタマイズが可能で、フィルタや優先度付けの選択や、優先度の重み付け、WebHook による拡張などが可能です。 大雑把な動作は以下のようになります。 新規 Pod が作成される スケジューラは API サ

はじめに Kubernetes 上のアプリケーションに対して、curl や tcpdump など使い慣れたツールを使ってデバッグを行いたいと思う場合があるかと思います。kubectl exec を利用するとコンテナ内のコマンドを実行することができ、従来 ssh で行っていたデバッグに近いことが可能になります。一方、コンテナには必要最低限のものしか含めないことがベストプラクティスとなっているため、使いたいコマンドが含まれていないこともあるでしょう。 本記事では、kubectl exec を主としたデバッグの方法と、コンテナに使いたいコマンドが含まれていない場合や kubectl exec が利用できない場合の対応方法などについて説明します。確認は Kubernetes v1.8 で行い、コンテナランタイムは Docker を前提としています。 kubectl exec を使ったデバッグ ku

kubectl apply はオブジェクトが存在しなければ作成し、存在すれば差分を反映してくれる便利なコマンドです。しかし差分の反映は単純な上書きではないので注意が必要です。この記事では Kubernetes Meetup Tokyo #5 で発表した内容をベースに kubectl apply の動作を整理してみました。Kubernetes v1.9.0 で確認をしています。 kubectl apply とは kubectl にはオブジェクトを操作する様々なサブコマンドが用意されています。apply 以外の create, replace などのサブコマンドは、現在のオブジェクトの状態を意識して操作をする必要があります。例えば kubectl create では存在する名前のオブジェクトを再度作ろうとするとエラーになりますし、kubectl replace では存在しないオブジェクトを上書

この記事は Pod Security Policy (PodSecurityPolicy)によるセキュリティの設定について Kubernetes v1.9 で確認した内容になります。v1.9 未満では RBAC 周りで大きな違いがあるのでご注意ください。 PodSecurityPolicy とは PodSecurityPolicy とはクラスタ全体のセキュリティ上のポリシーを定義する機能です。ホストに影響を与える可能性がある 特権 (privileged) や HostIPC などの機能を制限し Pod に脆弱性があった場合にクラスタを守ることができます。ポリシーの制限は Admission Control として実装されており、ポリシーを満たしていない Pod の実行を拒否することができるようになります。Design Proposal を見るとマルチテナントでの利用を想定した機能のようで

各プロジェクト Kubernetes Kubernetes はコンテナのオーケストレーションツールです。Kubernetes によって数台から数千台のサーバーが一つのクラスタとして管理され、シンプルなインタフェースを通してその中に効率良くコンテナを配置し管理することができます。これにより数百のサーバー台数が必要なアプリケーションのデプロイもコマンド一つで簡単に行うことができます。コンテナを採用することで PaaS と比べて高い柔軟性を持っており、IaaS レイヤを抽象化しマルチクラウドを実現する点も注目されています。 元々は Google が社内のオーケストレーションツール Borg で得た 10 年以上の経験を元に開発を始めたプロジェクトで、最初に CNCF に寄贈されたプロジェクトになります。CNCF プロジェクトの中でも圧倒的に規模が大きく、CNCF 主催の KubeCon + Cl

Prometheus 2.0 の目玉であるリライトされたストレージ prometheus/tsdb の構造と何が変わったかを説明します。 要約 Prometheus 2.0 ではストレージが完全に書き直され、今までの課題について改善され大きくパフォーマンスが向上しました 大量のファイルができることによるパフォーマンスの問題 時間の範囲ごとに block という単位でまとめて管理されるようになった メモリ管理の問題 mmap によってカーネル側のキャッシュ管理になった 歯抜データによるインデックスの問題 転置インデックスが導入された Prometheus v1.6.3 と v2.0.0 を 24 時間動かしたデータを比較したところ、公式アナウンスの通り、CPU・メモリ共にパフォーマンスが大きく向上していることが確認できました。 今まで (Storage v2) の課題 今までの Promet

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Prometheus 2.0 の主な変更点と移行するときのメモをまとめました。 主な変更点 ストレージ部分がリライトされてパフォーマンスが大きく向上 CPU、ディスク使用量、I/O のすべてが改善された オプションがシンプルになり -storage.local.target-heap-size のチューニングが不要に(後述) v1.x からデータファイルの移行はできないので注意 コードは prometheus/tsdb という独立したレポジトリで管理されている staleness の取扱が変わった staleness とはターゲットが消

Kubernetes の Deployment のローリングアップデートが起こる条件と設定についてのメモです。Deployment のローリングアップデート自体の仕組みについては Kubernetes: Deployment の仕組み にまとめています。 Deployment のローリングアップデートが起きる条件 Deployment のローリングアップデートは Deployment の Pod Template (.spec.template) という Pod のテンプレート情報に変更があったときにのみ行われます。例えば Deployment のアノテーション(.metadata.annotations) を変更してもローリングアップデートは起きませんが、Pod Template のアノテーション(.spec.template.metadata.annotations) を更新するとロー

OS のアップデートやスケールダウンなどで複数の Node を安全に停止したい場合のメモです。この記事は Kubernetes 1.7.3 で確認した情報を元に記載しています。 TL;DR Node を停止するためにはkubectl drain コマンドを利用して停止準備を行います drain は Node を Pod のスケジュール対象から外し (unschedulable に設定) Node 上の Pod を退去させることで停止可能な状態にします しかし複数の Node を停止させる場合、アプリケーションの Pod が一つも動作していない状態 (ready な Pod が 0)がありえるので注意が必要です PodDisruptionBudget を定義することで安全な Pod 数を保ったまま複数 Node の drain を行うことができるようになります 安全な Pod 数が確保できる

このエントリは Kubernetes v1.7 CHANGELOG の Notable Features のうち個人的に気になるものを抜粋しています。 https://github.com/kubernetes/kubernetes/blob/3f0141edd52ab6fd7b6fe473ecceb480faf12079/CHANGELOG.md#notable-features その他の項目は下記を参照してください。 Kubernetes v1.7: 主な変更点 (Major Themes) Kubernetes v1.7: Action Required Before Upgrading Kubernetes v1.7: Deprecations Kubernetes v1.7: Notable Features 抜粋 Notable Features 抜粋 Node の hostI

このエントリは Kubernetes v1.7 CHANGELOG の 主な変更点 (Major Themes) をまとめています。 https://github.com/kubernetes/kubernetes/blob/3f0141edd52ab6fd7b6fe473ecceb480faf12079/CHANGELOG.md#major-themes その他の項目は下記を参照してください。 Kubernetes v1.7: 主な変更点 (Major Themes) Kubernetes v1.7: Action Required Before Upgrading Kubernetes v1.7: Deprecations Kubernetes v1.7: Notable Features 抜粋 主な変更点 詳細は右メニューの各項目へのリンクからご覧ください。 セキュリティ強化 etc

Kubernetes v1.7 で導入された Node Authorization について概要と kubeadm で構築して試してみた結果をまとめました。確認は Kubernetes v1.7.0 で行っています。 概要 Node Authorization とは Node (Kubelet) の権限管理をより厳密に行う機能です。この機能を有効にすることで、Node はその Node が関連するオブジェクトにのみ権限が制限されるようになります。例えば Node は割り当てられた Pod が参照する Secret 以外にはアクセスできなくなります。これにより Node のクレデンシャルが漏洩したときのセキュリティリスクを最小限にすることができます。 制限されるリソース Node Authorization を有効にすると Node がアクセスする必要があるリソースをその Node に関連あ

Kubernetes 1.6 で Role-Based Access Control (RBAC) が beta になり、デフォルトのロールの拡充や kubectl からロールの紐付けができるようになったりと大幅にアップデートされました 。以下は v1.6 の RBAC と minikube で試す際のメモになります。 v 1.6 での RBAC の主な変更点 デフォルトロールの拡充。汎用的に使える読み取り専用ロール (view) や 書き込み権限ロール (edit) などが用意されました。 kubectl のサブコマンド create rolebinding/clusterrolebinding が追加され簡単にロールの紐付けができるようになりました API Server の --anonymous-authがデフォルトで有効になりました 認証を通さない場合、RBAC ではsystem:

kubernetes v1.6.0 で追加された ConfigMap / Secret の内容を一度に Pod への環境変数として読み込むという機能 (envFrom) が便利だったのでご紹介します。 v1.6 以前の指定方法 v1.6 以前は ConfigMap / Secret のキーを環境変数として読み込む場合、以下のようにひとつづつキーを読み込まなければならず、キーが多い場合に冗長な記述となっていました。 kind: Pod metadata: name: mypod spec: containers: - name: nginx image: nginx env: # 一つづつ環境変数に読み込まなければいけなかった - name: USERNAME valueFrom: configMapKeyRef: name: myconfig # ConfigMap の name key:

この記事は Kubernetes 1.5.2 で確認した情報を元に記載しています。 Deployment Deploymentはローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するものです。 Deployment の仕組み 下記の図のようにDeploymentはReplicaSetを生成・管理し、ReplicaSetはPodを生成・管理します。 ReplicaSet(ReplicationControllerの後継)はPodTemplateと呼ばれるPodのテンプレートをもとに、Podを指定された数(レプリカ数)に調整・管理を行う仕組みです。Podがレプリカ数より足りない場合はPodを追加し、多い場合はをPodを削除します。この仕組みによってノードの障害やアプリケーションのクラッシュでPodが足りなくなった際も自動的にPodが追加され、セルフヒーリングが実現されていま

参考 Kubernetes architecture 2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters and Where We're Going Next etcd v3 as storage backend for APIServer #44 Kubernetes: 構成コンポーネント一覧 Kubernetes: コンテナが起動するまでの各コンポーネントの流れ 複数クラスタ連携 (Federated Kubernetes) Federated Kubernetesは複数のKubernetesを連携させる機能です。Ubernetes("uber-"は"超える"の意味の接頭辞)とも呼ばれます。AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタ

KubernetesのRBAC(Role-based access control)の設定用にAPIリソースについてまとめました。Kubernetes v1.4時点での情報になります。 KubernetesのAPI KubernetesのAPIは、API ResourceとNon-Resource URLの2つに分けられます。 API Resource Kubernetes上で扱われる情報(Pod, Service等)はapiserver上ではAPI Resourceとして定義されています。kube-schedulerやkubelet、kubectlなどKubernetesのコンポーネントはこのAPIリソースをHTTPで操作することでPodの配置などの実際の操作を行います。(参考: Kubernetes: コンテナが起動するまでの各コンポーネントの流れ パスの形式例(requestinfo

Kubernetes 1.4の新機能としてkubeadmというkubernetesクラスタ構築を大幅に簡略化するための仕組みが入りました。1.4の時点ではalpha機能のため本番環境の構築には今後のバージョンを待つ必要があります。 マニュアルに沿ってGoogle Compute EngineのVMで実際に試してみました。 概要 下記の4手順で簡単にKubernetesクラスタを作ることができるようになりました。(Dockerのswarm join/initのイメージ) 関連パッケージのインストール kubeadm initでマスターを初期化 kubeadm join --token xxxx yyy.yyy.yyy.yyyでワーカーを追加 Podネットワークのデプロイ これでクラスタの構築が完了します。 準備 GCPで下記のVMを3台(Master*1, Worker*2)作成しました。

Kubernetes 1.4が出たので変更点をざっとみてみました。主に下記の情報を参考にしています。 Kubernetes 1.4: Making it easy to run on Kubernetes anywhere Kubernetes Feature tracking board (1.4 release) ScheduledJobs (alpha) ScheduledJobsというcronに相当するスケジュールベースのジョブの仕組みが追加されました。 下記のようなyamlでジョブを設定するようです。(マニュアルより) apiVersion: batch/v2alpha1 kind: ScheduledJob metadata: name: hello spec: schedule: 0/1 * * * ? jobTemplate: spec: template: spec: c

Kubernetesの1.4で追加されそうなImage Policy Webhookというイメージの制御ができる機能が面白そうだったので概要をまとめてみました。 Image Policy (Image Provenance)とは Image PolicyとはKubernetesクラスタ上で動かすコンテナイメージを独自に制御したい場合に使える仕組みです。Proposalのドキュメントによると下記のようなユースケースを想定しているようです。 既知の脆弱性を含まないことを確認されたイメージだけを動かしたい 特定のベースイメージを使ったイメージだけを動かしたい レビュー済みのコードでビルドされたイメージだけを動かしたい 署名されたイメージだけを動かしたい Image Policy Webhookは、ユーザが定義するWebAPIに対してそのPodに含まれるコンテナイメージの情報を渡し、実行可否をチェ