Возможно ли иметь кластер Kubernetes с привилегированными модулями по умолчанию?

Question

Я создаю модуль через KubernetesPodOperator в Airflow.Этот модуль должен подключить Google Cloud Storage к /mnt/bucket с использованием gcsfuse.Для этого модуль необходимо запустить с параметром securityContext, чтобы он мог стать «привилегированным».

В настоящее время невозможно передать параметр securityContext через Airflow,Есть ли другой способ обойти это?Возможно, установив securityContext по умолчанию до того, как модули будут запущены?Я смотрел на создание PodSecurityPolicy, но не смог найти способ.

Answer 1

Отдельно от Mutating Admission Controller, также возможно развернуть DaemonSet в вашем кластере, который монтирует /mnt/bucket на файловую систему хоста, а модули Airflow будут использовать {"name": "bucket", "hostPath": {"path": "/mnt/bucket"}} в качестве volume:, что при условииэто работает - будет загрузка лодки меньше печатать, а также не подвергнет очень серьезный риск того, что Mutating Admission Controller блокирует ваш кластер и вызывает загадочную мутацию Pod'ов

Answer 2

Мутантный контроллер доступа позволит вам сделать это: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook

У команды ibm-cloud есть сообщение об этом, но я никогда не пытался написать его: https://medium.com/ibm-cloud/diving-into-kubernetes-mutatingadmissionwebhook-6ef3c5695f74 иу ребят из GiantSwarm есть сквозной пример использования контроллера доступа Grumpy: https://docs.giantswarm.io/guides/creating-your-own-admission-controller/

Я бы использовал метки, аннотации или, возможно, даже изображение, чтобы идентифицировать блоки, запущенные Airflow, изатем измените только их, чтобы установить securityContext: на стручках так, как вы хотите.