cwielenb/CNCF-Dataset huggingface dataset:
Project: Velero (Runtime / Cloud Native Storage)
File: ark_server.md

title: "ark server" layout: docs Run the ark server Run the ark server ``` ark server [flags] ``` ``` -h, --help help for server --log-level the level at which to log. Valid values are debug, info, warning, error, fatal, panic. (default info) --metrics-address string the address to expose prometheus metrics (default ":8085") --plugin-dir string directory containing Ark plugins (default "/plugins") ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Back up and restore Kubernetes cluster resources.
Project: lxd (Runtime / Container Runtime)
File: network_integrations.md

(network-integrations)= ```{note} Network integrations are currently only available for the {ref}`network-ovn`. ``` Network integrations can be used to connect networks on the local Incus deployment to remote networks hosted on Incus or other platforms. At this time the only type of network integrations supported is OVN which makes use of OVN interconnection gateways to peer OVN networks together across multiple deployments. For this to work one needs a working OVN interconnection setup with: OVN interconnection `NorthBound` and `SouthBound` databases Two or more OVN clusters with their availability-zone names set properly (`name` property) All OVN clusters need to have the `ovn-ic` daemon running OVN clusters configured to advertise and learn routes from interconnection At least one server marked as an OVN interconnection gateway More details can be found in the . A network integration can be created with `incus network integration create`. Integrations are global to the Incus deployment, they are not tied to a network or project. An example for an OVN integration would be: ``` incus network integration create ovn-region ovn incus network integration set ovn-region ovn.northbound_connection tcp:[192.0.2.12]:6645,tcp:[192.0.3.13]:6645,tcp:[192.0.3.14]:6645 incus network integration set ovn-region ovn.southbound_connection tcp:[192.0.2.12]:6646,tcp:[192.0.3.13]:6646,tcp:[192.0.3.14]:6646 ``` To make use of a network integration, one needs to peer with it. This is done through `incus network peer create`, for example: ``` incus network peer create default region ovn-region --type=remote ``` The following configuration options are available for all network integrations: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group network_integration-common start --> :end-before: <!-- config group network_integration-common end --> ``` Those options are specific to the OVN network integrations: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group network_integration-ovn start --> :end-before: <!-- config group network_integration-ovn end --> ```
Project: Velero (Runtime / Cloud Native Storage)
File: feature-flags.md

Status: Accepted Some features may take a while to get fully implemented, and we don't necessarily want to have long-lived feature branches A simple feature flag implementation allows code to be merged into main, but not used unless a flag is set. Allow unfinished features to be present in Velero releases, but only enabled when the associated flag is set. A robust feature flag library. When considering the , the timelines involved presented a problem in balancing a release and longer-running feature work. A simple implementation of feature flags can help protect unfinished code while allowing the rest of the changes to ship. A new command line flag, `--features` will be added to the root `velero` command. `--features` will accept a comma-separated list of features, such as `--features EnableCSI,Replication`. Each feature listed will correspond to a key in a map in `pkg/features/features.go` defining whether a feature should be enabled. Any code implementing the feature would then import the map and look up the key's value. For the Velero client, a `features` key can be added to the `config.json` file for more convenient client invocations. A new `features` package will be introduced with these basic structs: ```go type FeatureFlagSet struct { flags map[string]bool } type Flags interface { // Enabled reports whether or not the specified flag is found. Enabled(name string) bool // Enable adds the specified flags to the list of enabled flags. Enable(names ...string) // All returns all enabled features All() []string } // NewFeatureFlagSet initializes and populates a new FeatureFlagSet func NewFeatureFlagSet(flags ...string) FeatureFlagSet ``` When parsing the `--features` flag, the entire `[]string` will be passed to `NewFeatureFlagSet`. Additional features can be added with the `Enable` function. Parsed features will be printed as an `Info` level message on server start up. No verification of features will be done in order to keep the implementation minimal. On the client side, `--features` and the `features` key in `config.json` file will be additive, resulting in the union of both. To disable a feature, the server must be stopped and restarted with a modified `--features` list. Similarly, the client process must be stopped and restarted without features. Omitted Omitted
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_vtep_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List VTEP CIDR and their corresponding VTEP MAC/IP List VTEP CIDR and their corresponding VTEP MAC/IP. ``` cilium-dbg bpf vtep list [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 ``` - Manage the VTEP mappings for IP/CIDR <-> VTEP MAC/IP
Project: lxd (Runtime / Container Runtime)
File: storage_dir.md

(storage-dir)= The directory storage driver is a basic backend that stores its data in a standard file and directory structure. This driver is quick to set up and allows inspecting the files directly on the disk, which can be convenient for testing. However, Incus operations are {ref}`not optimized <storage-drivers-features>` for this driver. The `dir` driver in Incus is fully functional and provides the same set of features as other drivers. However, it is much slower than all the other drivers because it must unpack images and do instant copies of instances, snapshots and images. Unless specified differently during creation (with the `source` configuration option), the data is stored in the `/var/lib/incus/storage-pools/` directory. (storage-dir-quotas)= <!-- Include start dir quotas --> The `dir` driver supports storage quotas when running on either ext4 or XFS with project quotas enabled at the file system level. <!-- Include end dir quotas --> The following configuration options are available for storage pools that use the `dir` driver and for storage volumes in these pools. Key | Type | Default | Description :-- | : | : | :- `rsync.bwlimit` | string | `0` (no limit) | The upper limit to be placed on the socket I/O when `rsync` must be used to transfer storage entities `rsync.compression` | bool | `true` | Whether to use compression while migrating storage pools `source` | string | - | Path to an existing directory {{volume_configuration}} Key | Type | Condition | Default | Description :-- | : | :-- | : | :- `security.shared` | bool | custom block volume | same as `volume.security.shared` or `false` | Enable sharing the volume across multiple instances `security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enableIDshifting}} `security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume `size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage volume `snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshotexpiryformat}} `snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshotpatternformat}} [^*] `snapshots.schedule` | string | custom volume | same as `volume.snapshots.schedule` | {{snapshotscheduleformat}} To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storagebucketsaddress` server setting. Storage buckets do not have any configuration for `dir` pools. Unlike the other storage pool drivers, the `dir` driver does not support bucket quotas via the `size` setting.
Project: Kilo (Runtime / Cloud Native Network)
File: multi-cluster-services.md

