cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Net (Runtime / Cloud Native Network)
File: how-it-works.md

title: Understanding Weave Net menu_order: 10 search_type: Documentation A Weave network consists of a number of 'peers' - Weave Net routers residing on different hosts. Each peer has a name, which tends to remain the same over restarts, a human friendly nickname for use in status and logging output and a unique identifier (UID) that is different each time it is run. These are opaque identifiers as far as the router is concerned, although the name defaults to a MAC address. Weave Net routers establish TCP connections with each other, over which they perform a protocol handshake and subsequently exchange information. These connections are encrypted if so configured. Peers also establish UDP "connections", possibly encrypted, which carry encapsulated network packets. These "connections" are duplex and can traverse firewalls. Weave Net creates a network bridge on the host. Each container is connected to that bridge via a veth pair, the container side of which is given an IP address and netmask supplied either by the user or by Weave Net's IP address allocator. Weave Net routes packets between containers on different hosts via two methods: a method, which operates entirely in kernel space, and a fallback `sleeve` method, in which packets destined for non-local containers are captured by the kernel and processed by the Weave Net router in user space, forwarded over UDP to weave router peers running on other hosts, and there injected back into the kernel which in turn passes them to local destination containers. Weave Net routers learn which peer host a particular MAC address resides on. They combine this knowledge with topology information in order to make routing decisions and thus avoid forwarding every packet to every peer. Weave Net can route packets in partially connected networks with changing topology. For example, in this network, peer 1 is connected directly to 2 and 3, but if 1 needs to send a packet to 4 or 5 it must first send it to peer 3: See Also *
Project: MinIO (Runtime / Cloud Native Storage)
File: README.fips.md

MinIO creates FIPS builds using a patched version of the Go compiler (that uses BoringCrypto, from BoringSSL, which is ) published by the Golang Team . MinIO FIPS executables are available at <http://dl.min.io> - they are only published for `linux-amd64` architecture as binary files with the suffix `.fips`. We also publish corresponding container images to our official image repositories. We are not making any statements or representations about the suitability of this code or build in relation to the FIPS 140-2 standard. Interested users will have to evaluate for themselves whether this is useful for their own purposes.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_config.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage runtime config ``` -h, --help help for config ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - List all runtime config entries
Project: Antrea (Runtime / Cloud Native Network)
File: policy-only.md

Antrea supports chaining with routed CNI implementations such as EKS CNI. In this mode, Antrea enforces Kubernetes NetworkPolicy, and delegates Pod IP management and network connectivity to the primary CNI. Antrea is designed to work as NetworkPolicy plug-in to work together with a routed CNIs. For as long as a CNI implementation fits into this model, Antrea may be inserted to enforce NetworkPolicy in that CNI's environment using Open vSwitch(OVS). In addition, Antrea working as NetworkPolicy plug-in automatically enables Antrea-proxy, because it requires Antrea-proxy to load balance Pod-to-Service traffic. <img src="../assets/policy-only-cni.svg" width="600" alt="Antrea Switched CNI"> The above diagram depicts a routed CNI network topology on the left, and what it looks like after Antrea inserts the OVS bridge into the data path. The diagram on the left illustrates a routed CNI network topology such as AWS EKS. In this topology a Pod connects to the host network via a point-to-point(PtP) like device, such as (but not limited to) a veth-pair. On the host network, a host route with corresponding Pod's IP address as destination is created on each PtP device. Within each Pod, routes are configured to ensure all outgoing traffic is sent over this PtP device, and incoming traffic is received on this PtP device. This is a spoke-and-hub model, where to/from Pod traffic, even within the same worker Node must traverse first to the host network and be routed by it. When the container runtime instantiates a Pod, it first calls the primary CNI to configure Pod's IP, route table, DNS etc, and then connects Pod to host network with a PtP device such as a veth-pair. When Antrea is chained with this primary CNI, container runtime then calls Antrea Agent, and the Antrea Agent attaches Pod's PtP device to the OVS bridge, and moves the host route to the Pod to local host gateway(`antrea-gw0`) interface from the PtP device. This is illustrated by the diagram on the right. Antrea needs to satisfy that All IP packets, sent on ``antrea-gw0`` in the host network, are received by the Pods exactly the same as if the OVS bridge had not been inserted. All IP packets, sent by Pods, are received by other Pods or the host network exactly the same as if OVS bridge had not been inserted. There are no requirements on Pod MAC addresses as all MAC addresses stays within the OVS bridge. To satisfy the above requirements, Antrea needs no knowledge of Pod's network configurations nor of underlying CNI network, it simply needs to program the following OVS flows on the OVS bridge: A default ARP responder flow that answers any ARP request. Its sole purpose is so that a Pod can resolve its neighbors, and the Pod therefore can generate traffic to these neighbors. A L3 flow for each local Pod that routes IP packets to that Pod if packets' destination IP matches that of the Pod. A L3 flow that routes all other IP packets to host network via `antrea-gw0` interface. These flows together handle all Pod traffic patterns.
Project: ORAS (Runtime / Cloud Native Storage)
File: OWNERS.md

