19 Followers
·
Follow

どちらかというとクラスター管理者向け

Image for post
Image for post
discovery

Kubernetes は様々な label を使うことで Pod 等の様々なリソースを効率よく管理することが出来ます。

Kubernetes の Node も同様に様々な label を付けることが可能です。利用者からすればリソースを Node に配置する時に、意図した Node に配置したいケースもあると思います。その際に Node に適切な label が設定されていて欲しいですよね。

利用者にとっては、例えば「特定の CPU の命令セットが実行できる Node に Pod を配置したい」なんて要望があるかもしれません(AVX2 や FMA3 等)。もしくは「 CPU の model や stepping を選択して配置したい」なんてケースもあるかもしれません。

Kubernetes はデフォルトでいくつかの labelNode に付与してくれますが、さすがにこのような CPU の細かい情報までは自動で付与してくれません。クラスター管理者が Node をセットアップする際に付与してあげたりしないといけません。管理者側からすると、いちいち物理的な情報を調べて、それを label として付与するのは手間ですよね。

Node feature discovery for Kubernetes

そこで登場するのが Node feature discovery for Kubernetes です(長いので 以下 NFD と略します)。

NFD は Nodeのハードウェア的な情報を discovery して label として付与してくれるやつです(後述しますが、こいつの実力はそれだけではない・・!)

クラスター管理者としては、利用者のニーズにはなるべく応えてあげたいところです。NFD を使うことでその手助けになるのではないでしょうか。

NFD を起動させると下記のような labelNode に付与されることが確認できると思います(後述する仕組みを使った labelも付与されてます)。

Image for post
Image for post
sample labels

NFD が discovery できるものは CPU や kernel だけではなく、PCIや USB といった物も対応しています。詳しくは README を御覧ください。

NFD のアーキテクチャ

NFD は nfd-masternfd-worker によって構成されています。 nfd-worker はその名の通り各 Node で動き、discovery を行います。その結果を nfd-master に送信し、 nfd-master は Kubernetes の APIに対して実際の label


Let’s keep your manifests safe and solid

Image for post
Image for post
The result is commented on PR page

Validating your Kubernetes manifests is very important for some security reasons especially in the case of GitOps. Ideally, the validation process should be integrated with your CI workflow.

GitHub Actions

GitHub Actions is powerful and easily setup CI workflow. You can find and use various useful actions that are published at GitHub Marketplace.

Conftest

Conftest helps you write tests for your Kubernetes manifests. Conftest uses the Rego language for writing tests.

The following example is checking whether container(s) uses latest image tag.

check image tag

This example uses extra kubernetes library. See the library and other examples described in instrumenta/policies repository.

And the output…


kubeval 編

Image for post
Image for post

Kubernetes の Manifests は yaml(もしくはjson) で記述されているのですが、正しい schema で記述されているのか判断したいと思ったことはありませんでしょうか。

例えば値のところに数字を書く時に " で括って strings として書くのか、そのまま int で書くのか迷ったり、いつのまにか indent がずれていた、なんて経験あるのではないでしょうか。

例えばこんな yaml があったとしましょう。

この manifest 内には Kubernetes の schema に合っていない記述が 2 つあります。1 つ目は replicas: の値が strings になっている部分です。この場合は "1" ではなく 1 と書くべきですよね。2 つ目は port: の部分です。これは ports: が正解になります。

例えば gitops とかで運用されているシステムでは、何らかの理由でこのような不正な manifests が紛れ込んでしまうのは極力避けたいところです。

Manifests の validation

Manifests の validation と聞くと真っ先に考えるのは kubectl--validate オプションです(デフォルトで true ) 。 --dry-run もしくは --server-dry-run と組み合わせることで validation することが可能です。

もちろんこの方法でも問題無いとは思いますが、 kubectl 方式だと Kubernets の cluster を用意しないといけません。もちろん RBAC を使っている場合は適切な認証情報も必要ですし、場合によっては Kubernetes の version 毎に kubectlを用意しないと正しくチェックできないかもしれません。その為 CI に組み込む際にも一手間かけないといけなくなります。

Kubeval を使った validation

そこで登場するのが Kubeval です。 Kubeval は Kubernetes の Cluster を用意していなくても実行できる Manifests の validation ツールです。複数の Kubernetes の version の schema…

About

makocchi

Makoto Hasegawa | kubernetes | CKA(#CKA-1700–0150–0100) | CKAD(CKAD-1800–0005–0100) | docker | container | OpenStack

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store