отключить автоматическое преобразование устаревших ресурсов
Я пытаюсь целенаправленно создать ресурсы 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-запроса/ответа.