Go to Qiita Advent Calendar 2024 Top
LoginSignup
10
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@Morix1500

Kyvernoをさわってみた

Last updated at Posted at 2021-08-11

この記事について

業務でKyvernoを使ってますが、一部機能しか使っておらず
全機能を把握できてないため調査のためにこの記事を書いてます。

Kyvernoとは

KyvernoとはKubernetes向けのポリシーエンジンです。
ポリシーとはk8sリソースを作成する際のルールです。
例えば・・・

  • Podには必ず○○というLabelがついていないといけない
  • latestタグの利用禁止
  • などなど

OpenPolicyAgentとの大きな違いとして、
Regoのような特別な言語を用いずにポリシーを定義できる点だと思います。

Kyvernoでできること

  • リソースが新規作成された際に別のリソースを新規作成できる
  • リソースが新規作成・更新された際にパッチを当てられる
  • リソースの作成された際に、ポリシーに則ってるか検証し、作成を拒否することができる

これらの機能をそれぞれ触ってみたいと思います！

インストール

マニフェストがGitHubで用意されてるのでそれを使います。
ちなみに今回使うKyvernoのバージョンは v1.4.1 です。

$ kubectl apply -f https://raw.githubusercontent.com/kyverno/kyverno/v1.4.1/definitions/install.yaml

さわってみた

Generate Resources

Generate Resourcesとは、リソースの新規作成 or 更新されたのをトリガーに
新たなリソースを作成する機能です。
https://kyverno.io/docs/writing-policies/generate/

とりあえずやってみましょう！

各Namespaceで同じSecret情報を使いたいことがあると思います。
そういうシーンを想定して、Namespaceが作成されたのをトリガーにすでに存在するSecretをコピーするポリシーを書いてみます。

まずコピー元となるSecretをdefault namespaceに作成します。

secret-sample.yaml
apiVersion: v1
kind: Secret
metadata:
  name: sample-secret
  namespace: default
type: Opaque
data:
  password: aG9nZQo= # hoge

次にこのSecretをコピーするポリシーを定義します。

secret-copy-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: sync-secrets
  annotations:
    policies.kyverno.io/title: Sync Secrets
    policies.kyverno.io/category: Sample
    policies.kyverno.io/subject: Secret
    policies.kyverno.io/description: >-
      copy sample secret from default namespace to requested namespace.
spec:
  background: false
  rules:
  - name: sync-sample-secret
    match:
      resources:
        kinds:
        - Namespace
    generate:
      kind: Secret
      name: sample-secret
      namespace: "{{request.object.metadata.name}}"
      synchronize: true
      clone:
        namespace: default
        name: sample-secret

ではNamespaceを作成して動作を確認してみましょう。

$ kubectl create namespace test
namespace/test created

# 関係あるところだけ抜粋
$ kubectl get secret sample-secret -o yaml -n test
apiVersion: v1
data:
  password: aG9nZQo=
kind: Secret
metadata:
  name: sample-secret
  namespace: test
type: Opaque

ということで、やりたいことは出来ました。

疑問

やってみて出てきた疑問とその答えを書きます。

spec.rules.generate.synchronizeとは？

今回のサンプルでは synchronize: true としました。これは一体なにを意味するのでしょう？

今回コピーして作られたリソースはソースコード管理ができません。
マニフェストをYamlで定義してGit管理してGitOpsをしてる場合、このリソースは直接編集できてしまいます。
それを防止するために、synchronize を true にすると、コピー元のリソースと同期をしてくれます。

コピー先を編集して同期されるか確認する
# コピーしたSecretリソースのパスワード部分変更
$ k edit secret sample-secret -n test
secret/sample-secret edited

# コピー元
$ k get secret sample-secret -o yaml -n default | grep password | head -1
  password: aG9nZQo=

# コピー先。editで更新したのに元に戻ってる
$ k get secret sample-secret -o yaml -n test | grep password | head -1
  password: aG9nZQo=

さて、先ほどはコピー先を編集してみましたが、コピー元を編集するとどうなるでしょうか。

コピー元を編集して同期されるか確認する
# コピー元のSecretリソースのパスワード部分変更
$ k edit secret sample-secret -n default
secret/sample-secret edited

# コピー元
$ k get secret sample-secret -o yaml -n default | grep password | head -1
  password: YWFhCg==

# コピー先
$ k get secret sample-secret -o yaml -n test | grep password | head -1
  password: YWFhCg==

こちらも同様に同期してくれます。便利ですね！

コピー（Clone）以外にできることは？

今回はCloneという機能を使いました。

clone:
   namespace: default
  name: sample-secret

あとはマニフェストの定義をそのまま書くことも出来ます。

    generate:
      synchronize: true
      kind: ConfigMap
      name: zk-kafka-address
      # generate the resource in the new namespace
      namespace: "{{request.object.metadata.name}}"
      data:
        kind: ConfigMap
        metadata:
          labels:
            somekey: somevalue
        data:
          ZK_ADDRESS: "192.168.10.10:2181,192.168.10.11:2181,192.168.10.12:2181"
          KAFKA_ADDRESS: "192.168.10.13:9092,192.168.10.14:9092,192.168.10.15:9092"

Mutate Resources

Mutate Resourcesとは、マッチしたリソースに対してパッチをあてる機能です。
https://kyverno.io/docs/writing-policies/mutate/

