cwielenb/CNCF-Dataset huggingface dataset:
Project: Kube-router (Runtime / Cloud Native Network)
File: tunnels.md

There are several situations in which kube-router will use tunnels in order to perform certain forms of overlay / underlay routing within the cluster. To accomplish this, kube-router makes use of overlay tunnels that are built into the Linux kernel and instrumented with iproute2. By default, kube-router enables the option `--enable-overlay` which will perform overlay networking based upon the `--overlay-type` setting (by default set to `subnet`). So out of the box, kube-router will create a tunnel for pod-to-pod traffic any time it comes across a kube-router enabled node that is not within the subnet of it's primary interface. Additionally, if `--overlay-type` is set to `full` kube-router will create an tunnel for all pod-to-pod traffic and attempt to transit any pod traffic in the cluster via an IPIP overlay network between nodes. Finally, kube-router also uses tunnels for DSR (). In this case, the inbound traffic is encapsulated in an IPIP packet by IPVS after it reaches the node and before it is set to the pod for processing. This allows the return IP address of the sender to be preserved at the pod level so that it can be sent directly back to the requestor (rather than being routed in a synchronous fashion). IPIP (IP in IP) - This is the default method of encapsulation that kube-router uses FoU (Foo over UDP) - This is an optional type of IPIP encapsulation that kube-router uses if the user enables it Specifically, kube-router uses GUE () in order to support both IPv4 and IPv6 FoU tunnels. This option can be enabled via the kube-router parameter `--overlay-encap=fou`. Optionally, the user can also specify a desired port for this traffic via the `--overlay-encap-port` parameter (by default set to `5555`). Unfortunately, Azure doesn't allow IPIP encapsulation on their network. So users that want to use an overlay network will need to enable `fou` support in order to deploy kube-router in an Azure environment. While it is possible to change a running cluster between `ipip` and `fou` type tunnels, administrators should beware that during the rollout it will cause pod-to-pod traffic to be dropped between nodes. Since, in almost all rollout scenarios, kube-router would be rolled out gracefully one pod or host to the next, during this rollout there will be mismatches between the encapsulation support between the two nodes as invariably one node will have an upgraded kube-router and another node may have a previous deployment. When this happens, they will have conflicting encapsulation setup on their tunnels and traffic will not be able to be sent between the two nodes until they are using a consistent encapsulation protocal between them. Once all nodes have upgraded with the destination configuration, pod-to-pod traffic patterns should return to normal.
Project: Kilo (Runtime / Cloud Native Network)
File: peer-validation.md

