cwielenb/CNCF-Dataset huggingface dataset:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_build-config.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Resolve all of the configuration sources that apply to this node ``` cilium-dbg build-config --node-name $K8SNODENAME [flags] ``` ``` --allow-config-keys strings List of configuration keys that are allowed to be overridden (e.g. set from not the first source. Takes precedence over deny-config-keys --deny-config-keys strings List of configuration keys that are not allowed to be overridden (e.g. set from not the first source. If allow-config-keys is set, this field is ignored --dest string Destination directory to write the fully-resolved configuration. (default "/tmp/cilium/config-map") --enable-k8s Enable the k8s clientset (default true) --enable-k8s-api-discovery Enable discovery of Kubernetes API groups and resources with the discovery API -h, --help help for build-config --k8s-api-server string Kubernetes API server URL --k8s-client-burst int Burst value allowed for the K8s client --k8s-client-qps float32 Queries per second limit for the K8s client --k8s-heartbeat-timeout duration Configures the timeout for api-server heartbeat, set to 0 to disable (default 30s) --k8s-kubeconfig-path string Absolute path of the kubernetes kubeconfig file --node-name string The name of the node on which we are running. Also set via K8SNODENAME environment. --source strings Ordered list of configuration sources. Supported values: config-map:<namespace>/name - a ConfigMap with <name>, optionally in namespace <namespace>. cilium-node-config:<NAMESPACE> - any CiliumNodeConfigs in namespace <NAMESPACE>. node:<NODENAME> - Annotations on the node. Namespace and nodename are optional (default [config-map:cilium-config,cilium-node-config:]) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI
Project: lxd (Runtime / Container Runtime)
File: containers_and_vms.md

(containers-and-vms)= Incus provides support for two different types of {ref}`instances <expl-instances>`: system containers and virtual machines. Incus uses features of the Linux kernel (such as `namespaces` and `cgroups`) in the implementation of system containers. These features provide a software-only way to isolate and restrict a running system container. A system container can only be based on the Linux kernel. When running a virtual machine, Incus uses hardware features of the the host system as a way to isolate and restrict a running virtual machine. Therefore, virtual machines can be used to run, for example, different operating systems than the host system. | Virtual Machines | Application Containers | System Containers | | :--: | :--: | :--: | | Uses a dedicated kernel | Uses the kernel of the host | Uses the kernel of the host | | Can host different types of OS | Can only host Linux | Can only host Linux | | Uses more resources | Uses less resources | Uses less resources | | Requires hardware virtualization | Software-only | Software-only | | Can host multiple applications | Can host a single app | Can host multiple applications | | Supported by Incus | Supported by Docker | Supported by Incus | Application containers (as provided by, for example, Docker) package a single process or application. System containers, on the other hand, simulate a full operating system similar to what you would be running on a host or in a virtual machine. You can run Docker in an Incus system container, but you would not run Incus in a Docker application container. Therefore, application containers are suitable to provide separate components, while system containers provide a full solution of libraries, applications, databases and so on. In addition, you can use system containers to create different user spaces and isolate all processes belonging to each user space, which is not what application containers are intended for. Virtual machines create a virtual version of a physical machine, using hardware features of the host system. The boundaries between the host system and virtual machines is enforced by those hardware features. System containers, on the other hand, use the already running OS kernel of the host system instead of launching their own kernel. If you run several system containers, they all share the same kernel, which makes them faster and more lightweight than virtual machines. With Incus, you can create both system containers and virtual machines. You should use a system container to leverage the smaller size and increased performance if all functionality you require is compatible with the kernel of your host operating system. If you need functionality that is not supported by the OS kernel of your host system or you want to run a completely different OS, use a virtual machine.
Project: runc (Runtime / Container Runtime)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2014 Brian Goff Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: containerd (Runtime / Container Runtime)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-aws_completion_bash.md

<!-- This file was autogenerated via cilium-operator --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-operator-aws completion bash) To load completions for every new session, execute once: cilium-operator-aws completion bash > /etc/bash_completion.d/cilium-operator-aws cilium-operator-aws completion bash > $(brew --prefix)/etc/bash_completion.d/cilium-operator-aws You will need to start a new shell for this setup to take effect. ``` cilium-operator-aws completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: OpenEBS (Runtime / Cloud Native Storage)
File: CONTRIBUTING-TO-K8S-DEMO.md