Just as Kilo can connect a Kubernetes cluster to external services over WireGuard, it can connect multiple independent Kubernetes clusters. This enables clusters to provide services to other clusters over a secure connection. For example, a cluster on AWS with access to GPUs could run a machine learning service that could be consumed by workloads running in a another location, e.g. an on-prem cluster without GPUs. Unlike services exposed via Ingresses or NodePort Services, multi-cluster services can remain private and internal to the clusters. Note: in order for connected clusters to be fully routable, the allowed IPs that they declare must be non-overlapping, i.e. the Kilo, pod, and service CIDRs. Consider two clusters, `cluster1` with: kubeconfig: `KUBECONFIG1`; and service CIDR: `$SERVICECIDR1` and `cluster2` with: kubeconfig: `KUBECONFIG2` service CIDR: `$SERVICECIDR2`; and In order to give `cluster2` access to a service running on `cluster1`, start by peering the nodes: ```shell for n in $(kubectl --kubeconfig $KUBECONFIG1 get no -o name | cut -d'/' -f2); do kgctl --kubeconfig $KUBECONFIG1 showconf node $n --as-peer -o yaml --allowed-ips $SERVICECIDR1 | kubectl --kubeconfig $KUBECONFIG2 apply -f - done for n in $(kubectl --kubeconfig $KUBECONFIG2 get no -o name | cut -d'/' -f2); do kgctl --kubeconfig $KUBECONFIG2 showconf node $n --as-peer -o yaml --allowed-ips $SERVICECIDR2 | kubectl --kubeconfig $KUBECONFIG1 apply -f - done ``` Now, Pods on `cluster1` can ping, cURL, or otherwise make requests against Pods and Services in `cluster2` and vice-versa. At this point, Kilo has created a fully routable network between the two clusters. However, as it stands the external Services can only be accessed by using their clusterIPs directly. For example, a Pod in `cluster2` would need to use the URL `http://$CLUSTERIPFROMCLUSTER1` to make an HTTP request against a Service running in `cluster1`. In other words, the Services are not yet Kubernetes-native. We can easily change that by creating a Kubernetes Service in `cluster2` to mirror the Service in `cluster1`: ```shell cat <<EOF | kubectl --kubeconfig $KUBECONFIG2 apply -f - apiVersion: v1 kind: Service metadata: name: important-service spec: ports: port: 80 apiVersion: v1 kind: Endpoints metadata: name: important-service subsets: addresses: ip: $(kubectl --kubeconfig $KUBECONFIG1 get service important-service -o jsonpath='{.spec.clusterIP}') # The cluster IP of the important service on cluster1. ports: port: 80 EOF ``` Now, `important-service` can be used and discovered on `cluster2` just like any other Kubernetes Service. That means that a Pod in `cluster2` could directly use the Kubernetes DNS name for the Service when making HTTP requests, for example: `http://important-service.default.svc.cluster.local`. Notice that this mirroring is ad-hoc, requiring manual administration of each Service. This process can be fully automated using to discover and mirror Kubernetes Services between connected clusters.
Project: JuiceFS (Runtime / Cloud Native Storage)
File: bug-report.md

