vpa: admission-controller in CrashLoopBackOff

[sedflix]

Which component are you using?:
vertical-pod-autoscaler

What version of the component are you using?:
vpa version is 0.10.0
helm chart is derived from here and we are using version 1.1.0

Component version:

What k8s version are you using (kubectl version)?:

kubectl version Output

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.3", GitCommit:"816c97ab8cff8a1c72eccca1026f7820e93e0d25", GitTreeState:"clean", BuildDate:"2022-01-25T21:17:57Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.23) and server (1.21) exceeds the supported minor version skew of +/-1

What environment is this in?:

We are using EKS with Calico CNI. Due to this, our webhook can't run without host network. Hence, we use hostNetwork: true for "vpa-admission-controller" deployment. We have modified the deployment. The concerned areas are

     spec:
       containers:
       - command:
         - /admission-controller
         - --webhook-port=8897
         - --port=8895
         - --v=1000
        ports:
         - containerPort: 8897
           hostPort: 8897
           name: http
           protocol: TCP
         - containerPort: 8895
           hostPort: 8895
           name: metrics
           protocol: TCP

What did you expect to happen?:

admission-controller was supposed to bootup fine and work.

What happened instead?:

We are seeing the following logs in admission controllers.

I0221 08:26:50.294132       1 main.go:76] Vertical Pod Autoscaler 0.10.0 Admission Controller
I0221 08:26:50.294246       1 certs.go:40] Successfully read 1168 bytes from /etc/tls-certs/caCert.pem
I0221 08:26:50.294268       1 certs.go:40] Successfully read 1168 bytes from /etc/tls-certs/serverCert.pem
I0221 08:26:50.294291       1 certs.go:40] Successfully read 1675 bytes from /etc/tls-certs/serverKey.pem
I0221 08:26:50.594962       1 api.go:92] Initial VPA synced successfully
I0221 08:26:53.697126       1 fetcher.go:100] Initial sync of ReplicaSet completed
I0221 08:26:53.797296       1 fetcher.go:100] Initial sync of StatefulSet completed
I0221 08:26:53.897491       1 fetcher.go:100] Initial sync of ReplicationController completed
I0221 08:26:54.397659       1 fetcher.go:100] Initial sync of Job completed
I0221 08:26:54.497799       1 fetcher.go:100] Initial sync of CronJob completed
I0221 08:26:54.597941       1 fetcher.go:100] Initial sync of DaemonSet completed
I0221 08:26:55.498106       1 fetcher.go:100] Initial sync of Deployment completed
I0221 08:27:08.643268       1 config.go:117] Self registration as MutatingWebhook succeeded.

How to reproduce it (as minimally and precisely as possible):

One can try run admission-controller in the hostNetwork mode.

Anything else we need to know?:

Calico CNI can't be installed on the master node in EKS. There for the master node being able to communicate to webhook pod, we need to run them on host network mode.
I tried a combination 8 to 10 different port numbers.
I think things are failing @

autoscaler/vertical-pod-autoscaler/pkg/admission-controller/main.go

Line 139 in 2bb41d6

server.ListenAndServeTLS("", "")

Regardless of the root cause of the failure, we might need to improve the logging for admission-controller.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[yurissouza]

Hello @sedflix , have you manage to deploy the admissionController using another port?
What flags (port numbers) have you used to do so?