This document describes the process for adding or improving the existing examples of applications using OpenEBS Volumes. Each application example should comprise of the following: K8s YAML file(s) for starting the application and its associated components. The volumes should point to the OpenEBS Storage Class. If the existing storage-classes do not suit the need, you may create a new storage class. Refer to our for examples. K8s YAML file(s) for starting a client that accesses the application. This is optional, in case the application itself provides a mechanism like in Jupyter, Wordpress, etc. When demonstrating a database-like application like Apache Cassandra, Redis, and so on, it is recommended to have such a mechanism to test that the application has been launched. An instruction guide, that will help in launch and verification of the application. At a very high level, the process to contribute and improve is pretty simple: Submit an Issue describing your proposed change. Or pick an existing issue tagged as . Create your development branch. Commit your changes. Submit your Pull Request. Submit an issue to update the User Documentation. *Note: You could also help by just adding new issues for applications that are currently missing in the examples or by raising issues on existing applications for further enhancements.* The following sections describe some guidelines that are helpful with the above process. Following the guidelines, here is a with frequently used git commands. Some general guidelines when submitting issues for example applications: If the proposed change requires an update to the existing example, please provide a link to the example in the issue. Fork the openebs repository and if you had previously forked, rebase with master to fetch latest changes. Create a new development branch in your forked repository with the following naming convention: "task description-#issue" Example: OpenEBS-Support-Kafka-Application-#538 Reference the issue number along with a brief description in your commits. Set your commit.template to the `COMMIT_TEMPLATE` given in the `.github` directory. `git config --local commit.template $GOPATH/src/github.com/openebs/openebs/.github` Rebase your development branch. Submit the PR from the development branch to the openebs/openebs:master Incorporate review comments, if any, in the development branch. Once the PR is accepted, close the branch. After the PR is merged the development branch in the forked repository can be deleted. If you need any help with git, refer to this and go back to the guide to proceed.
Project: Singularity (Runtime / Container Runtime)
File: PULL_REQUEST_TEMPLATE.md

Write your description of the PR here. Be sure to include as much background, and details necessary for the reviewers to understand exactly what this is fixing or enhancing. Fixes # Read the , and this PR conforms to the stated requirements. Added changes to the if necessary according to the Added tests to validate this PR, linted with `make check` and tested this PR locally with a `make test`, and `make testall` if possible (see CONTRIBUTING.md). Based this PR against the appropriate branch according to the Added myself as a contributor to the
Project: Carina (Runtime / Cloud Native Storage)
File: bug-report.md

name: Bug Report about: Create a report to help us improve this project <!-- 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: Anything else we need to know?: Environment: CSI Driver version: Kubernetes version (use `kubectl version`): OS (e.g. from /etc/os-release): Kernel (e.g. `uname -a`): Install tools: Others:
Project: Curve (Runtime / Cloud Native Storage)
File: HOWTO.md

`curvefs.py` and `curvefs_wrap.cxx` are generated by command `swig -c++ -python curvefs.i`. Revert `ListDir` and Delete `Opendir`/`Closedir` functions in `curvefs.py` if you don intend to make changes about these functions. Revert `wrapRead`/`wrapListdir`/`wrapGetClusterId`/`wrapCBDClientRead`/`wrapCBDClientListdir` if you don intend to make changes about these functions. :exclamation: C functions in `libcurvefs.h` are not recommended for use anymore. :exclamation: Types in `curve_type.h` are different from `include/client/*.h` even they have the similar name.
Project: Weave Net (Runtime / Cloud Native Network)
File: fastdp-how-it-works.md

