отключить автоматическое преобразование устаревших ресурсов
Я пытаюсь целенаправленно создать ресурсы K8S с устаревшим для тестовых целей, но в конечном итоге получаю преобразованный ресурс в неустаревший . Я не понимаю, почему это происходит, и не могу найти обсуждения/темы о том, как заставить API K8S уважать мой манифест ресурса.
Кто-нибудь знает, как это можно сделать? Или даже почему он так себя ведет?
Вот ресурс, который я пытаюсь создать:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: deprecated-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
serviceName: test
servicePort: 80
Я пытался создать этот ресурс на нескольких кластерах следующих версий:
- 1.16
- 1.21
- 1.23
Для каждого кластера я использовал соответствующийkubectl
версия. Это показатель того, что «конверсия» не происходит на стороне клиента.
Это созданный ресурс в кластере, как вы можете видеть,apiVersion
не такой же…
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.k8s.io/v1beta1","kind":"Ingress","metadata":{"annotations":{},"name":"deprecated-ingress","namespace":"test1"},"spec":{"rules":[{"host":"example.com","http":{"paths":[{"backen
d":{"serviceName":"test","servicePort":80},"path":"/*","pathType":"ImplementationSpecific"}]}}]}}
creationTimestamp: "2022-06-02T12:06:04Z"
finalizers:
- networking.gke.io/ingress-finalizer-V2
generation: 1
managedFields:
- apiVersion: networking.k8s.io/v1beta1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:finalizers:
.: {}
v:"networking.gke.io/ingress-finalizer-V2": {}
manager: glbc
operation: Update
time: "2022-06-02T12:06:04Z"
- apiVersion: networking.k8s.io/v1beta1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/last-applied-configuration: {}
f:spec:
f:rules: {}
manager: kubectl
operation: Update
time: "2022-06-02T12:06:04Z"
name: deprecated-ingress
namespace: test1
resourceVersion: "489457660"
selfLink: /apis/networking.k8s.io/v1/namespaces/test1/ingresses/deprecated-ingress
uid: c8c80e6f-3e72-45b7-aca7-d17ab4a49f19
spec:
rules:
- host: example.com
http:
paths:
- backend:
service:
name: test
port:
number: 80
path: /*
pathType: ImplementationSpecific
status:
loadBalancer: {}
Я также пробовал использовать CronJob и версиюbatch/v1beta1
и я закончил сbatch/v1
версия.
1 ответ
Когда вы используете API Kubernetes для отправки объекта на сервер API, вы можете получить доступ к этому ресурсу, используя любую версию того же API, которую ваш кластер знает, как обслуживать.
Это часть того, как работает управление версиями API Kubernetes . Если вы отправите Ingress вhttps://cluster.example/apis/networking.k8s.io/v1beta1/namespaces/example/ingresses
тогда ваш запрос рассматривается как использование входного APIv1beta1, и затем вы можете прочитать этот объект обратно, используя GET дляhttps://cluster.example/apis/networking.k8s.io/v1/namespaces/example/ingresses/deprecated-ingress
Клиент выбирает , какой API использовать. Попробуйте запуститьkubectl get ingresses.v1beta1.networking.k8s.io deprecated-ingress
и вы можете прочитать этот объект обратно через APIv1beta1. Если вы используете клиент, который неkubectl
, проверьте, какой механизм предоставляет ваш клиент для выбора запрашиваемой версии API.
Существует также деталь реализации, которая описывает, как этот объект сериализуется в etcd. Если вы не уверены, что это важно для вас, игнорируйте то, как выглядят сериализованные данные, и полагайтесь на способность Kubernetes автоматически преобразовывать объекты в любую стабильную версию API, независимо от того, как они хранятся.
Кстати: если вы создадите CustomResourceDefinitions, преобразование не будет автоматическим. Предполагается, что вы реализуете свой собственный код преобразования и настроите CustomResourceDefinition для вызова его по мере необходимости в виде RPC HTTP-запроса/ответа.