Action」を読んで学んだ結果を社内で共有しました。その第3回の内容です。PersistentVolumeClaimに対して、CPUやメモリのリソースの最小値/最大値、デフォルト値を設定することが可能。LimitRangeはNamespaceに対して制限をかけるため、Namespaceごとに設定する必要がある。LimitRangeは新規でpodを作成する際に利用されるため、既存のpodには影響を与えない。Limitsを設定していないと、QoSクラスがBestEffortになってしまいkillされやすくなってしまう。Limitsを設定する必要がある。ストレージのサイズを制限する。Requestsを設定しないと無限にスケジューリングされてしまうため、GKEではCPUのdefaultRequestが100mに設定されている。Limitsが設定されていないコンテナはこのデフォルト値が設定される。Requestsの4倍以上設定できないことを指す。Limitは801millicores以上は設定できない。ちなみに、たとえLimitRangeリソースを設定してpodが使用可能なResource量を制限しても、podを何個も作成したらClusterのリソースを食い尽くしてしまう。それを防ぐにはResourceQuotaリソースを使う必要がある。ResourceQuotaリソースResourceQuotaリソースを使用することで各Namespaceに対して利用可能なリソース量を制限することができる。LimitRangeリソースはPodごとに適用されるがそれに対してResourceQuotaリソースはNamespaceに対して適用される。制限可能な対象は大きく分けて「作成可能なリソース数の制限」と「リソース使用量の制限」の2種類がある。Podの数があるPodを作成するとき、ResourceQuotaリソースで定義された制限を超えていないかチェックされる。超えていたらPodは作成できない。以下のようなエラーメッセージが表示される。limits.cpu=600m,requests.cpu=400m既存のResourceQuotaリソースの設定を変更しても、既存のpodには影響がない。Limitsのトータル値に対して制限がかかる。Firehoseの料金が高かったmonday.comのURLをSlackに貼ったら展開されるようにしたSpinnakerについて調べたのでまとめる月別アーカイブはてなブログをはじめよう!shepherdMasterさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。