title: Fast Datapath & Weave Net menu_order: 30 search_type: Documentation Weave Net implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed. The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel: The fast datapath in Weave Net uses the Linux kernel's . This module enables the Weave Net router to tell the kernel how to process packets: Because Weave Net issues instructions directly to the kernel, context switches are decreased, and so by using `fast datapath` CPU overhead and latency is reduced. The packet goes straight from your application to the kernel, where the Virtual Extensible Lan (VXLAN) header is added (the NIC does this if it offers VXLAN acceleration). VXLAN is an IETF standard UDP-based tunneling protocol that enable you to use common networking tools like to inspect the tunneled packets. Prior to version 1.2, Weave Net used a custom encapsulation format. Fast datapath uses VXLAN, and like Weave Net's custom encapsulation format, VXLAN is UDP-based, and therefore needs no special configuration with network infrastructure. Note: The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path. See Also *
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: RELEASE.md

The `klog` 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: Velero (Runtime / Cloud Native Storage)
File: 01-amazon-web-services.md

title: Amazon Web Services (AWS) link: https://github.com/vmware-tanzu/velero-plugin-for-aws objectStorage: true volumesnapshotter: true supportedByVeleroTeam: true This repository contains an object store plugin and a volume snapshotter plugin to support running Velero on Amazon Web Services.
Project: gVisor (Runtime / Container Runtime)
File: docker-in-gke-sandbox.md

Docker is a platform designed to help developers build, share, and run container applications. In gVisor, all basic docker commands should function as expected. However, it's important to note that, currently, only the host network driver is supported. This means that both 'docker run' and 'docker build' commands must be executed with the `--network=host` option. First, install a GKE cluster (1.29.0 or higher) and deploy a node pool with gVisor enabled. You can view the full documentation . Prepare a container image with pre-installed Docker: ```shell $ cd g3doc/user_guide/tutorials/docker-in-gke-sandbox/ $ docker build -t {registry_url}/docker-in-gvisor:latest . $ docker push {registry_url}/docker-in-gvisor:latest ``` Create a Kubernetes pod YAML file (docker.yaml) with the following content: ```yaml apiVersion: v1 kind: Pod metadata: name: docker-in-gvisor spec: runtimeClassName: gvisor containers: name: docker-in-gvisor image: {registry_url}/docker-in-gvisor:latest securityContext: capabilities: add: ["all"] volumeMounts: name: docker mountPath: /var/lib/docker volumes: name: docker emptyDir: {} ``` This YAML file defines a Kubernetes Pod named docker-in-gvisor that will run a single container from the avagin/docker-in-gvisor:0.1 image. Apply the pod YAML to your GKE cluster using the kubectl apply command: ```shell $ kubectl apply -f docker.yaml ``` Verify that the docker-in-gvisor pid is running successfully: `shell $ kubectl get pods | grep docker-in-gvisor` You can access the container by executing a shell inside it. Use the following command: ```shell kubectl exec -it docker-in-gvisor -- bash ``` Now, we can build and run Docker containers. ```shell $ mkdir whalesay && cd whalesay $ cat > Dockerfile <<EOF FROM ubuntu RUN apt-get update && apt-get install -y cowsay curl RUN mkdir -p /usr/share/cowsay/cows/ RUN curl -o /usr/share/cowsay/cows/docker.cow https://raw.githubusercontent.com/docker/whalesay/master/docker.cow ENTRYPOINT ["/usr/games/cowsay", "-f", "docker.cow"] EOF $ docker build --network=host -t whalesay . .... Successfully tagged whalesay:latest $ docker run --network host -it --rm whalesay "Containers do not contain, but gVisor-s do!" _ / Containers do not contain, but gVisor-s \ \ do! / -- \ ## . \ ## ## ## == /""""""""""""""""\_/ === ~ { ~ ~ / ===- ~~~ \ o / \ \ / \\/ ```
Project: Kata Containers (Runtime / Container Runtime)
File: TokenBucket.md