Owners: Sajay Antony (@sajayantony) Shiwei Zhang (@shizhMSFT) Steve Lasker (@stevelasker) Emeritus: Avi Deitcher (@deitch) Jimmy Zelinskie (@jzelinskie) Josh Dolitsky (@jdolitsky) Vincent Batts (@vbatts)
Project: Rook (Runtime / Cloud Native Storage)
File: stretch-cluster.md

title: Stretch Storage Cluster For environments that only have two failure domains available where data can be replicated, consider the case where one failure domain is down and the data is still fully available in the remaining failure domain. To support this scenario, Ceph has integrated support for "stretch" clusters. Rook requires three zones. Two zones (A and B) will each run all types of Rook pods, which we call the "data" zones. Two mons run in each of the two data zones, while two replicas of the data are in each zone for a total of four data replicas. The third zone (arbiter) runs a single mon. No other Rook or Ceph daemons need to be run in the arbiter zone. For this example, we assume the desired failure domain is a zone. Another failure domain can also be specified with a known which is already being used for OSD failure domains. ```yaml apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: name: rook-ceph namespace: rook-ceph spec: dataDirHostPath: /var/lib/rook mon: count: 5 allowMultiplePerNode: false stretchCluster: failureDomainLabel: topology.kubernetes.io/zone subFailureDomain: host zones: name: a arbiter: true name: b name: c cephVersion: image: quay.io/ceph/ceph:v18.2.2 allowUnsupported: true storage: useAllNodes: true useAllDevices: true deviceFilter: "" placement: osd: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: matchExpressions: key: topology.kubernetes.io/zone operator: In values: b c ``` For more details, see the .
Project: Velero (Runtime / Cloud Native Storage)
File: ark_schedule_create.md

title: "ark schedule create" layout: docs Create a schedule The --schedule flag is required, in cron notation: | Character Position | Character Period | Acceptable Values | | -|:-:| --:| | 1 | Minute | 0-59,* | | 2 | Hour | 0-23,* | | 3 | Day of Month | 1-31,* | | 4 | Month | 1-12,* | | 5 | Day of Week | 0-7,* | ``` ark schedule create NAME --schedule [flags] ``` ``` ark create schedule NAME --schedule="0 /6 " ``` ``` --exclude-namespaces stringArray namespaces to exclude from the backup --exclude-resources stringArray resources to exclude from the backup, formatted as resource.group, such as storageclasses.storage.k8s.io -h, --help help for create --include-cluster-resources optionalBool[=true] include cluster-scoped resources in the backup --include-namespaces stringArray namespaces to include in the backup (use '' for all namespaces) (default ) --include-resources stringArray resources to include in the backup, formatted as resource.group, such as storageclasses.storage.k8s.io (use '*' for all resources) --label-columns stringArray a comma-separated list of labels to be displayed as columns --labels mapStringString labels to apply to the backup -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. --schedule string a cron expression specifying a recurring schedule for this backup to run -l, --selector labelSelector only back up resources matching this label selector (default <none>) --show-labels show labels in the last column --snapshot-volumes optionalBool[=true] take snapshots of PersistentVolumes as part of the backup --ttl duration how long before the backup can be garbage collected (default 720h0m0s) ``` ``` --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 ``` - Work with schedules
Project: MinIO (Runtime / Cloud Native Storage)
File: etcd.md

etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. Docker 18.03 or above, refer here for . etcd uses as a primary container registry. ``` rm -rf /tmp/etcd-data.tmp && mkdir -p /tmp/etcd-data.tmp && \ podman rmi gcr.io/etcd-development/etcd:v3.3.9 || true && \ podman run \ -p 2379:2379 \ -p 2380:2380 \ --mount type=bind,source=/tmp/etcd-data.tmp,destination=/etcd-data \ --name etcd-gcr-v3.3.9 \ gcr.io/etcd-development/etcd:v3.3.9 \ /usr/local/bin/etcd \ --name s1 \ --data-dir /etcd-data \ --listen-client-urls http://0.0.0.0:2379 \ --advertise-client-urls http://0.0.0.0:2379 \ --listen-peer-urls http://0.0.0.0:2380 \ --initial-advertise-peer-urls http://0.0.0.0:2380 \ --initial-cluster s1=http://0.0.0.0:2380 \ --initial-cluster-token tkn \ --initial-cluster-state new ``` You may also setup etcd with TLS following this documentation MinIO server expects environment variable for etcd as `MINIOETCDENDPOINTS`, this environment variable takes many comma separated entries. ``` export MINIOETCDENDPOINTS=http://localhost:2379 minio server /data ``` NOTE: If `etcd` is configured with `Client-to-server authentication with HTTPS client certificates` then you need to use additional envs such as `MINIOETCDCLIENTCERT` pointing to path to `etcd-client.crt` and `MINIOETCDCLIENTCERT_KEY` path to `etcd-client.key` . Once etcd is configured, any STS configuration will work including Client Grants, Web Identity or AD/LDAP. For example, you can configure STS with Client Grants (KeyCloak) using the guides at and . Once this is done, STS credentials can be generated: ``` go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga { "accessKey": "IRBLVDGN5QGMDCMO1X8V", "secretKey": "KzS3UZKE7xqNdtRbKyfcWgxBS6P1G4kwZn4DXKuY", "expiration": "2018-08-21T15:49:38-07:00", "sessionToken": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3NLZXkiOiJJUkJMVkRHTjVRR01EQ01PMVg4ViIsImF1ZCI6IlBvRWdYUDZ1Vk80NUlzRU5SbmdEWGo1QXU1WWEiLCJhenAiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiZXhwIjoxNTM0ODkxNzc4LCJpYXQiOjE1MzQ4ODgxNzgsImlzcyI6Imh0dHBzOi8vbG9jYWxob3N0Ojk0NDMvb2F1dGgyL3Rva2VuIiwianRpIjoiMTg0NDMyOWMtZDY1YS00OGEzLTgyMjgtOWRmNzNmZTgzZDU2In0.4rKsZ8VkZnIS_ALzfTJ9UbEKPFlQVvIyuHw6AWTJcDFDVgQA2ooQHmH9wUDnhXBi1M7o8yWJ47DXP-TLPhwCgQ" } ``` These credentials can now be used to perform MinIO API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further .
Project: HwameiStor (Runtime / Cloud Native Storage)
File: apis.md

