Install crictl in Agent containers

[kate-goldenring]

What this PR does / why we need it:
Instead of requiring users to install crictl locally, this adds crictl directly to the Agent containers, removing the need to mount it from the host in the charts/templates.

Many users can forget to specify the path of crictl. fixes #6

Special notes for your reviewer:
The size of crictl locally is 28.5 MBs:

kagold@nuc-ubtunu1:~$ stat /usr/local/bin/crictl
  File: /usr/local/bin/crictl
  Size: 28488749        Blocks: 55648      IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 9440263     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-11-12 00:47:30.575087778 +0000
Modify: 2019-12-16 03:11:36.000000000 +0000
Change: 2021-10-04 21:26:57.523199337 +0000
 Birth: -

Similarly, adding crictl to the agent increases its size from 128MB to 161MB.

Associated documentation should be updated to match this PR.

We could also remove the need to set the container runtime path agent.host.dockerShimSock and instead have users specify their distro with something like kubernetesDistro.microk8s=true. Then the appropriate socket path will be set.

We also may want to consider using a more recent version of crictl and add updating it to our release cycle.

If applicable:

• this PR has an associated PR with documentation in akri-docs
• this PR contains unit tests
• added code adheres to standard Rust formatting (cargo fmt)
• code builds properly (cargo build)
• code is free of common mistakes (cargo clippy)
• all Akri tests succeed (cargo test)
• inline documentation builds (cargo doc)
• version has been updated appropriately (./version.sh)
• all commits pass the DCO bot check by being signed off -- see the failing DCO check for instructions on how to retroactively sign commits

[bfjelds]

is this a patch-level version change or a minor-level change?

[kate-goldenring]

@bfjelds what do you think about:

We could also remove the need to set the container runtime path agent.host.dockerShimSock and instead have users specify their distro with something like kubernetesDistro.microk8s=true. Then the appropriate socket path will be set.

I was thinking that it would make sense to do this in a subsequent PR so we only have to change our docs once. With just this PR, AKRI_HELM_CRICTL_CONFIGURATION should be changed to something like CRI_SOCKET but if we enable setting a K8s distro, it could be an added line of --set kubernetesDistro=<microk8s|k3s|k8s> or kubernetesDistro.<distro>=true

[bfjelds]

use same VERSION=... && curl $VERSION style here too?

[kate-goldenring]

good catch thanks! fixed dcb45dd

[bfjelds]

@bfjelds what do you think about:

We could also remove the need to set the container runtime path agent.host.dockerShimSock and instead have users specify their distro with something like kubernetesDistro.microk8s=true. Then the appropriate socket path will be set.

I was thinking that it would make sense to do this in a subsequent PR so we only have to change our docs once. With just this PR, AKRI_HELM_CRICTL_CONFIGURATION should be changed to something like CRI_SOCKET but if we enable setting a K8s distro, it could be an added line of --set kubernetesDistro=<microk8s|k3s|k8s> or kubernetesDistro.<distro>=true

how confident are we that we can get the right path based on distro? if we are really sure, then it sounds like a good idea. i suppose if someone was using some nonstandard-path, they wouldn't be able to use the helm charts directly anymore, but maybe that never happens?

[kate-goldenring]

@bfjelds what do you think about:

We could also remove the need to set the container runtime path agent.host.dockerShimSock and instead have users specify their distro with something like kubernetesDistro.microk8s=true. Then the appropriate socket path will be set.

I was thinking that it would make sense to do this in a subsequent PR so we only have to change our docs once. With just this PR, AKRI_HELM_CRICTL_CONFIGURATION should be changed to something like CRI_SOCKET but if we enable setting a K8s distro, it could be an added line of --set kubernetesDistro=<microk8s|k3s|k8s> or kubernetesDistro.<distro>=true

how confident are we that we can get the right path based on distro? if we are really sure, then it sounds like a good idea. i suppose if someone was using some nonstandard-path, they wouldn't be able to use the helm charts directly anymore, but maybe that never happens?

I think we could still enable someone to override the default. I'll put in a PR of what im thinking after this

[jiria]

Why did you pick 1.17? We had problems using older crictl against newer clusters.

[kate-goldenring]

This is the version we have been using in our e2e tests and documentation.

We also may want to consider using a more recent version of crictl and add updating it to our release cycle.

I think our next release we can consider moving to a newer version

[jiria]

Can we merge the two RUNs? Otherwise curl/ca-certs will be part of the akri layers and contribute to the overall size.

[kate-goldenring]

I condensed them in 75f8467 but it didn't decrease the size at all interestingly. Still 161 MB

[jiria]

Interesting. Do we know ca-certs and curl were not in the initial image to begin with or installed as dependencies of the other packages we are installing?

[kate-goldenring]

I am pretty sure they werent there because it would not install until i added them