* [docs] Remove ingress-nginx references in docs and scripts jinja
Signed-off-by: Meza <meza-xyz@proton.me>
* Remove ingress-nginx doc and remove references in readme and sidebar
Signed-off-by: Meza <meza-xyz@proton.me>
* Delete ingress-nginx dir from kubernetes-apps
Signed-off-by: Meza <meza-xyz@proton.me>
* Delete ingress-nginx from inventory addons
Signed-off-by: Meza <meza-xyz@proton.me>
* Delete ingress_nginx_enabled from default main
Signed-off-by: Meza <meza-xyz@proton.me>
* Delete ingress_nginx from download
Signed-off-by: Meza <meza-xyz@proton.me>
* Delete ingress_nginx from dependencies
Signed-off-by: Meza <meza-xyz@proton.me>
* Remove ingress_nginx from registry task
Signed-off-by: Meza <meza-xyz@proton.me>
---------
Signed-off-by: Meza <meza-xyz@proton.me>
Commit 5fb85dc added service permissions for etcd datastore mode,
but the same permissions are needed for KDD (Kubernetes datastore) mode.
Signed-off-by: Micke Nordin <kano@sunet.se>
When joining a control plane node and "upgrading" the cluster setup (for
example, to update etcd addresses after adding a new etcd) in the same
playbook run, the node can take a bit of time to become ready after
joining.
This triggers a kubeadm preflight check (ControlPlaneNodesReady) in
kubeadm upgrade, which is run directly after the join tasks.
Add a configurable wait for the control plane node to become Ready to
fix this race condition.
We currently **recursively** set the permissions of /etc/ssl/etcd/ssl
(default path) to 700. But this removes group permission from the files
under it, and certain composents (like calio with etcd datastore) rely
on it ; thus, the upgrade of a cluster can fail because the
calico-kube-controller can't access the certs, and thus the etcd.
This works in other case because as far as I can tell, the apiserver
which do access the etcd run as root (the owner of the files, not just
the "group owner")
We also for some reasons do this twice.
Only create the etcd cert directory with the correct permissions once,
not recursively.
The config.json.j2 template was generating invalid JSON when multiple
crio_registry_auth entries were defined, resulting in multiple top-level
"auths" objects being rendered, e.g.:
{
"auths": { "registry1": { "auth": "xxxx" } },
"auths": { "registry2": { "auth": "yyyy" } }
}
This change moves the loop inside the "auths" object so that all registries
are rendered as siblings under a single "auths" key, producing valid JSON:
{
"auths": {
"registry1": { "auth": "xxxx" },
"registry2": { "auth": "yyyy" }
}
}
Since we're not longer injecting pseudo DNS into /etc/hosts,
'lb-apiserver.kubernetes.local' (the previous default) won't resolve to
anything.
Instead, default to the loadbalancer IP if defined, or to the node local
loadbalancer if it's in use.
Make the necessary adjustements in use site to deal with ip addresses as
well as hostnames.
Only set `discard_unpacked_layers` in the CRI image config for containerd
versions earlier than 2.1.0.
Starting with containerd v2.1, the CRI plugin uses the Transfer Service for
image pulls by default. The `discard_unpacked_layers` option is incompatible
with the Transfer Service and triggers containerd to fall back to local
image pulls, logging a warning.
This change prevents unsupported configuration from being applied on newer
containerd versions, avoiding runtime warnings and ensuring default image
pull behavior.
Signed-off-by: Ali Afsharzadeh <afsharzadeh8@gmail.com>
- invoke setup module only once to gather ipv4 and ipv6 addresses
- eliminate remaining use of `fallback_ip` and `fallback_ip6`, allowing
us to define (with `set_fact` all the "computed" IPs variable in one
go, since there is no longer a dependency between them.
Before "5ca23e3bf (Changed to use first_kube_control_plane to parse
kubeadm_certificate_key (#11875), 2025-01-14)", kubespray would have
problem adding new control planes when the order of the nodes in kubectl
output and the ansible inventory were not the same.
But the underlying problem is that the operation is fundamentally
something that should be done only once, and recorded for all host in
play.
Since `register` and `sef_fact` when used with `run_once` set the
variable for all the hosts, use it. Also allows to use the variable
directly instead of relying on hostvars to make the task more readable.