Group items tagged

The Terraform Registry is the main directory of publicly available Terraform providers, and hosts providers for most major infrastructure platforms.

Dependency Lock File documents an additional HCL file that can be included with a configuration, which tells Terraform to always use a specific set of provider versions.

Terraform CLI finds and installs providers when initializing a working directory. It can automatically download providers from a Terraform registry, or load them from a local mirror or cache.

To save time and bandwidth, Terraform CLI supports an optional plugin cache. You can enable the cache using the plugin_cache_dir setting in the CLI configuration file.

you can use Terraform CLI to create a dependency lock file and commit it to version control along with your configuration.

On Linux, control groups are used to constrain resources that are allocated to processes.

Both kubelet and the underlying container runtime need to interface with control groups to enforce resource management for pods and containers and set resources such as cpu/memory requests and limits.

When the cgroupfs driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups.

When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager.

Two cgroup managers result in two views of the available and in-use resources in the system.

Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation. If the kubelet has created Pods using the semantics of one cgroup driver, changing the container runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox for such existing Pods. Restarting the kubelet may not solve such errors.

The approach to mitigate this instability is to use systemd as the cgroup driver for the kubelet and the container runtime when systemd is the selected init system.

Kubernetes 1.26 defaults to using v1 of the CRI API. If a container runtime does not support the v1 API, the kubelet falls back to using the (deprecated) v1alpha2 API instead.

Make sure that the br_netfilter module is loaded.

you should ensure net.bridge.bridge-nf-call-iptables is set to 1 in your sysctl config,

kubeadm will not install or manage kubelet or kubectl for you, so you will need to ensure they match the version of the Kubernetes control plane you want kubeadm to install for you.

one minor version skew between the kubelet and the control plane is supported, but the kubelet version may never exceed the API server version.

Both the container runtime and the kubelet have a property called "cgroup driver", which is important for the management of cgroups on Linux machines.

Ephemeral containers differ from other containers in that they lack guarantees for resources or execution, and they will never be automatically restarted, so they are not appropriate for building applications.

distroless images enable you to deploy minimal container images that reduce attack surface and exposure to bugs and vulnerabilities.

Container filesystems are visible to other containers in the pod through the /proc/$pid/root link. This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions.

If you return None, Errbot will not respond with any kind of message when executing the command.

a file that ends with the extension .plug and it is used by Errbot to identify and load plugins.

The key Module should point to a module that Python can find and import.

The key Name should be identical to the name you gave to the class in your plugin file

The presence of __init__.py indicates lib is a Python regular package.

the !status command,

In-use IP addresses

run one or two control plane instances per failure zone, scaling those instances vertically first and then scaling horizontally after reaching the point of falling returns to (vertical) scale.

Kubernetes nodes do not automatically steer traffic towards control-plane endpoints that are in the same failure zone

store Event objects in a separate dedicated etcd instance.

start and configure additional etcd instance

Kubernetes resource limits help to minimize the impact of memory leaks and other ways that pods and containers can impact on other components.

Addons' default limits are typically based on data collected from experience running each addon on small or medium Kubernetes clusters.

Many addons scale horizontally - you add capacity by running more pods

The VerticalPodAutoscaler can run in recommender mode to provide suggested figures for requests and limits.

Some addons run as one copy per node, controlled by a DaemonSet: for example, a node-level log aggregator.

VerticalPodAutoscaler is a custom resource that you can deploy into your cluster to help you manage resource requests and limits for pods.

The cluster autoscaler integrates with a number of cloud providers to help you run the right number of nodes for the level of resource demand in your cluster.

The addon resizer helps you in resizing the addons automatically as your cluster's scale changes.