A can be used to avoid applying faulty Peer configurations to the cluster. A is a Kubernetes resource that can be used to dynamically specify a service (i.e. the webhook server) that should validate operations (e.g. `UPDATE`, `CREATE`, etc.) on a particular resource (e.g. Kilo Peers). Once such a configuration is applied, the Kubernetes API server will send an AdmissionReviewRequest to the webhook service every time the specified operations are applied to the resource of the specified type. With regard to the , the API server will apply the requested changes to a resource if the request was answered with `"allowed": true`, or deny the changes if the answer was `"allowed": false`. In case of Kilo Peer Validation, the specified operations are `UPDATE` and `CREATE`, the resources are `Peers`, and the default `failurePolicy` is set to `Fail`. View the full ValidatingWebhookConfiguration . Apply the Service, the Deployment of the actual webserver, and the ValidatingWebhookConfiguration with: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/blob/main/manifests/peer-validation.yaml ``` The Kubernetes API server will only talk to webhook servers via TLS so the Kilo-Peer-Validation server must be given a valid TLS certificate and key, and the API server must be told what certificate authority (CA) to trust. The above manifest will use to generate the requiered certificates and patch the .
Project: runc (Runtime / Container Runtime)
File: cgroup-v2.md

runc fully supports cgroup v2 (unified mode) since v1.0.0-rc93. To use cgroup v2, you might need to change the configuration of the host init system. The following distributions are known to use cgroup v2 by default: <!-- the list should be kept in sync with https://github.com/rootless-containers/rootlesscontaine.rs/blob/master/content/getting-started/common/cgroup2.md --> Fedora (since 31) Arch Linux (since April 2021) openSUSE Tumbleweed (since c. 2021) Debian GNU/Linux (since 11) Ubuntu (since 21.10) RHEL and RHEL-like distributions (since 9) On other systemd-based distros, cgroup v2 can be enabled by adding `systemd.unifiedcgrouphierarchy=1` to the kernel cmdline. Yes if `/sys/fs/cgroup/cgroup.controllers` is present. Recommended version: 5.2 or later Minimum version: 4.15 Kernel older than 5.2 is not recommended due to lack of freezer. Notably, kernel older than 4.15 MUST NOT be used (unless you are running containers with user namespaces), as it lacks support for controlling permissions of devices. On cgroup v2 hosts, it is highly recommended to run runc with the systemd cgroup driver (`runc --systemd-cgroup`), though not mandatory. The recommended systemd version is 244 or later. Older systemd does not support delegation of `cpuset` controller. Make sure you also have the `dbus-user-session` (Debian/Ubuntu) or `dbus-daemon` (CentOS/Fedora) package installed, and that `dbus` is running. On Debian-flavored distros, this can be accomplished like so: ```console $ sudo apt install -y dbus-user-session $ systemctl --user start dbus ``` On cgroup v2 hosts, rootless runc can talk to systemd to get cgroup permissions to be delegated. ```console $ runc spec --rootless $ jq '.linux.cgroupsPath="user.slice:runc:foo"' config.json | sponge config.json $ runc --systemd-cgroup run foo ``` The container processes are executed in a cgroup like `/user.slice/user-$(id -u).slice/user@$(id -u).service/user.slice/runc-foo.scope`. Typically, only `memory` and `pids` controllers are delegated to non-root users by default. ```console $ cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers memory pids ``` To allow delegation of other controllers, you need to change the systemd configuration as follows: ```console [Service] Delegate=cpu cpuset io memory pids EOF ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_nat_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List all NAT mapping entries ``` cilium-dbg bpf nat list [cluster <cluster id>] [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - NAT mapping tables
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-health_completion_bash.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for bash Generate the autocompletion script for the bash shell. This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager. To load completions in your current shell session: source <(cilium-health completion bash) To load completions for every new session, execute once: cilium-health completion bash > /etc/bash_completion.d/cilium-health cilium-health completion bash > $(brew --prefix)/etc/bash_completion.d/cilium-health You will need to start a new shell for this setup to take effect. ``` cilium-health completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ``` -D, --debug Enable debug messages -H, --host string URI to cilium-health server API --log-driver strings Logging endpoints to use for example syslog --log-opt map Log driver options for cilium-health e.g. syslog.level=info,syslog.facility=local5,syslog.tag=cilium-agent ``` - Generate the autocompletion script for the specified shell
Project: CubeFS (Runtime / Cloud Native Storage)
File: verify.md

::: tip Note If you have deployed the erasure coding module to create an erasure coding volume, please refer to the section. ::: `cfs-cli` reads config file `~/.cfs-cli.json`. Example `cfs-cli.json`: ```json { "masterAddr": [ "127.0.0.1:17010", "127.0.0.2:17010", "127.0.0.3:17010" ], "timeout": 60 } ``` ```bash ./build/bin/cfs-cli volume create ltptest ltptest ./build/bin/cfs-cli volume info ltptest ``` Prepare client config file. Example `client.conf`: ```json { "mountPoint": "/home/cfs/client/mnt", "volName": "ltptest", "owner": "ltptest", "masterAddr": "127.0.0.1:17010,127.0.0.2:17010,127.0.0.3:17010", "logDir": "/cfs/client/log", "logLevel": "info", "profPort": "27510" } ``` Note that `volName` and `owner` must match with the volume created by `cfs-cli`. Start the client ```bash ./build/bin/cfs-client -c /home/data/conf/client.conf ``` Check if the mount is successful `/home/cfs/client/mnt` is the mount point. If the output of the command `df -h` is similar to the following, the mount is successful. ```bash df -h Filesystem Size Used Avail Use% Mounted on udev 3.9G 0 3.9G 0% /dev tmpfs 796M 82M 714M 11% /run /dev/sda1 98G 48G 45G 52% / tmpfs 3.9G 11M 3.9G 1% /dev/shm cubefs-ltptest 10G 0 10G 0% /home/cfs/client/mnt ... ``` ::: tip Note The erasure coding subsystem (Blobstore) provides a separate interactive command-line management tool. Currently, this tool is not integrated into cfs-cli, and it will be integrated later. ::: The Blobstore CLI can easily manage the erasure coding subsystem. Use `help` to view the help information. Here, we only introduce how to verify the correctness of the erasure coding system itself. Based on the default configuration, start the command-line tool `cli`. For detailed usage, please refer to . Physical machine environment ``` bash $> cd ./cubefs $>./build/bin/blobstore/blobstore-cli -c blobstore/cli/cli/cli.conf # Start the command line with the default configuration ``` Docker environment ``` bash $> ./bin/blobstore-cli -c conf/blobstore-cli.conf ``` ``` bash $> access put -v -d "test -data-" {"clusterid":1,"codemode":10,"size":11,"blobsize":8388608,"crc":2359314771,"blobs":[{"minbid":1844899,"vid":158458,"count":1}]} $> access get -v -l '{"clusterid":1,"codemode":10,"size":11,"blobsize":8388608,"crc":2359314771,"blobs":[{"minbid":1844899,"vid":158458,"count":1}]}' $> access del -v -l '{"clusterid":1,"codemode":10,"size":11,"blobsize":8388608,"crc":2359314771,"blobs":[{"minbid":1844899,"vid":158458,"count":1}]}' ```
Project: CNI-Genie (Runtime / Cloud Native Network)
File: developer-guide.md

