Open jackzhao0711 opened 10 months ago
for your first question, the reason the apiVersion in second column is from the rules config to lists one or more API versions to match. if you view the full yaml output, you will find it refer https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-rules
for second question, there is no such automatic upgrade. firstly all existing persisted objects are accessible via the new APIs, however as the admissionregistration.k8s.io/v1beta1 API version of MutatingWebhookConfiguration is no longer served as of v1.22 also the below changes in admissionregistration.k8s.io/v1 , you need to update YAML spec files to the new API version and change accordingly. eg you may have to add webhooks[*].admissionReviewVersions
webhooks[].failurePolicy default changed from Ignore to Fail for v1 webhooks[].matchPolicy default changed from Exact to Equivalent for v1 webhooks[].timeoutSeconds default changed from 30s to 10s for v1 webhooks[].sideEffects default value is removed, and the field made required, and only None and NoneOnDryRun are permitted for v1 webhooks[].admissionReviewVersions default value is removed and the field made required for v1 (supported versions for AdmissionReview are v1 and v1beta1) webhooks[].name must be unique in the list for objects created via admissionregistration.k8s.io/v1
@KevinHuang40856 Thank you for your reply, since my cluster is created through CDK and these apis are automatically generated, how should I find and update these values?
cdk created cluster, but normally will not create MutatingWebhookConfiguration resources.
if you are using cdk8s to create the kubunetes resources , you will have a look at construct you are using.
if your cdk created cluster with old k8s version, you can make cdk to create/upgrade cluster with new version to get new api version.
@KevinHuang40856 Sorry, it took so long to reply to you. This problem has been solved, and the version will be automatically updated after upgrading directly.
Current EKS version:1.21 Purpose: Upgrade version to 1.22 EKS upgrade insights shows that there are deprecated api versions:
Check cluster:
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -A
Check details:
kubectl get MutatingWebhookConfiguration.v1beta1.admissionregistration.k8s.io "0500-amazon-eks-fargate-mutation.amazonaws.com" -o yaml | grep apiVersion
kubectl get MutatingWebhookConfiguration.v1.admissionregistration.k8s.io "0500-amazon-eks-fargate-mutation.amazonaws.com" -o yaml | grep apiVersion
The difference between the two: v1beta1 & v1
Question: 1、In the second picture, why does the first row show v1, but the second column shows v1beta1? 2、If I upgrade to v1.22, will v1beta1 in the first picture be automatically updated to v1? In the same way, will the second row in the second picture also be updated?
For "pod-identity-webhook", the phenomenon is the same as above.
kubectl get MutatingWebhookConfiguration.v1beta1.admissionregistration.k8s.io "pod-identity-webhook" -o yaml | grep apiVersion
kubectl get MutatingWebhookConfiguration.v1.admissionregistration.k8s.io "pod-identity-webhook" -o yaml | grep apiVersion
Guys, is there anything I need to do before upgrading?