If using IPv6 and a kubenet-style CNI (which is more common with
IPv6), we need to support an IPv6 route on the pod, or else Pods will
be unable to reach other Pods.
Co-authored-by: Ciprian Hacman <ciprian@hakman.dev>
Add cluster.Spec.Containerd.SELinuxEnabled field that enables SELinux in
containerd.
With SELinux enabled, all pods that use HostPath volumes must run with
SELinux label `spc_t`, otherwise SELinux denies the pods to touch the host
filesystem.
We want to be able to use "dns=none" (without peer-to-peer gossip)
even for clusters that have the k8s.local extension. These were
previously called "gossip clusters", but really that is an
implementation; what actually matters to users is that they don't rely
on writing records into a DNS zone (such as Route53).
This means that the object is not mutated after construction, making
it easier to do validity checks (such as whether we have mounted the
same path twice).
In order to verify that the caller is running on the specified node,
we source the expected IP address from the cloud, and require that the
node set up a simple challenge/response server to answer requests.
Because the challenge server runs on a port outside of the nodePort
range, this also makes it harder for pods to impersonate their host
nodes - though we do combine this with TPM and similar functionality
where it is available.
```
W0317 01:46:07.374788 27111 executor.go:139] error running task "Package/python2" (6m1s remaining to succeed): error installing package "python2": exit status 1: Last metadata expiration check: 0:14:55 ago on Fri Mar 17 01:31:12 2023.
No match for argument: python2
Error: Unable to find a match: python2
W0317 01:46:07.374820 27111 executor.go:139] error running task "Package/curl" (6m1s remaining to succeed): error installing package "curl": exit status 1: Last metadata expiration check: 0:14:55 ago on Fri Mar 17 01:31:12 2023.
Error:
Problem: problem with installed package curl-minimal-7.88.1-1.amzn2023.0.1.x86_64
- package curl-minimal-7.88.1-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.87.0-2.amzn2023.0.2.x86_64
- package curl-minimal-7.87.0-2.amzn2023.0.2.x86_64 conflicts with curl provided by curl-7.87.0-2.amzn2023.0.2.x86_64
- package curl-minimal-7.88.0-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.87.0-2.amzn2023.0.2.x86_64
- conflicting requests
- package curl-minimal-7.88.1-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.88.0-1.amzn2023.0.1.x86_64
- package curl-minimal-7.87.0-2.amzn2023.0.2.x86_64 conflicts with curl provided by curl-7.88.0-1.amzn2023.0.1.x86_64
- package curl-minimal-7.88.0-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.88.0-1.amzn2023.0.1.x86_64
- package curl-minimal-7.88.1-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.88.1-1.amzn2023.0.1.x86_64
- package curl-minimal-7.87.0-2.amzn2023.0.2.x86_64 conflicts with curl provided by curl-7.88.1-1.amzn2023.0.1.x86_64
- package curl-minimal-7.88.0-1.amzn2023.0.1.x86_64 conflicts with curl provided by curl-7.88.1-1.amzn2023.0.1.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
```
As of the NVIDIA Container Toolkit v1.6.0 release the nvidia-container-toolkit
is the top-level package for installing the NVIDIA container stack with the
nvidia-container-runtime provided as a meta-package to support "legacy"
workflows such as this.
This change installs the nvidia-container-toolkit package directly instead.
Note that the nvidia-container-runtime binary is included in this package.
See https://github.com/NVIDIA/nvidia-container-toolkit/releases/tag/v1.6.0
Signed-off-by: Evan Lezar <evanlezar@gmail.com>
The ubuntu20.04 and ubunut22.04 repositories are "mirrors" of the
ubuntu18.04 repository. This change ensures that the ubuntu18.04 repository
is used regardless of the Ubuntu distribution.
Signed-off-by: Evan Lezar <evanlezar@gmail.com>
If the non-masquerade CIDR is not set, take that as an indication that
we don't want masquerade, rather than failing nodeup.
Not setting a non-masquerade CIDR means that we likely won't preserve
pod IPs for pod-to-pod traffic, but likely just means that more
NATting is done than might be needed.
Omitting the value can also be useful if we're using something like
the ip-masq-agent to manage masquerade rules for us.
This means that we automatically check the error code. A linter could
detect errors here (maybe), but in practice we can't recover from
errors here anyway.
We're aiming to use this for testing immediately and better
logging/tracing in future, but to make the changes manageable breaking
them into a smaller series that don't directly achieve much.