cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Net (Runtime / Cloud Native Network)
File: k8s-src-ip.md

Weave Net: v2.2.1. Kubernetes: v1.10.0. kube-proxy: iptables/ipvs mode with `--masquerade-all=false` and `--cluster-cidr` unspecified(default kubeadm options). Hosts: `h1` and `h2`. \# | Src | Target | Dst | Src IP | `-j WEAVE-NPC` |-|-|--||-- 1 | Podh1 | ip(Podh2) | Podh2 | ip(Podh1) | OK 2 | h1 | ClusterIP | Podh1 | ip(weaveh1) | NOK 3 | h1 | ClusterIP | Podh2 | ip(weaveh1) | OK 4 | Podh1 | ClusterIP | Podh1 | ip(Pod_h1) | OK 5 | Podh1 | ClusterIP | Podh2 | ip(weave_h1) | OK 6 | h1 | ip(h1):NodePort | Podh1 | ip(weaveh1) | NOK 7 | h1 | ip(h1):NodePort | Podh2 | ip(weaveh1) | OK 8 | h1 | ip(h2):NodePort | Podh1 | ip(weaveh2) | OK 9 | h1 | ip(h2):NodePort | Podh2 | ip(weaveh2) | ??? Can't reproduce 10 | Podh1 | ip(h1):NodePort | Podh1 | ip(weave_h1) | NOK 11 | Podh1 | ip(h1):NodePort | Podh2 | ip(weave_h1) | OK 12 | Podh1 | ip(h2):NodePort | Podh1 | ip(weave_h2) | OK 13 | Podh1 | ip(h2):NodePort | Podh2 | ip(weave_h2) | OK Remarks: Src IP* is of a packet which is captured on the weave bridge. -j WEAVE-NPC* - whether a packet enters the `filter/WEAVE-NPC` iptables chain (OK = NetworkPolicy is enforced as required). Pod_h1* - a Pod running on the `h1` host. ip(weave_h1)* - IP addr of the weave bridge on the `h1` host.
Project: CNI-Genie (Runtime / Cloud Native Network)
File: CNIGenieFeatureSet.md