ではさわって行きたいと思います。
今回想定するシーンは、「あるNamespace配下のPodには必ず共通するConfigMapを読み込ませたい」です。

ではまずNamespaceを作成しましょう。

$ kubectl create namespace test2
namespace/test2 created

次に読み込ませたいConfigMapを作成します。

configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: sample-configmap
  namespace: test2
data:
  environment_name: staging

次に test2 配下のPodに対して上記ConfigMapを読み込ませるポリシーを書きましょう。
ConfigMapに記載されている値が環境変数になるような感じで！

add-configmap-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-configmap-policy
  annotations:
    policies.kyverno.io/title: add configmap
    policies.kyverno.io/category: Sample
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: >-
      Add env to pods which place to test2 namespace.
spec:
  rules:
  - name: "Set common environment variables"
    match:
      resources:
        kinds:
        - Pod
        namespaces:
        - test2
    mutate:
      overlay:
        spec:
          containers:
          - (name): "*"
            env:
              - name: ENVIRONMENT
                valueFrom:
                  configMapKeyRef:
                    name: sample-configmap
                    key: environment_name

最後にテスト用のDeploymentを作成します。

test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deployment
  namespace: test2
spec:
  selector:
    matchLabels:
      app: test
  replicas: 1
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

このDeploymentで作成されるPodに対してConfigMapで定義した値を環境変数に設定する設定が加わってるはずです。
見てみましょう。

$ kubectl describe pod -n test2 test-deployment-c49854788-s2wg4 | grep -i ENVIRONMENT
    Environment:
      ENVIRONMENT:  <set to the key 'environment_name' of config map 'sample-configmap'>  Optional: false

このように自動でenv設定を挿入するような設定が出来ました。

疑問

spec.rules.mutate.overlayとは？

mutateは以下の3つのパッチの当て方を指定できます。

  • overlay
    • 追加・置き換えたいマニフェストを記述する方法です
  • Strategic Merge Patch
    • overlayと同じく、追加や置き換えの記述が出来ます
    • 削除も可能です
  • RFC 6902 JSONPatch
    • リソースに対して json patchを当てる方法です。kustomizeでいう patchesJson6902
    • Strategi Merge Patchでは実現できない更新をしたいときに使います
      • 例えばarrayの一部要素を書き換えたいとか

matchで指定できるものって？

ここに詳しく書いてあります。
https://kyverno.io/docs/writing-policies/match-exclude/

リソースの名前やラベルでも対象を制限できますし、除外設定も行えます。

Validate Resources

新規・既存リソースが定義したポリシーを満たしているかを検査する機能です。

今回想定するシーンは「Podには必ずresources.requests/limitsを入れる。入れてない場合Podを生成しない」です。
まずその制限をするポリシーを書きます。

require-req-limit-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: all-containers-need-requests-and-limits
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: check-container-resources
    match:
      resources:
        kinds:
        - Pod
        namespaces:
        - test2
    validate:
      message: "All containers must have CPU and memory resource requests and limits defined."
      pattern:
        spec:
          containers:
          - name: "*"
            resources:
              limits:
                memory: "?*"
                cpu: "?*"
              requests:
                memory: "?*"
                cpu: "?*"

mutateのとき使ったDeploymentを適用してみます。
すると・・・

$ kubectl apply -f test.yaml
Error from server: error when creating "test.yaml": admission webhook "validate.kyverno.svc" denied the request:

resource Deployment/test2/test-deployment was blocked due to the following policies

all-containers-need-requests-and-limits:
  autogen-check-container-resources: 'validation error: All containers must have CPU
    and memory resource requests and limits defined. Rule autogen-check-container-resources
    failed at path /spec/template/spec/containers/0/resources/limits/'

# Podは作成されていない
$ kubectl -n test2 get pods
No resources found in test2 namespace.

ということで、やりたいことは実現できました。

疑問

spec.backgroundとは？

ここを true にすると、既存リソースに対してもポリシーのチェックを行うようになります。
https://kyverno.io/docs/writing-policies/background/

既存リソースがポリシー違反になった場合、既存リソースはそのままですが、
ClusterPolicyReport または PolicyReport というリソースが作成されます。

既存リソースがポリシー違反になった例
$ kubectl get policyreport -A
NAMESPACE   NAME            PASS   FAIL   WARN   ERROR   SKIP   AGE
test2       polr-ns-test2   0      1      0      0       0      67s

中身を見てみると、エラーになった理由が記載されています。

この spec.background はデフォルトはtrueで、mutateやgenerateには影響ない項目です。

spec.validationFailureActionで指定できるものは？

  • enforce
    • ポリシー違反の場合、新規リソースの場合は、そのリソースは作成されません
  • audit
    • ポリシー違反の場合、ClusterPolicyReport または PolicyReport というリソースが作成されます
    • ポリシー違反でもそのリソースは作成されます

その他便利機能

今回はさわってないですが、使いこなすときに便利そうな機能があったので紹介しておきます。

変数

リクエストされたリソースの情報を変数として使えます。
https://kyverno.io/docs/writing-policies/variables/

またConfigMapの情報も呼び出せます。
これはConfigMapで定義した値を元にValidationを行ったりすることができるというものです。
https://kyverno.io/docs/writing-policies/external-data-sources/

前提条件

match や exclude よりもさらに細かい条件指定を行いたい場合に
preconditions というものが使えます。
https://kyverno.io/docs/writing-policies/preconditions/

10
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
10
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?