задний фон
При оркестровке Kubernetes мы используем синтаксис yaml для описания бизнес-ресурсов для IaC. Используем ли мы отдельный файл манифеста ресурсов или диаграммы helm, есть ли инструмент lint, как и другие языки, для синтаксиса yaml для определения синтаксиса? Чтобы предотвратить проблемы до их возникновения, можем ли мы обнаружить неправильную конфигурацию kubernetes заранее на этапе написания?Есть ли инструмент, который может определить, соответствует ли код лучшим практикам обнаружения kubernetes?
В то же время, когда преобладает DevOPS, в рабочем процессе GitOPS обнаружение синтаксических ошибок не ограничивается самим кодом, но также необходимо тестировать код конфигурации.В это время особенно важен инструмент обнаружения yaml.
Два введения в кубелинтер
В сообществе StackRox есть инструмент обнаружения yaml с открытым исходным кодом под названием KubeLinter, который помогает пользователям обнаруживать неправильные конфигурации в Kubernetes, позволяя разработчикам использовать простой метод для обнаружения файлов Kubernetes YAML и диаграмм HELM до их развертывания в кластере. с лучшими практиками, а также анализировать и отлаживать их.
Как только файл YAML будет предоставлен инструменту, он проведет встроенные проверки, а затем подробно сообщит обо всех ошибках и средствах их устранения. Лучшее в этом инструменте то, что его можно настраивать и расширять: встроенные проверки могут быть включены или отключены, и вы можете определить и использовать свои собственные пользовательские проверки.
Три установки и развертывания
3.1 Установка MacOS
brew install kube-linter
3.2 Установка Linux
Используйте бинарную установку, которую можно найти по адресуreleaseНайдите версию, которую хотите установить.
wget https://github.com/stackrox/kube-linter/releases/download/0.1.3/kube-linter-linux.tar.gz
tar -zxvf kube-linter-linux.tar.gz
mv kube-linter /usr/bin/
четыре использования
4.1 yaml, подлежащий обнаружению
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
resources:
requests:
memory: "64Mi"
cpu: "250m"
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
4.2 Выполнение теста
kube-linter lint pod.yaml
4.3 Просмотр результатов теста
pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in your container's securityContext.)
pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set your container's CPU requests and limits depending on its requirements. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ #requests-and-limits for more details.)
pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has memory limit 0 (check: unset-memory-requirements, remediation: Set your container's memory requests and limits depending on its requirements. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ #requests-and-limits for more details.)
Error: found 3 lint errors
Как видите, в файле YAML были обнаружены ошибки, каждая из которых имеет четкие шаги по исправлению.
4.4 Тип обнаружения просмотра
Если вы хотите взглянуть на встроенные проверки, вы можетеhttps://github.com/stackrox/kube-linter/blob/main/docs/genic/checks.mdВсе эти проверки перечислены в , или вы также можете просмотреть список с помощью KubeLinter:
4.5 Игнорировать обнаружение
Вы можете использовать следующие аннотации, чтобы игнорировать определенные проверки для файлов YAML или группы проверок по мере необходимости:
ignore-check.kube-linter.io/<check-name>
# 例如：
ignore-check.kube-linter.io/unset-cpu-requirements
Вы можете добавить правила проверки игнорирования в приведенный выше пример файла развертывания следующим образом:
metadata:
name: portainer
namespace: portainer
labels:
io.portainer.kubernetes.application.stack: portainer
app.kubernetes.io/name: portainer
app.kubernetes.io/instance: portainer
app.kubernetes.io/version: "2.0.0"
annotations:
ignore-check.kube-linter.io/unset-cpu-requirements : "cpu requirements not required"
Теперь, когда вы снова запустите kube-linter lint deploy.yaml, вы не должны увидеть ошибок, связанных с требованиями к ЦП.
4.6 Использование игнорирования конфигурации
KubeLinter также можно запустить с конфигурацией, в которой вы можете предоставить всю информацию об инструментах для включения/исключения. Вот пример конфигурации из репозитория:
# customChecks defines custom checks.
customChecks:
- name: "required-label-app"
template: "required-label"
params:
key: "app"
checks:
# if doNotAutoAddDefaults is true, default checks are not automatically added.
doNotAutoAddDefaults: false
# addAllBuiltIn, if set, adds all built-in checks. This allows users to
# explicitly opt-out of checks that are not relevant using Exclude.
# Takes precedence over doNotAutoAddDefaults, if both are set.
addAllBuiltIn: false
# include explicitly adds checks, by name. You can reference any of the built-in checks.
# Note that customChecks defined above are included automatically.
include:
- "required-label-owner"
# exclude explicitly excludes checks, by name. exclude has the highest priority: if a check is
# in exclude, then it is not considered, even if it is in include as well.
exclude:
- "privileged"
если ты побежишьkubelinter --config config lint deploy.yaml, где config такой же, как в приведенном выше файле конфигурации, и вы должны увидеть добавленную галочку для необходимой метки:
deploy.yaml: (object: portainer/portainer apps/v1, Kind=Deployment) no label matching "owner=<any>" found (check: required-label-owner, remediation: Add an email annotation to your object with information about the object's owner.)
KubeLinter, встроенный в конвейер CI, может оказаться очень полезным инструментом. Файлы оркестрации, отправленные в репозиторий, можно проверить и проверить на соответствие рекомендациям и соображениям безопасности, а при обнаружении проблем генерируются предупреждения.
5. Интеграция в DevOPS
Очень удобно интегрировать kubelinter в процесс CI, который можно использовать для обнаружения kubernetes до того, как фактическое приложение будет развернуто в среде.
Таким образом, приложения, развернутые в кластере, могут быть проверены на готовность к работе. Проект находится в альфа-версии, но ожидается, что он будет служить инструментом интеграции CI для проверки всех развертываний перед фактическим развертыванием в рабочей среде.
Шесть отражений
Ежедневно готовится в тестовом бизнесе. Можно использовать файл манифеста ресурсов Kubernetes.--dry-runЧтобы определить, является ли это передовой практикой kubernetes, вы можете использовать kube-linter, чтобы определить, установлен ли он локально в открытой среде или интегрирован в DevOPS, и он может вовремя обнаружить и оптимизировать файл манифеста ресурса.