After making any modification to source files, below steps can be followed to build and use the new binary. Note that you should install genie first before making changes to the source. This ensures genie conf file is generated successfully. Please make sure to run the below commands with root privilege. Build genie binary by running: ``` make plugin ``` Place "genie" binary from dest/ into /opt/cni/bin/ directory. ``` cp dist/genie /opt/cni/bin/genie ``` A running kubernetes cluster is required to run the tests. To run ginkgo tests for CNI-Genie run the following command: If Kubernetes cluster is 1.7+ ``` make test testKubeVersion=1.7 testKubeConfig=/etc/kubernetes/admin.conf ``` If Kubernetes cluster is 1.5.x ``` make test testKubeVersion=1.5
Project: Kata Containers (Runtime / Container Runtime)
File: CpuAffinity.md

Name | Type | Description | Notes | - | - | - Vcpu | int32 | | HostCpus | []int32 | | `func NewCpuAffinity(vcpu int32, hostCpus []int32, ) *CpuAffinity` NewCpuAffinity instantiates a new CpuAffinity object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewCpuAffinityWithDefaults() *CpuAffinity` NewCpuAffinityWithDefaults instantiates a new CpuAffinity object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *CpuAffinity) GetVcpu() int32` GetVcpu returns the Vcpu field if non-nil, zero value otherwise. `func (o CpuAffinity) GetVcpuOk() (int32, bool)` GetVcpuOk returns a tuple with the Vcpu field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuAffinity) SetVcpu(v int32)` SetVcpu sets Vcpu field to given value. `func (o *CpuAffinity) GetHostCpus() []int32` GetHostCpus returns the HostCpus field if non-nil, zero value otherwise. `func (o CpuAffinity) GetHostCpusOk() ([]int32, bool)` GetHostCpusOk returns a tuple with the HostCpus field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuAffinity) SetHostCpus(v []int32)` SetHostCpus sets HostCpus field to given value.
Project: Cilium (Runtime / Cloud Native Network)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: 2-collect-information.md

Before performing the upgrade and removing the old deployment, collect information on the state of your cluster. This ensures the upgraded deployment will have a compatible configuration. This is the second step when migrating Piraeus Operator from version 1 (v1) to version 2 (v2). . To collect the necessary information for the migration, run the script provided at `docs/how-to/upgrade/collect-operator-v1-information.sh`. You can run the script either from a checked out repository, or directly from GitHub: ``` $ curl --proto '=https' --tlsv1.2 -sSf \ https://raw.githubusercontent.com/piraeusdatastore/piraeus-operator/v2/docs/how-to/upgrade/collect-operator-v1-information.sh \ | bash -s ``` The script will ask you if you want to keep modifications made with the deployed Piraeus Operator. For each modification, the script will show you the proposed change to the deployed resources and ask for confirmation. In addition, it will also inform you about values that cannot automatically be migrated, along with recommended actions should you need to keep the modification. The output looks like this: ``` Using kubectl context: kubernetes-admin@kubernetes Found LinstorControllers: ["piraeus-cs"] Found LinstorSatelliteSets: ["piraeus-ns"] Found LinstorCSIDrivers: ["piraeus"] Found additional environment variables passed to LINSTOR Controller Default resource +++ Updated resource @@ -143,6 +143,12 @@ kind: Deployment args: startController env: - name: FOO value: bar - name: EXAMPLE valueFrom: fieldRef: fieldPath: status.podIP name: JAVA_OPTS value: -Djdk.tls.acknowledgeCloseNotify=true name: K8SAWAITELECTION_ENABLED Apply the patch (Y/n)? y ... | After upgrading, apply the following resources. They have been saved to v2-resources.yaml | apiVersion: piraeus.io/v1 kind: LinstorCluster metadata: name: linstorcluster spec: linstorPassphraseSecret: piraeus-passphrase patches: [] ... ``` A copy of the identified resources is saved at `v2-resources.yaml`. Helm automatically generates a passphrase for LINSTOR. Once LINSTOR is initialized with the passphrase, the LINSTOR Controller will not be able fully start without supplying the passphrase. To migrate the generated passphrase to Piraeus Operator v2, create a backup of the secret: ``` $ kubectl get secrets piraeus-op-passphrase -ogo-template='{{.data.MASTER_PASSPHRASE}}{{"\n"}}' ZVRxanl1cVBscXV1ZTk1cmEwVTk5b0ptd0F4OGFmWlVPUVA0NWNnUw== ``` Save the generated passphrase for later use.
Project: containerd (Runtime / Container Runtime)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: lxd (Runtime / Container Runtime)
File: server_migrate_lxd.md