Feature 1: CNI-Genie "Multiple CNI Plugins" Interface Connector to 3rd party CNI-Plugins. The user can Feature 2: CNI-Genie "Multiple IP Addresses" Injects multiple IPs to a single container. The container is reachable using any of the Feature 3: CNI-Genie "Network Attachment Definition" feature incorporates Kubernetes Network Custom Resource Definition De-facto Standard in CNI-Genie Feature 4: CNI-Genie "Smart CNI Plugin Selection" Intelligence in selecting the CNI plugin. CNI-Genie the CNI plugin, accordingly Feature 5: CNI-Genie "Default Plugin Selection" Support to set default plugin of user choice to be used for all the pods being created Feature 6: CNI-Genie "Network Isolation" Dedicated 'physical' network for a tenant Isolated 'logical' networks for different tenants on a shared 'physical'network Feature 7: CNI-Genie "Network Policy Engine" allows for network level ACLs Feature 8: CNI-Genie "Real-time Network Switching" Price minimization: dynamically switching workload to a cheaper network as network prices change Maximizing network utilization: dynamically switching workload to the less congested network at a threshold
Project: Flannel (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

CoreOS projects are and accept contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted. By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the file for details. Fork the repository on GitHub Read the for build and test instructions Play with the project, submit bugs, submit patches! This is a rough outline of what a contributor's workflow looks like: Create a topic branch from where you want to base your work (usually master). Make commits of logical units. Make sure your commit messages are in the proper format (see below). Push your changes to a topic branch in your fork of the repository. Make sure the tests pass, and add any new tests as appropriate. Submit a pull request to the original repository. Thanks for your contributions! We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why. ``` scripts: add the test-cluster command this uses tmux to setup a test cluster that you can easily kill and start for debugging. Fixes #38 ``` The format can be described more formally as follows: ``` <subsystem>: <what changed> <BLANK LINE> <why this change was made> <BLANK LINE> <footer> ``` The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters. This allows the message to be easier to read on GitHub as well as in various git tools.
Project: Kilo (Runtime / Cloud Native Network)
File: CONDUCT.md

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

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Update vtep entries Create/Update vtep entry. ``` cilium-dbg bpf vtep update [flags] ``` ``` -h, --help help for update ``` ``` --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: Kata Containers (Runtime / Container Runtime)
File: what-is-vm-templating-and-how-do-I-use-it.md

VM templating is a Kata Containers feature that enables new VM creation using a cloning technique. When enabled, new VMs are created by cloning from a pre-created template VM, and they will share the same initramfs, kernel and agent memory in readonly mode. It is very much like a process fork done by the kernel but here we fork VMs. Both and VM templating help speed up new container creation. When VMCache enabled, new VMs are created by the VMCache server. So it is not vulnerable to share memory CVE because each VM doesn't share the memory. VM templating saves a lot of memory if there are many Kata Containers running on the same host. VM templating helps speed up new container creation and saves a lot of memory if there are many Kata Containers running on the same host. If you are running a density workload, or care a lot about container startup speed, VM templating can be very useful. In one example, we created 100 Kata Containers each claiming 128MB guest memory and ended up saving 9GB of memory in total when VM templating is enabled, which is about 72% of the total guest memory. See [full results here](https://github.com/kata-containers/runtime/pull/303#issuecomment-395846767). In another example, we created ten Kata Containers with containerd shimv2 and calculated the average boot up speed for each of them. The result showed that VM templating speeds up Kata Containers creation by as much as 38.68%. See . One drawback of VM templating is that it cannot avoid cross-VM side-channel attack such as that originally targeted at the Linux KSM feature. It was concluded that "Share-until-written approaches for memory conservation among mutually untrusting tenants are inherently detectable for information disclosure, and can be classified as potentially misunderstood behaviors rather than vulnerabilities." Warning: If you care about such attack vector, do not use VM templating or KSM. VM templating can be enabled by changing your Kata Containers config file (`/usr/share/defaults/kata-containers/configuration.toml`, overridden by `/etc/kata-containers/configuration.toml` if provided) such that: `qemu` version `v4.1.0` or above is specified in `hypervisor.qemu`->`path` section `enable_template = true` `initrd =` is set `image =` option is commented out or removed `shared_fs` should not be `virtio-fs` Then you can create a VM templating for later usage by calling ``` $ sudo kata-runtime factory init ``` and purge it by calling ``` $ sudo kata-runtime factory destroy ``` If you do not want to call `kata-runtime factory init` by hand, the very first Kata container you create will automatically create a VM templating.
Project: rkt (Runtime / Container Runtime)
File: attach.md

Applications can be started in interactive mode and later attached via `rkt attach`. In order for an application to be attachable: it must be started in interactive mode it must be running as part of a running pod it must support the corresponding attach mode To start an application in interactive mode, either `tty` or `stream` must be passed as value for the `--stdin`, `--stdout` and `--stderr` options. An application can be run with a dedicated terminal and later attached to: ``` ``` ``` / # hostname rkt-911afe8e-992f-4089-8666-4a4c957a1964 / # tty /rkt/iottymux/alpine-sh/pts ^C ``` In a similar way, an application can be run without a tty but with separated attachable streams: ``` ``` ``` hostname rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c tty not a tty ^C ``` If a pod contains multiple applications, the one to be used as attach target can be specified via `--app`. The following options are allowed as `--mode` values: `list`: list available endpoints, and return early without attaching `auto`: attach to all available endpoints `tty`: bi-directionally attach to the application terminal `tty-in` or `tty-out`: uni-directionally attach to the application terminal `stdin,stdout,stderr`: attach to specific application streams. Omitted streams will no be attached A more complex example, showing the usage of advanced options and piping: ``` ``` ``` stdin stdout stderr rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c /bin/sh: fakecmd: not found ^C rkt-846c35db-6728-471a-ad50-66d3a8d7ff9c ^C /bin/sh: fakecmd: not found ^C ``` | Flag | Default | Options | Description | | | | | | | `--app` | `` | Name of an application | Name of the app to attach to within the specified pod | | `--mode` | `auto` | "list", "auto" or tty/stream mode | Attaching mode | See the table with .
Project: MinIO (Runtime / Cloud Native Storage)
File: opa.md

OPA is a lightweight general-purpose policy engine that can be co-located with MinIO server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts). OPA is enabled through MinIO's Access Management Plugin feature. ```sh podman run -it \ --name opa \ --publish 8181:8181 \ docker.io/openpolicyagent/opa:0.40.0-rootless \ run --server \ --log-format=json-pretty \ --log-level=debug \ --set=decision_logs.console=true ``` In another terminal, create a policy that allows root user all access and for all other users denies `PutObject`: ```sh cat > example.rego <<EOF package httpapi.authz import input default allow = false allow { input.owner == true } allow { input.action != "s3:PutObject" input.owner == false } EOF ``` Then load the policy via OPA's REST API. ``` curl -X PUT --data-binary @example.rego \ localhost:8181/v1/policies/putobject ``` Set the `MINIOPOLICYPLUGIN_URL` as the endpoint that MinIO should send authorization requests to. Then start the server. ```sh export MINIOPOLICYPLUGIN_URL=http://localhost:8181/v1/data/httpapi/authz/allow export MINIOCICD=1 export MINIOROOTUSER=minio export MINIOROOTPASSWORD=minio123 minio server /mnt/data ``` Ensure that `mc` is installed and the configured with the above server with the alias `myminio`. ```sh mc mb myminio/test mc admin user add myminio foo foobar123 mc cp /etc/issue myminio/test/ export MCHOSTfoo=http://foo:foobar123@localhost:9000 mc ls foo/test mc cat foo/test/issue mc cp /etc/issue myminio/test/issue2 ```
Project: CRI-O (Runtime / Container Runtime)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Weave Net (Runtime / Cloud Native Network)
File: plugin-how-it-works.md