name: Bug Report about: Report a bug encountered while operating JuiceFS labels: kind/bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! --> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know? Environment: JuiceFS version (use `juicefs --version`) or Hadoop Java SDK version: Cloud provider or hardware configuration running JuiceFS: OS (e.g `cat /etc/os-release`): Kernel (e.g. `uname -a`): Object storage (cloud provider and region, or self maintained): Metadata engine info (version, cloud provider managed or self maintained): Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage): Others:
Project: Kata Containers (Runtime / Container Runtime)
File: agent-systemd-cgroup.md

As we know, we can interact with cgroups in two ways, `cgroupfs` and `systemd`. The former is achieved by reading and writing cgroup `tmpfs` files under `/sys/fs/cgroup` while the latter is done by configuring a transient unit by requesting systemd. Kata agent uses `cgroupfs` by default, unless you pass the parameter `--systemd-cgroup`. For systemd, kata agent configures cgroups according to the following `linux.cgroupsPath` format standard provided by `runc` (`[slice]:[prefix]:[name]`). If you don't provide a valid `linux.cgroupsPath`, kata agent will treat it as `"system.slice:kata_agent:<container-id>"`. Here slice is a systemd slice under which the container is placed. If empty, it defaults to system.slice, except when cgroup v2 is used and rootless container is created, in which case it defaults to user.slice. Note that slice can contain dashes to denote a sub-slice (e.g. user-1000.slice is a correct notation, meaning a `subslice` of user.slice), but it must not contain slashes (e.g. user.slice/user-1000.slice is invalid). A slice of `-` represents a root slice. Next, prefix and name are used to compose the unit name, which is `<prefix>-<name>.scope`, unless name has `.slice` suffix, in which case prefix is ignored and the name is used as is. The kata agent will translate the parameters in the `linux.resources` of `config.json` into systemd unit properties, and send it to systemd for configuration. Since systemd supports limited properties, only the following parameters in `linux.resources` will be applied. We will simply treat hybrid mode as legacy mode by the way. CPU v1 | runtime spec resource | systemd property name | | | | | `cpu.shares` | `CPUShares` | v2 | runtime spec resource | systemd property name | | -- | -- | | `cpu.shares` | `CPUShares` | | `cpu.period` | `CPUQuotaPeriodUSec`(v242) | | `cpu.period` & `cpu.quota` | `CPUQuotaPerSecUSec` | MEMORY v1 | runtime spec resource | systemd property name | | | | | `memory.limit` | `MemoryLimit` | v2 | runtime spec resource | systemd property name | | | | | `memory.low` | `MemoryLow` | | `memory.max` | `MemoryMax` | | `memory.swap` & `memory.limit` | `MemorySwapMax` | PIDS | runtime spec resource | systemd property name | | | | | `pids.limit ` | `TasksMax` | CPUSET | runtime spec resource | systemd property name | | | -- | | `cpuset.cpus` | `AllowedCPUs`(v244) | | `cpuset.mems` | `AllowedMemoryNodes`(v244) | `session.rs` and `system.rs` in `src/agent/rustjail/src/cgroups/systemd/interface` are automatically generated by `zbus-xmlgen`, which is is an accompanying tool provided by `zbus` to generate Rust code from `D-Bus XML interface descriptions`. The specific commands to generate these two files are as follows: ```shell // system.rs zbus-xmlgen --system org.freedesktop.systemd1 /org/freedesktop/systemd1 // session.rs zbus-xmlgen --session org.freedesktop.systemd1 /org/freedesktop/systemd1 ``` The current implementation of `cgroups/systemd` uses `system.rs` while `session.rs` could be used to build rootless containers in the future.
Project: lxd (Runtime / Container Runtime)
File: cluster_groups.md

(howto-cluster-groups)= Cluster members can be assigned to {ref}`cluster-groups`. By default, all cluster members belong to the `default` group. To create a cluster group, use the command. For example: incus cluster group create gpu To assign a cluster member to one or more groups, use the command. This command removes the specified cluster member from all the cluster groups it currently is a member of and then adds it to the specified group or groups. For example, to assign `server1` to only the `gpu` group, use the following command: incus cluster group assign server1 gpu To assign `server1` to the `gpu` group and also keep it in the `default` group, use the following command: incus cluster group assign server1 default,gpu To add a cluster member to a specific group without removing it from other groups, use the command. For example, to add `server1` to the `gpu` group and also keep it in the `default` group, use the following command: incus cluster group add server1 gpu With cluster groups, you can target an instance to run on one of the members of the cluster group, instead of targeting it to run on a specific member. ```{note} {config:option}`cluster-cluster:scheduler.instance` must be set to either `all` (the default) or `group` to allow instances to be targeted to a cluster group. See {ref}`clustering-instance-placement` for more information. ``` To launch an instance on a member of a cluster group, follow the instructions in {ref}`cluster-target-instance`, but use the group name prefixed with `@` for the `--target` flag. For example: incus launch images:ubuntu/22.04 c1 --target=@gpu
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230517-set-recurring-job-to-pvc.md