Name | Type | Description | Notes | - | - | - Size | int64 | The total number of tokens this bucket can hold. | OneTimeBurst | Pointer to int64 | The initial size of a token bucket. | [optional] RefillTime | int64 | The amount of milliseconds it takes for the bucket to refill. | `func NewTokenBucket(size int64, refillTime int64, ) *TokenBucket` NewTokenBucket instantiates a new TokenBucket 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 NewTokenBucketWithDefaults() *TokenBucket` NewTokenBucketWithDefaults instantiates a new TokenBucket 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 *TokenBucket) GetSize() int64` GetSize returns the Size field if non-nil, zero value otherwise. `func (o TokenBucket) GetSizeOk() (int64, bool)` GetSizeOk returns a tuple with the Size field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *TokenBucket) SetSize(v int64)` SetSize sets Size field to given value. `func (o *TokenBucket) GetOneTimeBurst() int64` GetOneTimeBurst returns the OneTimeBurst field if non-nil, zero value otherwise. `func (o TokenBucket) GetOneTimeBurstOk() (int64, bool)` GetOneTimeBurstOk returns a tuple with the OneTimeBurst field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *TokenBucket) SetOneTimeBurst(v int64)` SetOneTimeBurst sets OneTimeBurst field to given value. `func (o *TokenBucket) HasOneTimeBurst() bool` HasOneTimeBurst returns a boolean if a field has been set. `func (o *TokenBucket) GetRefillTime() int64` GetRefillTime returns the RefillTime field if non-nil, zero value otherwise. `func (o TokenBucket) GetRefillTimeOk() (int64, bool)` GetRefillTimeOk returns a tuple with the RefillTime field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *TokenBucket) SetRefillTime(v int64)` SetRefillTime sets RefillTime field to given value.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: monitoring.md

Piraeus Datastore offers integration with the [Prometheus monitoring stack]. The integration configures: Metrics scraping for the LINSTOR and DRBD state. Alerts based on the cluster state A Grafana dashboard To complete this guide, you should be familiar with: Deploying workloads in Kubernetes using Deploying resources using NOTE: If you already have a working Prometheus Operator deployment, skip this step. First deploy the . A simple way to deploy it, is to use the helm chart provided by the Prometheus Community. First, add the helm chart repository to your local helm configuration: ``` $ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ``` Then, deploy the chart. This chart will set up Prometheus, AlertManager and Grafana for your cluster. Configure it to search for monitoring and alerting rules in all namespaces: ``` $ helm install --create-namespace -n monitoring prometheus prometheus-community/kube-prometheus-stack \ --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \ --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \ --set prometheus.prometheusSpec.ruleSelectorNilUsesHelmValues=false ``` NOTE: By default, the deployment will only monitor resources in the `kube-system` and its own namespace. Piraeus Datastore is usually deployed in a different namespace, so Prometheus needs to be configured to watch this namespace. In the example above, this is achieved by setting the various `*NilUsesHelmValues` parameters to `false`. After creating a Prometheus Operator deployment and configuring it to watch all namespaces, apply the monitoring and alerting resources for Piraeus Datastore: ``` $ kubectl apply --server-side -n piraeus-datastore -k "https://github.com/piraeusdatastore/piraeus-operator//config/extras/monitoring?ref=v2" ``` Verify that the monitoring configuration is working by checking the prometheus console. First, get access to the prometheus console from your local browser by forwarding it to local port 9090: ``` $ kubectl port-forward -n monitoring services/prometheus-kube-prometheus-prometheus 9090:9090 ``` Now, open http://localhost:9090/graph and display the `linstorinfo` and `drbdversion` metrics: To view the dashboard, forward the grafana service to local port 3000: ``` $ kubectl port-forward -n monitoring services/prometheus-grafana 3000:http-web ``` Now, open http://localhost:3000 and log in. If using the example deployment from above, use username `admin` and password `prom-operator` to gain access. Then, select "Piraeus Datastore" from the available dashboards: