Deploy lockc as a DeamonSet #91
Conversation
This change makes lockc deployable on Kubernetes by simply doing kubectl apply -f contrib/kubernetes/lockc.yaml That way: * lockcd is deployed as a DaemonSet * lockc-runc-wrapper is installed on the host by the init container * a new component, lockc-k8s-agent, gets deployed as a DaemonSet and its purpose is to serve a small API via UNIX socket which lets lockc-runc-wrapper now what kind of policy should be applied for which k8s namespace Container images can be built with: ./scripts/container-build.sh or also pushed with: LOCKC_PUSH=true ./scripts/container-build.sh Signed-off-by: Michal Rostecki <[email protected]>
|
The issue I have with this PR are pods failing with: I've never seen this error before and when I was using the lockc-runc-wrapper as a default runtime. This occurs only when using lockc-runc-wrapper as a secondary runtime with Runtime Class. |
|
OK, same issuee appears when I'm putting lockc-runc-wrapper as the main runtime in containerd config (in ConfigMap). Weird. |
| hostPID: true | ||
| containers: | ||
| - name: lockcd | ||
| image: docker.io/vadorovsky/lockcd:latest |
There was a problem hiding this comment.
Don't use latest tag for Kubernetes deployments, it breaks RollingUpdate
| mountPath: /sys/fs/bpf | ||
| initContainers: | ||
| - name: install-lockc-runc-wrapper | ||
| image: docker.io/vadorovsky/lockc-runc-wrapper:latest |
There was a problem hiding this comment.
Don't use latest tag for Kubernetes deployments, it breaks RollingUpdate
| - name: containerd-config | ||
| mountPath: /config | ||
| - name: restart-containerd | ||
| image: busybox:latest |
There was a problem hiding this comment.
Don't use latest tag for Kubernetes deployments, it breaks RollingUpdate
| spec: | ||
| containers: | ||
| - name: lockc-k8s-agent | ||
| image: docker.io/vadorovsky/lockc-k8s-agent:latest |
There was a problem hiding this comment.
Don't use latest tag for Kubernetes deployments, it breaks RollingUpdate
| - kubectl wait --for=condition=Available deployment --timeout=2m -n cert-manager --all | ||
| - helm install -n kube-system kubewarden-crds kubewarden/kubewarden-crds | ||
| - helm install --wait -n kube-system kubewarden-controller kubewarden/kubewarden-controller | ||
| - kubectl apply -f /usr/local/src/lockc/contrib/kubernetes/lockc.yaml |
There was a problem hiding this comment.
we would like to have lockc installed also as Helm chart
| - helm install --wait -n kube-system kubewarden-controller kubewarden/kubewarden-controller | ||
| - kubectl apply -f /usr/local/src/lockc/contrib/kubernetes/lockc.yaml | ||
| - kubectl wait --for=condition=Available daemonset --timeout=2m -n lockcd --all | ||
| - kubectl apply -f /usr/local/src/lockc/contrib/kubernetes/kubewarden.yaml |
There was a problem hiding this comment.
This should be added to Kubewarden Helm chart
There was a problem hiding this comment.
Not really, it's our way of using kubewarden and our speficic policy. That file is about a policy which enforces usage of lockc-runc-wrapper RuntimeClass. Maybe I should change the name of that to be less misleading.
|
So my mentioned issue actually occurs also on |
|
Moved the content of this PR to #93 |
2 participants
This PR is not fully functional yet, just showing progress
This change makes lockc deployable on Kubernetes by simply doing
That way:
purpose is to serve a small API via UNIX socket which lets
lockc-runc-wrapper now what kind of policy should be applied for which
k8s namespace
Container images can be built with:
or also pushed with:
Signed-off-by: Michal Rostecki [email protected]