Почему Kubernetes REST API обязателен?
Обновлено: Как упоминалось в ответе Джонаса, Kubernetes REST API можно рассматривать как декларативный, а не императивный.
Kubernetes хорошо известен своей декларативной моделью. Контроллер наблюдает за объектами в ETCD, которые содержат желаемое состояние (декларативное). Он сравнивает его с текущим состоянием и генерирует императивные команды для императивного API Kubernetes.
По каким причинам проект Kubernetes не предоставляет декларативный HTTP API?
Таким образом, пусть контроллер/оператор выполняет согласование.
Примером декларативного REST API, который я нашел, является F5 AS3 . И я думаю, что их оператор Kubernetes, построенный поверх этого декларативного API, довольно прост.
Ответы 1
API Kubernetes можно использовать как декларативно, так и императивно. Для быстрой разработки императивный рабочий процесс может работать лучше, тогда как для прослеживаемости и рабочей нагрузки рекомендуется декларативный рабочий процесс.
Пример декларативного HTTP с использованием curl
Для этого сначала нужно запустить kubectl proxy.
curl -X POST -H 'Content-Type: application/yaml' --data '
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-example
spec:
replicas: 3
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
' http://127.0.0.1:8001/apis/apps/v1/namespaces/default/deployments
API Kubernetes является декларативным в том смысле, что вы всегда указываете, что хотите, например. replicas: 2 вместо, например. create 2 replicas это будет иметь место в императивном API. Затем контроллеры «приводят» состояние к тому, «что» вы указали в цикле согласования.
Видеть:
- Декларативное управление объектами Kubernetes с помощью файлов конфигурации
- Императивное управление объектами Kubernetes с помощью файлов конфигурации
- Управление объектами Kubernetes с помощью императивных команд
Из вашей ссылки:
Расширение Application Services 3 использует декларативную модель, то есть вы отправляете файл объявления с помощью одного вызова Rest API.
Kubernetes API работает точно так же, когда вы применяете файлы yaml-manifest, используя, например, kubectl apply -f deployment.yaml
kubectl — это просто http-клиент. HTTP API является декларативным.
На самом деле я был удивлен, увидев, что это необходимо.
Не уверен, что повторю этот запрос дважды $ curl -H 'content-type: application/json' -X POST http://localhost:8080/api/v1/namespaces/testapi/pods -d '{"kind":"Pod","apiVersion":"v1","metadata":{"name":"nginx-via-api","labels":{"run":"nginx"}},"spec":{"containers":[{"name":"nginx","image":"nginx"}],"restartPolicy":"Never"}}' | jq .code => 409. Я получил 409. Если бы API был декларативным, он бы не возвращал 409 и не обновлял объект, если в каком-то поле было изменение, или ничего не делал, если тот же объект (идемпотентность)? wdyt
для обновления вам нужно использовать PUT и вы можете запускать его много раз, это идемпотент. Вы можете создать ресурс с уникальным именем только один раз, это не является отказом сделать это дважды, но вы получите сообщение об этом.
также смотрите developer.mozilla.org/en-US/docs/Glossary/Idempotent
Очень ясно, поймите, почему Kubernetes API является декларативным!
Я понимаю, что инструмент Kubectl допускает как декларативный, так и императивный подход, но почему HTTP API (вызываемый Kubectl или контроллерами) является обязательным. Могло ли оно быть декларативным? в чем причина? я что-то упускаю