Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Error while deploying kyverno on minikube #581

Closed
shubham-asati opened this issue Dec 30, 2019 · 5 comments
Closed

[BUG] Error while deploying kyverno on minikube #581

shubham-asati opened this issue Dec 30, 2019 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@shubham-asati
Copy link
Contributor

Describe the bug
I have tried installing kyverno using installation.md on minikube .But on deployment pod gets into error phase.
Logs from pod

  • init-container
    ERROR: logging before flag.Parse: I1227 14:20:57.721367 1 main.go:109] Using in-cluster configuration ERROR: logging before flag.Parse: I1227 14:20:57.722398 1 client.go:281] Starting registered resources sync: every 10000000000 seconds

  • kyverno container
    standard_init_linux.go:211: exec user process caused "no such file or directory"

minikube version: v1.6.2
vm-driver: virtualbox
Kubernetes version : v1.17.0
Docker version : 19.03.5

To Reproduce
Steps to reproduce the behavior:

  1. follow the minikube installation guide
  2. run kubectl apply command as given in kyverno installation guide
  3. Check pod status

Expected behavior
Successful installation

@shubham-asati shubham-asati added the bug Something isn't working label Dec 30, 2019
@shivdudhani shivdudhani self-assigned this Dec 30, 2019
@shivdudhani
Copy link
Contributor

init-container error is due to a missing flag.Parse() before using the arguments. Adding a init with flag arguments should fix it (nirmata@e6e5e3b)

@JimBugwadia JimBugwadia added this to the Kyverno Release 1.1.0 milestone Dec 30, 2019
@shivdudhani shivdudhani mentioned this issue Dec 30, 2019
@shivdudhani
Copy link
Contributor

The other error with kyverno_container is due to an incorrect target in CI script.

The binary is linked to C libs and the vanilla alpine image does not contain the clib and this is due to default go flags defined during build.

The PR #582 should fix the above issue:

The specific make targets for initContainer & kyverno container disable the CGO flags while building the binary. Updating the CI script to use the specific make targets should resolve this issue.

The default make targets make build & initContainer still use the users go environment, but the CI will disable the flags for the build.

@shubham-asati I have tested the above fix with the following setup, do confirm if the above fixes the reported issues for your setup.

Testing Environment:
minikube version:v1.6.2
vm-driver: hyperkit
Kubernetes version : v1.17.0
docker version: 19.03.5

@realshuting
Copy link
Member

I'm deploying the latest kyverno, seems like the pod falls in crashloopbackoff.
Images:

nirmata/kyverno                                          latest               9c36b66332da        2 hours ago         31MB
nirmata/kyvernopre                                       latest               3b4fc19d1c11        2 hours ago         27.4M

Logs:

  • container kyverno-pre:
I1230 21:00:04.689992       1 main.go:115] Using in-cluster configuration
I1230 21:00:04.691756       1 client.go:281] Starting registered resources sync: every 10000000000 seconds
  • container kyverno:
standard_init_linux.go:207: exec user process caused "no such file or directory"

@shivdudhani
Copy link
Contributor

there was a typo in make target command, fixed in nirmata@d0ab83a

@shubham-asati
Copy link
Contributor Author

The other error with kyverno_container is due to an incorrect target in CI script.

The binary is linked to C libs and the vanilla alpine image does not contain the clib and this is due to default go flags defined during build.

The PR #582 should fix the above issue:

The specific make targets for initContainer & kyverno container disable the CGO flags while building the binary. Updating the CI script to use the specific make targets should resolve this issue.

The default make targets make build & initContainer still use the users go environment, but the CI will disable the flags for the build.

@shubham-asati I have tested the above fix with the following setup, do confirm if the above fixes the reported issues for your setup.

Testing Environment:
minikube version:v1.6.2
vm-driver: hyperkit
Kubernetes version : v1.17.0
docker version: 19.03.5

@shivdudhani Thanks for the help . Both issues are fixed .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants