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

Share you story about the Kube-OVN journey with the community. | Type | Name | Website | Use-Case | |:-|:-|:-|:-| | Vendor | nix | https://aenix.io/ | nix provides consulting services for cloud providers and uses Kube-OVN as main CNI in free PaaS platform for running virtual machines and Kubernetes-as-a-Service. | | Vendor | Alauda Inc | https://www.alauda.cn/ | Alauda distributes Kube-OVN as part of the to provide enterprise level cloud native network. | | User | China Telecom CTYun | https://www.ctyun.cn/ | CTYun uses Kube-OVN as the cloud native SDN component in . | | User | China Yealink | https://www.yealink.com/ | Yealink uses Kube-OVN as the cloud native SDN component in Private Cloud. | | User | Inspur | https://www.inspur.com/ | Inspur uses Kube-OVN as the cloud native SDN component in Private Cloud. | | User | GPUHPC | https://gpuhpc.com/ | GPUHPC uses Kube-OVN as the cloud native SDN component in Edge Cloud. | | User | 99Cloud | https://www.99cloud.net/ | 99Cloud uses Kube-OVN to provider cloud native network for VM, Kata, VNF in Hybird Cloud. | | Vendor | Canonical | https://ubuntu.com/kubernetes | Canonical uses Kube-OVN inside of its Chramed Kube-OVN operator and is distributed on Charmed Kubernetes. |
Project: rkt (Runtime / Container Runtime)
File: rm.md

Cleans up all resources (files, network objects) associated with a pod just like `rkt gc`. This command can be used to immediately free resources without waiting for garbage collection to run. ``` rkt rm c138310f ``` Instead of passing UUID on command line, rm command can read the UUID from a text file. This can be paired with `--uuid-file-save` to remove pods by name: ``` rkt run --uuid-file-save=/run/rkt-uuids/mypod ... rkt rm --uuid-file=/run/rkt-uuids/mypod ``` See the table with .
Project: Velero (Runtime / Cloud Native Storage)
File: volumesnapshotlocation.md

title: "Velero Volume Snapshot Location" layout: docs A volume snapshot location is the location in which to store the volume snapshots created for a backup. Velero can be configured to take snapshots of volumes from multiple providers. Velero also allows you to configure multiple possible `VolumeSnapshotLocation` per provider, although you can only select one location per provider at backup time. Each VolumeSnapshotLocation describes a provider + location. These are represented in the cluster via the `VolumeSnapshotLocation` CRD. Velero must have at least one `VolumeSnapshotLocation` per cloud provider. A sample YAML `VolumeSnapshotLocation` looks like the following: ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: aws-default namespace: velero spec: provider: aws config: region: us-west-2 profile: "default" ``` The configurable parameters are as follows: {{< table caption="Main config parameters" >}} | Key | Type | Default | Meaning | | | | | | | `provider` | String | Required Field | The name for whichever storage provider will be used to create/store the volume snapshots. See for the appropriate value to use. | | `config` | map string string | None (Optional) | Provider-specific configuration keys/values to be passed to the volume snapshotter plugin. See for details. | {{< /table >}}
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-bugtool_completion_powershell.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-bugtool completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-bugtool completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Carina (Runtime / Cloud Native Storage)
File: capacity-scheduler.md

carina-scheduler can scheduling pods based on usage and capacity of nodes' disks. ```yaml config.json: |- { "diskScanInterval": "300", # disk scan intervals in seconds. Zero will disable scanning. "diskGroupPolicy": "type", # disk group policy "schedulerStrategy": "spreadout" # scheduler policy, supports binpack and spreadout. } ``` For schedulerStrategy, In case of `storageclass volumeBindingMode:Immediate`, the scheduler will only consider nodes' disk usage. For example, with `spreadout` policy, carina scheduler will pick the node with the largest disk capacity to create volume. In case of `schedulerStrategy``storageclass volumeBindingMode:WaitForFirstConsumer`, carina scheduler only affects the pod scheduleing by providing its rank. Kube-scheduler will pick a node finally. User can learn detailed messages in carina-scheduler's log. When multiples nodes have valid capacity ten times larger than requested, those node will share the same rank. Notethere is an carina webhook that will change the pod scheduler to carina-scheduler if it uses carina PVC.
Project: Rook (Runtime / Cloud Native Storage)
File: ISSUE_TEMPLATE.md

<!-- Are you in the right place? For issues or feature requests, please create an issue in this repository. For general technical and non-technical questions, we are happy to help you on our . Did you already search the existing open issues for anything similar? --> Is this a bug report or feature request? <!-- Remove only one --> Bug Report Feature Request Bug Report Expected behavior: Deviation from expected behavior: How to reproduce it (minimal and precise): <!-- Please let us know any circumstances for reproduction of your bug. --> File(s) to submit: Cluster CR (custom resource), typically called `cluster.yaml`, if necessary Operator's logs, if necessary Crashing pod(s) logs, if necessary To get logs, use `kubectl -n <namespace> logs <pod name>` When pasting logs, always surround them with backticks or use the `insert code` button from the GitHub UI. Read . Feature Request Are there any similar features already existing: What should the feature do: What would be solved through this feature: Does this have an impact on existing features: Environment: OS (e.g. from /etc/os-release): Kernel (e.g. `uname -a`): Cloud provider or hardware configuration: Rook version (use `rook version` inside of a Rook Pod): Storage backend version (e.g. for ceph do `ceph -v`): Kubernetes version (use `kubectl version`): Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): Storage backend status (e.g. for Ceph use `ceph health` in the ):
Project: Velero (Runtime / Cloud Native Storage)
File: run-locally.md

title: "Run Velero locally in development" layout: docs Running the Velero server locally can speed up iterative development. This eliminates the need to rebuild the Velero server image and redeploy it to the cluster with each change. Velero runs against the Kubernetes API server as the endpoint (as per the `kubeconfig` configuration), so both the Velero server and client use the same `client-go` to communicate with Kubernetes. This means the Velero server can be run locally just as functionally as if it was running in the remote cluster. When running Velero, you will need to ensure that you set up all of the following: Appropriate RBAC permissions in the cluster Read access for all data from the source cluster and namespaces Write access to the target cluster and namespaces Cloud provider credentials Read/write access to volumes Read/write access to object storage for backup data A object definition for the Velero server (Optional) A object definition for the Velero server, to take PV snapshots See documentation on how to install Velero in some specific providers: After you use the `velero install` command to install Velero into your cluster, you scale the Velero deployment down to 0 so it is not simultaneously being run on the remote cluster and potentially causing things to get out of sync: `kubectl scale --replicas=0 deployment velero -n velero` To run the server locally, use the full path according to the binary you need. Example, if you are on a Mac, and using `AWS` as a provider, this is how to run the binary you built from source using the full path: `AWSSHAREDCREDENTIALSFILE=<path-to-credentials-file> ./output/bin/darwin/amd64/velero`. Alternatively, you may add the `velero` binary to your `PATH`. Start the server: `velero server [CLI flags]`. The following CLI flags may be useful to customize, but see `velero server --help` for full details: `--log-level`: set the Velero server's log level (default `info`, use `debug` for the most logging) `--kubeconfig`: set the path to the kubeconfig file the Velero server uses to talk to the Kubernetes apiserver (default `$KUBECONFIG`) `--namespace`: the set namespace where the Velero server should look for backups, schedules, restores (default `velero`) `--plugin-dir`: set the directory where the Velero server looks for plugins (default `/plugins`) The `--plugin-dir` flag requires the plugin binary to be present locally, and should be set to the directory containing this built binary. `--metrics-address`: set the bind address and port where Prometheus metrics are exposed (default `:8085`)
Project: Kube-router (Runtime / Cloud Native Network)
File: feature_request.md

name: Feature request about: Suggest an idea for kube-router title: '' labels: feature assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is and what the feature provides. Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Spiderpool (Runtime / Cloud Native Network)
File: reservedip.md

| Case ID | Title | Priority | Smoke | Status | Other | | - | | -- | -- | | -- | | S00001 | An IP that is set in ReservedIP CRD should not be assigned to a pod | p2 | | done | | | S00002 | An IP that is set in the `excludeIPs` field of ippool, should not be assigned to a pod | p2 | | done | | | S00003 | Failed to set same IP in excludeIPs when an IP is assigned to a pod | p2 | | done | | | S00004 | Check excludeIPs for manually created ippools | p3 | | done | |
Project: Container Storage Interface (CSI) (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 Spec version: Others:
Project: FabEdge (Runtime / Cloud Native Network)
File: roadmap.md

Support KubeEdge/SuperEdge/Openyurt Automatic management of node certificate Air-gap installation Support Flannel/Calico Support IPV4 Support IPSec Tunnel Support Edge Cluster Support topology-aware service discovery Support IPV6 Implement a flexiable way to configure fabedge-agent Support auto networking of edge nodes in LAN Change the naming strategy of fabedge-agent pods Add commonName validation for fabedge-agent certificates Implement node-specific configuration of fabedge-agent arguments Let fabedge-agent configure sysctl parameters needed Let fabedge-operator manage calico ippools for CIDRs Support settings strongswan's port Support strongswan hole punching Release fabctl which is a CLI to help diagnosing networking problems; Integerate fabedge-agent with coredns and kube-proxy Implement connector high availability Improve dual stack implementation Improve iptables rule configuring (ensure the order of rules)
Project: Velero (Runtime / Cloud Native Storage)
File: README.md

The Vision To create a modern, geometric typeface. Open sourced, and openly available. Influenced by other popular geometric, minimalist sans-serif typefaces of the new millennium. Designed for optimal readability at small point sizes while beautiful at large point sizes. December 2017 update Currently working on greatly improving spacing and kerning of the base typeface. Once this is done, work on other variations (e.g. rounded or slab) can begin in earnest. The License Licensed under Open Font License (OFL). Available to anyone and everyone. Contributions welcome. Contact Contact me via chris.m.simpson@icloud.com or http://twitter.com/ChrisMSimpson for any questions, requests or improvements (or just submit a pull request). Support You can now support work on Metropolis via Patreon at https://www.patreon.com/metropolis. ally-added-mutations.yaml case-b-target-manually-added-mutations.yaml source: https://raw.githubusercontent.com/brito-rafa/k8s-webhooks/master/examples-for-projectvelero/case-b/target/case-b-target-manually-added-mutations.yaml case-c-target-manually-added-mutations.yaml source: https://raw.githubusercontent.com/brito-rafa/k8s-webhooks/master/examples-for-projectvelero/case-a/source/case-a-source.yaml case-c-target-manually-added-mutations.yaml source: https://raw.githubusercontent.com/brito-rafa/k8s-webhooks/master/examples-for-projectvelero/case-c/target/case-c-target-manually-added-mutations.yaml musicv1rockband.yaml source: https://github.com/brito-rafa/k8s-webhooks/blob/master/examples-for-projectvelero/case-a/source/music/config/samples/musicv1rockband.yaml musicv1alpha1rockband.yaml source: https://github.com/brito-rafa/k8s-webhooks/blob/master/examples-for-projectvelero/case-a/source/music/config/samples/musicv1alpha1rockband.yaml musicv2rockband.yaml source: https://github.com/brito-rafa/k8s-webhooks/blob/master/examples-for-projectvelero/case-c/target/music/config/samples/musicv2rockband.yaml musicv2beta1rockband.yaml source: https://github.com/brito-rafa/k8s-webhooks/blob/master/examples-for-projectvelero/case-b/source/music/config/samples/musicv2beta1rockband.yaml musicv2beta2rockband.yaml source: https://github.com/brito-rafa/k8s-webhooks/blob/master/examples-for-projectvelero/case-b/source/music/config/samples/musicv2beta2rockband.yaml
Project: rkt (Runtime / Container Runtime)
File: dns.md

rkt can automatically prepare `/etc/resolv.conf` and `/etc/hosts` for the apps in the pod. They can either be generated at runtime, or the host's configuration can be used. Four options affect how this file is created: `--dns` : Specify either a DNS server, or one of the "magic" values `host` or `none` `--dns-domain` : The resolv.conf `domain` parameter `--dns-opt` : One or more resolv.conf `option` parameters `--dns-search` : One or more domains for the search list The simplest configuration is: ```sh $ sudo rkt run --dns=8.8.8.8 pod.aci ``` Other parameters can be given: ```sh $ sudo rkt run \ --dns=8.8.8.8 --dns=4.2.2.2 \ --dns-domain=example.org \ --dns-opt=debug --dns-opt=rotate \ --dns-search=example.com --dns-search=example.gov \ pod.aci ``` This will generate the following `/etc/resolv.conf` for the applications: ``` search example.com example.gov nameserver 8.8.8.8 nameserver 4.2.2.2 options debug rotate domain example.org ``` The magic parameter `host` will bind-mount the host's `/etc/resolv.conf` in to the applications. This will be a read-only mount. The magic parameter `none` will ignore any DNS configuration from CNI. This will ensure that the image's `/etc/resolv.conf` has precedence. `resolv.conf` can be generated by multiple components. The order of precedence is: If `--dns`, et al. are passed to `rkt run` If a CNI plugin returns DNS information, unless `--dns=none` is passed If a volume is mounted on `/etc/resolv.conf` If the application container includes `/etc/resolv.conf` `rkt run` provides one option with two modes: `--hosts-entry <IP>=<HOST>` `--hosts-entry host` Passing `--hosts-entry=host` will bind-mount (read-only) the hosts's `/etc/hosts` in to every application. When passing IP=HOST pairs: ```sh $ rkt run ... --hosts-entry 198.51.100.0=host1,198.51.100.1=host2 --hosts-entry 198.51.100.0=host3 ``` rkt will take some and append the requested entries. ``` < the default entries > 198.51.100.0 host1 host3 198.51.100.1 host2 ``` `/etc/hosts` can be generated by multiple components. The order of precedence is: If `--hosts-entry` is passed to `rkt run` If a volume is mounted on `/etc/hosts` If the app image includes `/etc/hosts` Otherwise, a fallback stub `/etc/hosts` is created The following example shows that the DNS options allow the pod to resolve names successfully: ``` $ sudo rkt run --net=host --dns=8.8.8.8 quay.io/coreos/alpine-sh --exec=/bin/ping --interactive -- -c 1 coreos.com ... PING coreos.com (104.20.47.236): 56 data bytes 64 bytes from 104.20.47.236: seq=0 ttl=63 time=5.421 ms coreos.com ping statistics 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 5.421/5.421/5.421 ms ```
Project: Weave Net (Runtime / Cloud Native Network)
File: troubleshooting-weavedns.md

title: Troubleshooting and Present Limitations menu_order: 50 search_type: Documentation The command: weave status reports on the current status of various Weave Net components, including DNS: ``` ... Service: dns Domain: weave.local. Upstream: 8.8.8.8, 8.8.4.4 TTL: 1 Entries: 9 ... ``` The first section covers the router; see the [troubleshooting guide](/site/troubleshooting.md#weave-status) for more details. The 'Service: dns' section is pertinent to weaveDNS, and includes: The local domain suffix which is being served The list of upstream servers used for resolving names not in the local domain The response ttl The total number of entries You may also use `weave status dns` to obtain a [complete dump](/site/troubleshooting.md#weave-status-dns) of all DNS registrations. Information on the processing of queries, and the general operation of weaveDNS, can be obtained from the container logs with docker logs weave The server will not know about restarted containers, but if you re-attach a restarted container to the weave network, it will be re-registered with weaveDNS. The server may give unreachable IPs as answers, since it doesn't try to filter by reachability. If you use subnets, align your hostnames with the subnets.
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.13.md

title: "Upgrading to Velero 1.13" layout: docs Velero installed. If you're not yet running at least Velero v1.8, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Caution: From Velero v1.10, except for using restic to do file-system level backup and restore, kopia is also been integrated, it could be upgraded from v1.10 or higher to v1.13 directly, but it would be a little bit of difference when upgrading to v1.13 from a version lower than v1.10.0. Install the Velero v1.13 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.13.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.10.0 only v1 CRD will be supported during installation, therefore, the v1.10.0 will only work on Kubernetes version >= v1.16 Update the container image and objects fields used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl get deploy -n velero -ojson \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.13.0\"#g" \ | sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \ | sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \ | sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \ | sed "s#restic-timeout#fs-backup-timeout#g" \ | kubectl apply -f - echo $(kubectl get ds -n velero restic -ojson) \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.13.0\"#g" \ | sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \ | sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \ | kubectl apply -f - kubectl delete ds -n velero restic --force --grace-period 0 ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.13.0 Git commit: <git SHA> Server: Version: v1.13.0 ``` If it's directly upgraded from v1.10 or higher, the other steps remain the same only except for step 3 above. The details as below: Update the container image used by the Velero deployment, plugin and, optionally, the node agent daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.13.0 \ velero-plugin-for-aws=velero/velero-plugin-for-aws:v1.9.0 \ --namespace velero kubectl set image daemonset/node-agent \ node-agent=velero/velero:v1.13.0 \ --namespace velero ``` If upgraded from v1.9.x, there still remains some resources left over in the cluster and never used in v1.13.x, which could be deleted through kubectl and it is based on your desire: resticrepository CRD and related CRs velero-restic-credentials secret in velero install namespace
Project: Weave Net (Runtime / Cloud Native Network)
File: encryption.md

title: Encryption and Weave Net menu_order: 50 search_type: Documentation Weave Net peers . This communication . Encryption of control plane traffic (TCP) and data plane traffic (UDP) of sleeve overlay is accomplished using the crypto libraries, employing Curve25519, XSalsa20 and Poly1305 to encrypt and authenticate messages. Weave Net protects against injection and replay attacks for traffic forwarded between peers. NaCl was selected because of its good reputation both in terms of selection and implementation of ciphers, but equally importantly, its clear APIs, good documentation and high-quality . It is quite difficult to use NaCl incorrectly. Contrast this with libraries such as OpenSSL where the library and its APIs are vast in size, poorly documented, and easily used wrongly. There are some similarities between Weave Net's crypto and . Weave Net does not need to cater for multiple cipher suites, certificate exchange and other requirements emanating from X509, and a number of other features. This simplifies the protocol and implementation considerably. On the other hand, Weave Net needs to support UDP transports, and while there are extensions to TLS such as which can operate over UDP, these are not widely implemented and deployed. In the case of fast datapath, data plane traffic is encrypted by using . The process of encryption is handled by the Linux kernel and is controlled via the IP transformation framework (XFRM). See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-generic_completion_fish.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: cilium-operator-generic completion fish | source To load completions for every new session, execute once: cilium-operator-generic completion fish > ~/.config/fish/completions/cilium-operator-generic.fish You will need to start a new shell for this setup to take effect. ``` cilium-operator-generic completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell