Kubernetes: Kubernetes Descheduler とは - Qiita
kubernetes-incubator で開発が進められている、Kubernetes Descheduler という Pod の再スケジューリングを行うためのコンポーネントについて調べてみました。v0.6.0 時点での情報をもとに記載しています。 Kubernetes のスケジューラは Pod の作成時にしかスケジューリングを行わないため、長期的に見ると下記のような課題があります。 ノードのリソース使用率に偏りがでてしまう スケジュール後に taints, label などが変更されても、スケジュール済みの Pod には反映されない 新しくノードが追加されても、その時点では Pod は分散されない Kubernetes Descheduler はスケジュール済みの Pod 削除 (evict) し再スケジュールさせることでこの問題を解決します。Descheduler はあくまで Pod
Kubernetes 1.3の変更点(予定) - Qiita
Kubernetes 1.3で入りそうな機能についてまとめてみました。現時点(2016/5/17)ではFeature Completeになっていなく、決定した情報ではないのでご注意ください。1.3のリリースは2016年6月末を予定しているようです。 主な参考情報 kubernetes/kubernetes v1.3 milestone Kubernetes Community Hangout Working Doc Kubernetes 1.3 - Effort tracking dashboard Youtubeの Kubernetes Community Meeting の録画 Kubernetes Wiki Release 1.3 主な変更点 Ubernetes(複数クラスタ連携)の実装 (alpha) Ubernetesは複数のKubernetesクラスタを連携させる機能です。("
Kubernetes: Deployment のローリングアップデートの条件と設定 - Qiita
Kubernetes の Deployment のローリングアップデートが起こる条件と設定についてのメモです。Deployment のローリングアップデート自体の仕組みについては Kubernetes: Deployment の仕組み にまとめています。 Deployment のローリングアップデートが起きる条件 Deployment のローリングアップデートは Deployment の Pod Template (.spec.template) という Pod のテンプレート情報に変更があったときにのみ行われます。例えば Deployment のアノテーション(.metadata.annotations) を変更してもローリングアップデートは起きませんが、Pod Template のアノテーション(.spec.template.metadata.annotations) を更新するとロー
Kubernetes: Pod Security Policy によるセキュリティの設定 - Qiita
この記事は Pod Security Policy (PodSecurityPolicy)によるセキュリティの設定について Kubernetes v1.9 で確認した内容になります。v1.9 未満では RBAC 周りで大きな違いがあるのでご注意ください。 PodSecurityPolicy とは PodSecurityPolicy とはクラスタ全体のセキュリティ上のポリシーを定義する機能です。ホストに影響を与える可能性がある 特権 (privileged) や HostIPC などの機能を制限し Pod に脆弱性があった場合にクラスタを守ることができます。ポリシーの制限は Admission Control として実装されており、ポリシーを満たしていない Pod の実行を拒否することができるようになります。Design Proposal を見るとマルチテナントでの利用を想定した機能のようで
Kubernetes: スケジューラの動作 - Qiita
Kubernetes で Pod をノードに割り当てるスケジューラ kube-scheduler の動作についてまとめてみました。動作の検証やソースコードの参照は kubernetes v1.9.2 のものを使っています1。 スケジューラのお仕事 Kubernetes のスケジューラの仕事は、新規に Pod が作成されたときに最適なノードを選択して割り当てることです。スケジューラで重要なのは最適なノードをどう選択をするかで、様々なフィルタと優先度付けが実装されています。 スケジューラは kube-scheduler という独立したバイナリになっています。Policy ファイルにより柔軟なカスタマイズが可能で、フィルタや優先度付けの選択や、優先度の重み付け、WebHook による拡張などが可能です。 大雑把な動作は以下のようになります。 新規 Pod が作成される スケジューラは API サ
Kubernetes: アプリケーションのデバッグ方法 (kubectl exec など) - Qiita
はじめに Kubernetes 上のアプリケーションに対して、curl や tcpdump など使い慣れたツールを使ってデバッグを行いたいと思う場合があるかと思います。kubectl exec を利用するとコンテナ内のコマンドを実行することができ、従来 ssh で行っていたデバッグに近いことが可能になります。一方、コンテナには必要最低限のものしか含めないことがベストプラクティスとなっているため、使いたいコマンドが含まれていないこともあるでしょう。 本記事では、kubectl exec を主としたデバッグの方法と、コンテナに使いたいコマンドが含まれていない場合や kubectl exec が利用できない場合の対応方法などについて説明します。確認は Kubernetes v1.8 で行い、コンテナランタイムは Docker を前提としています。 kubectl exec を使ったデバッグ ku
Kubernetes: kubectl apply の動作 - Qiita
kubectl apply はオブジェクトが存在しなければ作成し、存在すれば差分を反映してくれる便利なコマンドです。しかし差分の反映は単純な上書きではないので注意が必要です。この記事では Kubernetes Meetup Tokyo #5 で発表した内容をベースに kubectl apply の動作を整理してみました。Kubernetes v1.9.0 で確認をしています。 kubectl apply とは kubectl にはオブジェクトを操作する様々なサブコマンドが用意されています。apply 以外の create, replace などのサブコマンドは、現在のオブジェクトの状態を意識して操作をする必要があります。例えば kubectl create では存在する名前のオブジェクトを再度作ろうとするとエラーになりますし、kubectl replace では存在しないオブジェクトを上書
Kubernetes: 複数の Node を安全に停止する (kubectl drain + PodDisruptionBudget) - Qiita
Kubernetes: 複数の Node を安全に停止する (kubectl drain + PodDisruptionBudget)kubernetes OS のアップデートやスケールダウンなどで複数の Node を安全に停止したい場合のメモです。この記事は Kubernetes 1.7.3 で確認した情報を元に記載しています。 TL;DR Node を停止するためにはkubectl drain コマンドを利用して停止準備を行います drain は Node を Pod のスケジュール対象から外し (unschedulable に設定) Node 上の Pod を退去させることで停止可能な状態にします しかし複数の Node を停止させる場合、アプリケーションの Pod が一つも動作していない状態 (ready な Pod が 0)がありえるので注意が必要です PodDisruption
Kubernetes: ConfigMap / Secret の内容を一度に環境変数として読み込む (envFrom) - Qiita
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 v1.7: 主な変更点 (Major Themes) - Qiita
このエントリは 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 抜粋 詳細は右メニューの各項目へのリンクからご覧ください。 セキュリティ強化 etcd の暗号化
Kubernetes v1.7: Notable Features 抜粋 - Qiita
このエントリは 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 抜粋 Node の hostIP が downward API で取れ
Kubernetes: v1.7 で導入された Node Authorization とは - Qiita
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: RBACの設定におけるAPIリソース - Qiita
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: v1.6 の Role-Based Access Control (RBAC) を minikube で試す - Qiita
Kubernetes: v1.6 の Role-Based Access Control (RBAC) を minikube で試すkubernetes Kubernetes 1.6 で Role-Based Access Control (RBAC) が beta になり、デフォルトのロールの拡充や kubectl からロールの紐付けができるようになったりと大幅にアップデートされました 。以下は v1.6 の RBAC と minikube で試す際のメモになります。 v 1.6 での RBAC の主な変更点 デフォルトロールの拡充。汎用的に使える読み取り専用ロール (view) や 書き込み権限ロール (edit) などが用意されました。 kubectl のサブコマンド create rolebinding/clusterrolebinding が追加され簡単にロールの紐付けができるよ
Kubernetes: Image Policy Webhookとは - Qiita
Kubernetesの1.4で追加されそうなImage Policy Webhookというイメージの制御ができる機能が面白そうだったので概要をまとめてみました。 Image Policy (Image Provenance)とは Image PolicyとはKubernetesクラスタ上で動かすコンテナイメージを独自に制御したい場合に使える仕組みです。Proposalのドキュメントによると下記のようなユースケースを想定しているようです。 既知の脆弱性を含まないことを確認されたイメージだけを動かしたい 特定のベースイメージを使ったイメージだけを動かしたい レビュー済みのコードでビルドされたイメージだけを動かしたい 署名されたイメージだけを動かしたい Image Policy Webhookは、ユーザが定義するWebAPIに対してそのPodに含まれるコンテナイメージの情報を渡し、実行可否をチェ
Kubernetes 1.4の変更点 - Qiita
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: クラスタ構築が簡単になるkubeadm - Qiita
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の主な機能一覧 (v1.5時点) - Qiita
参考 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: パッケージマネージャHelm - Qiita
公式レポジトリ 公式レポジトリではstableとincubatorの2つに分けて管理されています。kubernetes/chartsのstableの説明によると下記のポリシーで運用されています。 データ永続化の方法が提供される アプリケーションのアップグレードがサポートされる アプリケーション設定のカスタマイズを許可する セキュアなデフォルト設定を持つ Kubernetesのアルファ機能を利用しない 公式レポジトリ以外に任意のレポジトリを使用することも可能です。なお、現在は下記のパッケージが提供されています。 Stable drupal jenkins mariadb mysql redmine wordpress Incubator consul elasticsearch etcd grafana mongodb patroni prometheus spark zookeeper 旧
Kubernetes: Deployment の仕組み - Qiita
Deploymentはローリングアップデートやロールバックといったデプロイ管理の仕組みを提供するものです。 下記の図のようにDeploymentはReplicaSetを生成・管理し、ReplicaSetはPodを生成・管理します。 ReplicaSet(ReplicationControllerの後継)はPodTemplateと呼ばれるPodのテンプレートをもとに、Podを指定された数(レプリカ数)に調整・管理を行う仕組みです。Podがレプリカ数より足りない場合はPodを追加し、多い場合はをPodを削除します。この仕組みによってノードの障害やアプリケーションのクラッシュでPodが足りなくなった際も自動的にPodが追加され、セルフヒーリングが実現されています。 Deploymentはコンテナイメージのバージョンアップなどアップデートがあった場合、新しい仕様のReplicaSetを作成し、新旧
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