sidebar_position: 11 sidebar_label: "APIs" HwameiStor defines some object classes to associate PV/PVC with local disks. | Name | Abbr | Kind | Function | ||-|--|-| | clusters | hmcluster | Cluster | HwameiStor cluster | | events | evt | Event | Audit information of HwameiStor cluster | | localdiskclaims | ldc | LocalDiskClaim | Filter and allocate local data disks | | localdisknodes | ldn | LocalDiskNode | Storage pool for disk volumes | | localdisks | ld | LocalDisk | Data disks on nodes and automatically find which disks are available | | localdiskvolumes | ldv | LocalDiskVolume | Disk volumes | | localstoragenodes | lsn | LocalStorageNode | Storage pool for lvm volumes | | localvolumeconverts | lvconvert | LocalVolumeConvert | Convert common LVM volume to highly available LVM volume | | localvolumeexpands | lvexpand | LocalVolumeExpand | Expand local volume storage capacity | | | localvolumegroups | lvg | LocalVolumeGroup | LVM volume groups | | | localvolumemigrates | lvmigrate | LocalVolumeMigrate | Migrate LVM volume | | localvolumereplicas | lvr | LocalVolumeReplica | Replicas of LVM volume | | localvolumereplicasnapshotrestores | lvrsrestore,lvrsnaprestore | LocalVolumeReplicaSnapshotRestore | Restore snapshots of LVM volume Replicas | | localvolumereplicasnapshots | lvrs | LocalVolumeReplicaSnapshot | Snapshots of LVM volume Replicas | | localvolumes | lv | LocalVolume | LVM local volumes | | localvolumesnapshotrestores | lvsrestore,lvsnaprestore | LocalVolumeSnapshotRestore | Restore snapshots of LVM volume | | localvolumesnapshots | lvs | LocalVolumeSnapshot | Snapshots of LVM volume | | | resizepolicies | | ResizePolicy | PVC automatic expansion policy | |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ipmasq.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> ip-masq-agent CIDRs ``` -h, --help help for ipmasq ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - List ip-masq-agent CIDRs
Project: rkt (Runtime / Container Runtime)
File: install-rkt-in-coreos.md

If a different version of rkt is required than what ships with CoreOS Container Linux, a oneshot systemd unit can be used to download and install an alternate version on boot. The following unit will use curl to download rkt, its signature, and the CoreOS app signing key. The downloaded rkt is then verified with its signature, and extracted to /opt/rkt. ``` [Unit] Description=rkt installer Requires=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/mkdir -p /opt/rkt ExecStart=/usr/bin/curl --silent -L -o /opt/rkt.tar.gz <rkt-url> ExecStart=/usr/bin/curl --silent -L -o /opt/rkt.tar.gz.sig <rkt-sig-url> ExecStart=/usr/bin/curl --silent -L -o /opt/coreos-app-signing-key.gpg https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg ExecStart=/usr/bin/gpg --keyring /tmp/gpg-keyring --no-default-keyring --import /opt/coreos-app-signing-key.gpg ExecStart=/usr/bin/gpg --keyring /tmp/gpg-keyring --no-default-keyring --verify /opt/rkt.tar.gz.sig /opt/rkt.tar.gz ExecStart=/usr/bin/tar --strip-components=1 -xf /opt/rkt.tar.gz -C /opt/rkt ``` The URLs in this unit must be filled in before the unit is installed. Valid URLs can be found on . This unit should be installed with either or a . Other units being added can then contain a `After=rkt-install.service` (or whatever the service was named) to delay their running until rkt has been installed.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restore.md

title: "ark restore" layout: docs Work with restores Work with restores ``` -h, --help help for restore ``` ``` --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. - Create a restore - Delete a restore - Describe restores - Get restores - Get restore logs
Project: Velero (Runtime / Cloud Native Storage)
File: use-cases.md

title: "Use Cases" layout: docs This doc provides sample Ark commands for the following common scenarios: Using Schedules and Restore-Only Mode If you periodically back up your cluster's resources, you are able to return to a previous state in case of some unexpected mishap, such as a service outage. Doing so with Heptio Ark looks like the following: After you first run the Ark server on your cluster, set up a daily backup (replacing `<SCHEDULE NAME>` in the command as desired): ``` ark schedule create <SCHEDULE NAME> --schedule "0 7 *" ``` This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`. A disaster happens and you need to recreate your resources. Update the , setting `restoreOnlyMode` to `true`. This prevents Backup objects from being created or deleted during your Restore process. Create a restore with your most recent Ark Backup: ``` ark restore create --from-backup <SCHEDULE NAME>-<TIMESTAMP> ``` Using Backups and Restores Heptio Ark can help you port your resources from one cluster to another, as long as you point each Ark Config to the same cloud object storage. In this scenario, we are also assuming that your clusters are hosted by the same cloud provider. Note that Heptio Ark does not support the migration of persistent volumes across cloud providers. (Cluster 1) Assuming you haven't already been checkpointing your data with the Ark `schedule` operation, you need to first back up your entire cluster (replacing `<BACKUP-NAME>` as desired): ``` ark backup create <BACKUP-NAME> ``` The default TTL is 30 days (720 hours); you can use the `--ttl` flag to change this as necessary. (Cluster 2) Make sure that the `persistentVolumeProvider` and `backupStorageProvider` fields in the Ark Config match the ones from Cluster 1, so that your new Ark server instance is pointing to the same bucket. (Cluster 2) Make sure that the Ark Backup object has been created. Ark resources are synced with the backup files available in cloud storage. (Cluster 2) Once you have confirmed that the right Backup (`<BACKUP-NAME>`) is now present, you can restore everything with: ``` ark restore create --from-backup <BACKUP-NAME> ```
Project: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.6.md

- https://github.com/heptio/ark/tree/v0.6.0 Plugins* - We now support user-defined plugins that can extend Ark functionality to meet your custom backup/restore needs without needing to be compiled into the core binary. We support pluggable block and object stores as well as per-item backup and restore actions that can execute arbitrary logic, including modifying the items being backed up or restored. For more information see the , which includes a reference to a fully-functional sample plugin repository. (#174 #188 #206 #213 #215 #217 #223 #226) Describers* - The Ark CLI now includes `describe` commands for `backups`, `restores`, and `schedules` that provide human-friendly representations of the relevant API objects. The config object format has changed. In order to upgrade to v0.6.0, the config object will have to be updated to match the new format. See the and for more information. The restore object format has changed. The `warnings` and `errors` fields are now ints containing the counts, while full warnings and errors are now stored in the object store instead of etcd. Restore objects created prior to v.0.6.0 should be deleted, or a new bucket used, and the old restore objects deleted from Kubernetes (`kubectl -n heptio-ark delete restore --all`). Add `ark plugin add` and `ark plugin remove` commands #217, @skriss Add plugin support for block/object stores, backup/restore item actions #174 #188 #206 #213 #215 #223 #226, @skriss @ncdc Improve Azure deployment instructions #216, @ncdc Change default TTL for backups to 30 days #204, @nrb Improve logging for backups and restores #199, @ncdc Add `ark backup describe`, `ark schedule describe` #196, @ncdc Add `ark restore describe` and move restore warnings/errors to object storage #173 #201 #202, @ncdc Upgrade to client-go v5.0.1, kubernetes v1.8.2 #157, @ncdc Add Travis CI support #165 #166, @ncdc Fix log location hook prefix stripping #222, @ncdc When running `ark backup download`, remove file if there's an error #154, @ncdc Update documentation for AWS KMS Key alias support #163, @lli-hiya Remove clock from `volumesnapshotaction` #137, @athampy
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_nat_flush.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Flush all NAT mapping entries ``` cilium-dbg bpf nat flush [flags] ``` ``` -h, --help help for flush ``` ``` --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-dbg_bpf_bandwidth.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> BPF datapath bandwidth settings ``` -h, --help help for bandwidth ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - List BPF datapath bandwidth settings