KubernetesのResource RequestsとResource Limitsについて - Qiita
Resource Requests とは podをデプロイする時に必要とするリソース(CPU/メモリ)を指定することができる仕組み。 ただしpodは指定したresource requests以上のリソースを使うことができる。(リソース使用量の制限はlimitを使う) またその指定したリソースがそのpod用に確保されるわけではない。 あくまでpodをデプロイ時にそのリソース量が空いているかをチェックするためのもの。 ポイントとしてはpodをデプロイするときに、nodeのリソース使用量は見ないで、resource requestsをみてデプロイが行われる。 なので、nodeのリソース(CPUやメモリ)の使用率が100%でも、resource requestsに空きがあればデプロイされる。空きがないnodeにはデプロイされない。 たとえばメモリ1Gのnodeがあって、resource reque
KubernetesのTaintsとTolerationsについて - Qiita
Kubernetesには最初、特定のnodeに特定のpodをscheduleする方法としてnode selectorを使う方法があった。(node selectorの他にも特定のnodeに特定のpodをscheduleするための仕組みとしてNode Affinityがある) しかし後からもっと柔軟にscheduleするためのメカニズムが導入された。 それがTaintsとTolerations。 (taintは"汚れ"という意味。tolerationは"容認"という意味。つまり"汚れ"を"容認"できるならscheduleできる仕組み) TaintsとTolerationsはNode SelectorやNode Affinityと似ているが性質は正反対で、 Node SelectorやNode Affinityが特定のnodeに特定のpodをscheduleするための仕組みに対し、 Taint
KubernetesのNode Affinity, Inter-Pod Affinityについて - Qiita
taints/tolerations(参考)は特定のNodeにPodをscheduleされるのを避けるための仕組み。 それに対してNode Affinityという仕組みは、Podを特定のNode集合へscheduleするための仕組みだ。 特定のNodeにPodをscheduleするための仕組みとしてはnode selectorがある。Node Affinityはnode selectorよりももっとパワフル。 Node AffinityはNodeのlabelとして設定する。 そして(node selectorはpodにselectorを設定したが、同様に)Node Affinity ruleはpodに設定する。 podのNode Affinity ruleにnodeのlabelのNode Affinityがマッチした場合、そのnodeへpodがscheduleされる。 まずnodeのlab
helmとは & helmの使い方 - Qiita
Kubernetes Helm(以降Helm)とはKubernetesのパッケージマネージャーです。HelmはKubernetesのSIG-Appsで開発がされています。パッケージはChart(s)と呼ばれ、公式でレポジトリkubernetes/chartsが用意されています。Kubernetesクラスタに側にはtillerと呼ばれるデプロイ用のコンポーネントを配置して使用します。 用語 用語 意味 役割
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