Managing recurring jobs for Longhorn Volumes is challenging for users utilizing gitops. Primary because gitops operates at the Kubernetes resource level while recurring job labeling is specific to individual Longhorn Volumes. This document proposes the implementation of a solution that allows configuring recurring jobs directly on PVCs. By adopting this approach, users will have the capability to manage Volume recurring jobs through the PVCs. https://github.com/longhorn/longhorn/issues/5791 Introduce support for enabling/disabling PVCs as a recurring job label source for the corresponding Volume. The recurring job labels on PVCs are reflected on the associated Volume when the PVC is set as the recurring job label source. Sync Volume recurring job labels to PVC. The existing behavior of recurring jobs will remain unchanged, with the Volume's recurring job labeling as the source of truth. When the PVC is enabled as the recurring job label source, its recurring job labels will override all recurring job labels of the associated Volume. As a user, I want to be able to set the RecurringJob label on the PVC. I expect that any updates made to the RecurringJob labels on the PVC will automatically reflect on the associated Volume. To enable or disable the PVC as the recurring job label source, users can manage it by adding or removing the `recurring-job.longhorn.io/source: enable` label to the PVC. Once the PVC is set as the recurring job label source, any recurring job labels added or removed from the PVC will be automatically synchronized by Longhorn to the associated Volume. `None` If the PVC is labeled with `recurring-job.longhorn.io/source: enable`, the volume controller checks and updates the Volume to ensure the recurring job labels stay synchronized with the PVC by detecting recurring job label differences. As of now, Longhorn includes a feature that automatically removes the Volume recurring job label associated with a deleting RecurringJob. This is also applicable to the PVC. Update PVC recurring job label should reflect on the Volume. Delete RecurringJob custom resource should delete the recurring job labels on both Volume and PVC. `None` `None`
Project: Weave Net (Runtime / Cloud Native Network)
File: ip-addresses.md

title: IP Addresses, Routes and Networks menu_order: 40 search_type: Documentation Weave Net runs containers on a private network, which means that IP addresses are isolated from the rest of the Internet, and that you don't have to worry about addresses clashing. You can of course also manually change the IP of any given container or subnet on a Weave network. See, IP is the Internet Protocol, the fundamental basis of network communication between billions of connected devices. The IP address is (for most purposes) the four numbers separated by dots, like `192.168.48.12`. Each number is one byte in size, so can be between 0 and 255. Each IP address lives on a Network, which is some set of those addresses that all know how talk to each other. The network address is some prefix of the IP address, like `192.168.48`. To show which part of the address is the network, we append a slash and then the number of bits in the network prefix, like `/24`. A route is an instruction for how to deal with traffic destined for somewhere else - it specifies a Network, and a way to talk to that network. Every device using IP has a table of routes, so for any destination address it looks up that table, finds the right route, and sends it in the direction indicated. In the IP address `10.4.2.6/8`, the network prefix is the first 8 bits \- `10`. Written out in full, that network is `10.0.0.0/8`. The most common prefix lengths are 8, 16 and 24, but there is nothing stopping you using a /9 network or a /26. For example, `6.250.3.1/9` is on the `6.128.0.0/9` network. Several websites offer calculators to decode this kind of address, see, for example: . The following is an example route table for a container that is attached to a Weave network: default via 172.17.42.1 dev eth0 10.2.2.0/24 dev ethwe proto kernel scope link src 10.2.2.1 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.170 It has two interfaces: one that Docker gave it called `eth0`, and one that weave gave it called `ethwe`. They are on networks `172.17.0.0/16` and `10.2.2.0/24` respectively, and if you want to talk to any other address on those networks then the routing table tells it to send directly down that interface. If you want to talk to anything else not matching those rules, the default rule says to send it to `172.17.42.1` down the eth0 interface. So, suppose this container wants to talk to another container at address `10.2.2.9`; it will send down the ethwe interface and weave Net will take care of routing the traffic. To talk an external server at address `74.125.133.128`, it looks in its routing table, doesn't find a match, so uses the default rule. See Also
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_lb_maglev.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Maglev lookup table ``` -h, --help help for maglev ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Load-balancing configuration - Get Maglev lookup table for given service by ID - List Maglev lookup tables
Project: CRI-O (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`