title: How the Weave Net Docker Network Plugins Work menu_order: 10 search_type: Documentation The Weave Net legacy plugin actually provides two network drivers to Docker - one named `weavemesh` that can operate without a cluster store and another one named `weave` that can only work with one (like Docker's overlay driver), while the V2 plugin provides one - `weaveworks/net-plugin:latest_release` operating only in swarm mode. Weave Net handles all co-ordination between hosts (referred to by Docker as a "local scope" driver) Supports a single network only. A network named `weave` is automatically created for you. Uses Weave Net's partition tolerant IPAM If you do create additional networks using the `weavemesh` driver, containers attached to them will be able to communicate with containers attached to `weave`. There is no isolation between those networks. This runs in what Docker calls "global scope", which requires an external cluster store Supports multiple networks that must be created using `docker network create --driver weave ...` Used with Docker's cluster-store-based IPAM There's no specific documentation from Docker on using a cluster store, but the first part of is a good place to start. Note: In the case of multiple networks using the `weave` driver, all containers are on the same virtual network but Docker allocates their addresses on different subnets so they cannot talk to each other directly. The plugin accepts the following options via `docker network create ... --opt`: `works.weave.multicast` -- tells weave to add a static IP route for multicast traffic onto its interface. Note: If you connect a container to multiple Weave networks, at most one of them can have the multicast route enabled. The `weave` network created when the plugin is first launched has the multicast option turned on, but for any networks you create it defaults to off. The driver runs within the plugin V2. Requires Docker to run in . Supports multiple networks. Used with Docker's IPAM. See Also *
Project: Weave Net (Runtime / Cloud Native Network)
File: automatic-discovery-proxy.md

title: Using Automatic Discovery With the Weave Net Proxy menu_order: 40 search_type: Documentation Containers launched via the proxy use automatically if it is running when they are started - see the section for an in depth explanation of the behaviour and how to control it. Typically, the proxy passes on container names as-is to weaveDNS for registration. However, there are situations in which the final container name may be out of your control (for example, if you are using Docker orchestrators which append control/namespacing identifiers to the original container names). For those situations, the proxy provides the following flags: `--hostname-from-label<labelkey>` `--hostname-match <regexp>` `--hostname-replacement <replacement>` When launching a container, the hostname is initialized to the value of the container label using key `<labelkey>`. If no `<labelkey>` was provided, then the container name is used. Additionally, the hostname is matched against a regular expression `<regexp>` and based on that match, `<replacement>` is used to obtain the final hostname, and then handed over to weaveDNS for registration. For example, you can launch the proxy using all three flags, as follows: host1$ weave launch --hostname-from-label hostname-label --hostname-match '^aws-[0-9]+-(.*)$' --hostname-replacement 'my-app-$1' host1$ eval $(weave env) Note: regexp substitution groups must be pre-pended with a dollar sign (for example, `$1`). For further details on the regular expression syntax see . After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weaveDNS registering the hostname `my-app-foo` and not `aws-12798186823-foo`. host1$ docker run -ti --name=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data. 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.067 ms Also, running a container named `foo` with the label `hostname-label=aws-12798186823-foo` leads to the same hostname registration. host1$ docker run -ti --name=foo --label=hostname-label=aws-12798186823-foo weaveworks/ubuntu ping my-app-foo PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data. 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from my-app-foo.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.042 ms This is because, as explained above, if providing `--hostname-from-label` to the proxy, the specified label takes precedence over the container's name. See Also *
Project: Virtual Kubelet (Runtime / Container Runtime)
File: DEBUGGING.md

Debugging virtual-kubelet ========================= Not implemented. virtual-kubelet uses to record traces. These traces include requests on the HTTP API as well as the reconciliation loop which reconciles virtual-kubelet pods with what's in the Kubernetes API server. The granularity of traces may depend on the service provider (e.g. `azure`, `aws`, etc) being used. Traces are collected and then exported to any configured exporter. Built-in exporters currently include: `jaeger` - , supports configuration through environment variables. `JAEGER_ENDPOINT` - Jaeger HTTP Thrift endpoint, e.g. `http://localhost:14268` `JAGERAGENTENDPOINT` - Jaeger agent address, e.g. `localhost:6831` `JAEGER_USER` `JAEGER_PASSWORD` `zpages` - . Currently supports configuration through environment variables, but this interface is not considered stable. ZPAGES_PORT - e.g. `localhost:8080` sets the address to setup the HTTP server to serve zpages on. Will be available at `http://<address>:<port>/debug/tracez` If consuming virtual-kubelet as a library you can configure your own tracing exporter. Traces propagated from other services must be propagated using Zipkin's B3 format. Other formats may be supported in the future. `--trace-exporter` - Sets the exporter to use. Multiple exporters can be specified. If this is unset, traces are not exported. `--trace-service-name` - Sets the name of the service, defaults to `virtual-kubelet` but can be anything. This value is passed to the exporter purely for display purposes. `--trace-tag` - Adds tags in a `<key>=<value>` form which is included with collected traces. Think of this like log tags but for traces. `--trace-sample-rate` - Sets the probability for traces to be recorded. Traces are considered an expensive operation so you may want to set this to a lower value. Range is a value of 0 to 100 where 0 is never trace and 100 is always trace.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_identity_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List identities ``` cilium-dbg identity list [LABELS] [flags] ``` ``` --endpoints list identities of locally managed endpoints -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 security identities
Project: Carina (Runtime / Cloud Native Storage)
File: pvc-device.md

Creating storageclass `kubectl apply -f storageclass.yaml` ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-carina-sc provisioner: carina.storage.io parameters: csi.storage.k8s.io/fstype: xfs carina.storage.io/disk-group-name: hdd reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer mountOptions: ``` Creating PVC `kubectl apply -f pvc.yaml` ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: raw-block-pvc namespace: carina spec: accessModes: ReadWriteOnce volumeMode: Block resources: requests: storage: 13Gi storageClassName: csi-carina-sc ``` Checking the LV object. ```shell $ kubectl get lv NAME SIZE GROUP NODE STATUS pvc-319c5deb-f637-423b-8b52-42ecfcf0d3b7 7Gi carina-vg-hdd 10.20.9.154 Success ``` mount volume as block in pod`kubectl apply -f pod.yaml` ```yaml apiVersion: v1 kind: Pod metadata: name: carina-block-pod namespace: carina spec: containers: name: centos securityContext: capabilities: add: ["SYS_RAWIO"] image: centos:latest imagePullPolicy: "IfNotPresent" command: ["/bin/sleep", "infinity"] volumeDevices: name: data devicePath: /dev/xvda volumes: name: data persistentVolumeClaim: claimName: raw-block-pvc ```