(server-migrate-lxd)= Incus includes a tool named `lxd-to-incus` which can be used to convert an existing LXD installation into an Incus one. For this to work properly, you should make sure to {doc}`install </installing>` the latest stable release of Incus but not initialize it. Instead, make sure that both `incus info` and `lxc info` both work properly, then run `lxd-to-incus` to migrate your data. This process transfers the entire database and all storage from LXD to Incus, resulting in an identical setup after the migration. ```{note} Following the migration, you will need to add any user that was in the `lxd` group into the equivalent `incus-admin` group. As group membership only updates on login, users may need to close their session and re-open it for it to take effect. ``` ```{note} Additionally, this process doesn't migrate the command line tool configuration. For this you may want to transfer the content of `~/.config/lxc/` or `~/snap/lxd/common/config/` over to `~/.config/incus/`. This is mostly useful to those who interact with other remote servers or have configured custom aliases. ``` ```{terminal} :input: lxd-to-incus :user: root => Looking for source server ==> Detected: snap package => Looking for target server => Connecting to source server => Connecting to the target server => Checking server versions ==> Source version: 5.19 ==> Target version: 0.1 => Validating version compatibility => Checking that the source server isn't empty => Checking that the target server is empty => Validating source server configuration The migration is now ready to proceed. At this point, the source server and all its instances will be stopped. Instances will come back online once the migration is complete. Proceed with the migration? [default=no]: yes => Stopping the source server => Stopping the target server => Wiping the target server => Migrating the data => Migrating database => Cleaning up target paths => Starting the target server => Checking the target server Uninstall the LXD package? [default=no]: yes => Uninstalling the source server ``` ```{terminal} :input: incus list :user: root To start your first container, try: incus launch images:ubuntu/22.04 Or for a virtual machine: incus launch images:ubuntu/22.04 --vm +++--+--+--+--+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +++--+--+--+--+ | u1 | RUNNING | 10.204.220.101 (eth0) | fd42:1eb6:f1d8:4e2a:216:3eff:fe65:940d (eth0) | CONTAINER | 0 | +++--+--+--+--+ ``` The tool will also look for any configuration that is incompatible with Incus and fail before any data is migrated. ```{warning} All instances will be stopped during the migration. Once the migration process is started, it cannot easily be reversed so make sure to plan adequate downtime. ```
Project: iSulad (Runtime / Container Runtime)
File: architecture.md

iSulad is an OCI-compliant container runtime engine that emphasizes simplicity, robustness, performance and lightweight. As a daemon process, it manages the entire container life cycle of the host system, including image transmission and storage, container execution and monitoring management, container resource management, and network management. iSulad provides Docker-like CLI for users. You can use Docker-like commands to manage container images and iSulad provides gRPC APIs which comply with the CRI standard for Kubernetes. iSulad is divided into different modules, and the modules are organized into subsystems. Understanding these modules, subsystems, and their relationships is important to modify and extend iSulad. This document describes the high-level system architecture design. For more information about each module, please refer to the relevant design documents. You can interact with the iSulad by invoking gRPC APIs exported by the subsystem. image service : Image management service, provides image-related operations, such as image download, query, and deletion. execution service: Container life cycle management service, provides container-related operations, such as container creation, startup, and deletion. networkThe network subsystem is responsible for network management capabilities of the pod of the CRI. When a pod is started, the pod is added to the network plane specified in the configuration file through the CNI interface. When a pod is stopped, the CNI API is used to remove the pod from the network plane where the pod is located and clear related network resources. image content : Managing Image Metadata and Container File Systems resource manage: Container resource management module, for example, setting available CPU and memory resource limits ExecutorRuntime for executing actual container operations. The LCR acts as the default runtime and can be extended through the plug-in mechanism. EventsContainer event collection module PluginsProvides the plugin mechanism to extend container capabilities through different plugins. HAThis module provides fault locating and garbage collection service. The figure shows the architecture: