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

title: Isolating Applications on a Weave Network menu_order: 5 search_type: Documentation A single Weave network can host multiple, isolated applications where each application's containers are able to communicate with each other, but not with the containers of other applications. To isolate applications, you can make use of `isolation-through-subnets` technique. This common strategy is an example of how with Weave Net many of your `on metal` techniques can still be used to deploy applications to a container network. To begin isolating an application (or parts of an application), configure Weave Net's IP allocator to manage multiple subnets. Using , configure multiple subsets: host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 host1$ eval $(weave env) host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1 host2$ eval $(weave env) This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs it to allocate from 10.2.1.0/24 within that, if a specific subnet is not specified. Next, launch the two netcat containers onto the default subnet: host1$ docker run --name a1 -ti weaveworks/ubuntu host2$ docker run --name a2 -ti weaveworks/ubuntu And then to test the isolation, launch a few more containers onto a different subnet: host1$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b1 -ti weaveworks/ubuntu host2$ docker run -e WEAVE_CIDR=net:10.2.2.0/24 --name b2 -ti weaveworks/ubuntu Ping each container to confirm that they can talk to each other, but not to the containers of our first subnet: root@b1:/# ping -c 1 -q b2 PING b2.weave.local (10.2.2.128) 56(84) bytes of data. b2.weave.local ping statistics 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.338/1.338/1.338/0.000 ms root@b1:/# ping -c 1 -q a1 PING a1.weave.local (10.2.1.2) 56(84) bytes of data. a1.weave.local ping statistics 1 packets transmitted, 0 received, 100% packet loss, time 0ms root@b1:/# ping -c 1 -q a2 PING a2.weave.local (10.2.1.130) 56(84) bytes of data. a2.weave.local ping statistics 1 packets transmitted, 0 received, 100% packet loss, time 0ms If required, a container can also be attached to multiple subnets when it is started using: host1$ docker run -e WEAVE_CIDR="net:default net:10.2.2.0/24" -ti weaveworks/ubuntu `net:default` is used to request the allocation of an address from the default subnet in addition to one from an explicitly specified range. Important: Containers must be prevented from capturing and injecting raw network packets - this can be accomplished by starting them with the `--cap-drop net_raw` option. Note: By default docker permits communication between containers on the same host, via their docker-assigned IP addresses. For complete isolation between application containers, that feature needs to be disabled by in the docker daemon configuration. See Also *
Project: CNI-Genie (Runtime / Cloud Native Network)
File: RELEASING.md

A Gomega release is a tagged sha and a GitHub release. To cut a release: Ensure CHANGELOG.md is up to date. Use `git log --pretty=format:'- %s [%h]' HEAD...vX.X.X` to list all the commits since the last release Categorize the changes into Breaking Changes (requires a major version) New Features (minor version) Fixes (fix version) Maintenance (which in general should not be mentioned in `CHANGELOG.md` as they have no user impact) Update GOMEGAVERSION in `gomegadsl.go` Push a commit with the version number as the commit message (e.g. `v1.3.0`) Create a new with the version number as the tag (e.g. `v1.3.0`). List the key changes in the release notes.
Project: Project Calico (Runtime / Cloud Native Network)
File: logging.md

confd logs everything to stdout. You can control the types of messages that get printed by using the `-log-level` flag and corresponding configuration file settings. See the for more details. Example log messages: ```Bash 2013-11-03T19:04:53-08:00 confd[21356]: INFO SRV domain set to confd.io 2013-11-03T19:04:53-08:00 confd[21356]: INFO Starting confd 2013-11-03T19:04:53-08:00 confd[21356]: INFO etcd nodes set to http://etcd0.confd.io:4001, http://etcd1.confd.io:4001 2013-11-03T19:04:54-08:00 confd[21356]: INFO /tmp/myconf2.conf has md5sum ae5c061f41de8895b6ef70803de9a455 should be 50d4ce679e1cf13e10cd9de90d258996 2013-11-03T19:04:54-08:00 confd[21356]: INFO Target config /tmp/myconf2.conf out of sync 2013-11-03T19:04:54-08:00 confd[21356]: INFO Target config /tmp/myconf2.conf has been updated ```
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-openshift.md

title: OpenShift adds a number of security and other enhancements to Kubernetes. In particular, allow the cluster admin to define exactly which permissions are allowed to pods running in the cluster. You will need to define those permissions that allow the Rook pods to run. The settings for Rook in OpenShift are described below, and are also included in the : : Creates the security context constraints and starts the operator deployment : Creates an object store with rgw listening on a valid port number for OpenShift To create an OpenShift cluster, the commands basically include: ```console oc create -f crds.yaml -f common.yaml oc create -f operator-openshift.yaml oc create -f cluster.yaml ``` Configuration required for Openshift is automatically created by the Helm charts, such as the SecurityContextConstraints. See the . To orchestrate the storage platform, Rook requires the following access in the cluster: Create `hostPath` volumes, for persistence by the Ceph mon and osd pods Run pods in `privileged` mode, for access to `/dev` and `hostPath` volumes Host networking for the Rook agent and clusters that require host networking Ceph OSDs require host PIDs for communication on the same node Before starting the Rook operator or cluster, create the security context constraints needed by the Rook pods. The following yaml is found in `operator-openshift.yaml` under `/deploy/examples`. !!! hint Older versions of OpenShift may require `apiVersion: v1`. Important to note is that if you plan on running Rook in namespaces other than the default `rook-ceph`, the example scc will need to be modified to accommodate for your namespaces where the Rook pods are running. To create the scc you will need a privileged account: ```console oc login -u system:admin ``` We will create the security context constraints with the operator in the next section. There are some Rook settings that also need to be adjusted to work in OpenShift. There is an environment variable that needs to be set in the operator spec that will allow Rook to run in OpenShift clusters. `ROOKHOSTPATHREQUIRES_PRIVILEGED`: Must be set to `true`. Writing to the hostPath is required for the Ceph mon and osd pods. Given the restricted permissions in OpenShift with SELinux, the pod must be running privileged in order to write to the hostPath volume. ```yaml name: ROOKHOSTPATHREQUIRES_PRIVILEGED value: "true" ``` Now create the security context constraints and the operator: ```console oc create -f operator-openshift.yaml ``` The cluster settings in `cluster.yaml` are largely isolated from the differences in OpenShift. There is perhaps just one to take note of: `dataDirHostPath`: Ensure that it points to a valid, writable path on the host systems. In OpenShift, ports less than 1024 cannot be bound. In the , ensure the port is modified to meet this requirement. ```yaml gateway: port: 8080 ``` You can expose a different port such as `80` by creating a service. A sample object store can be created with these settings: ```console oc create -f object-openshift.yaml ```
Project: Virtual Kubelet (Runtime / Container Runtime)
File: setup.md

title: Setup description: Install Virtual Kubelet using one of several methods weight: 1 You can install Virtual Kubelet by building it . First, make sure that you have a set. Then clone the Virtual Kubelet repository and run `make build`: ```bash mkdir -p ${GOPATH}/src/github.com/virtual-kubelet cd ${GOPATH}/src/github.com/virtual-kubelet git clone https://github.com/virtual-kubelet/virtual-kubelet cd virtual-kubelet && make build ``` This method adds a `virtual-kubelet` executable to the `bin` folder. To run it: ```bash bin/virtual-kubelet ``` Once you have Virtual Kubelet installed, you can move on to the documentation.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_encrypt.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage transparent encryption ``` -h, --help help for encrypt ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Flushes the current IPsec state - Display the current encryption state
Project: Kata Containers (Runtime / Container Runtime)
File: Release-Process.md

This document lists the tasks required to create a Kata Release. GitHub permissions to run workflows. The Kata Containers project uses for all releases. Semantic versions are comprised of three fields in the form: ``` MAJOR.MINOR.PATCH ``` When `MINOR` increases, the new release adds new features but without changing the existing behavior. When `MAJOR` increases, the new release adds new features, bug fixes, or both and which changes the behavior from the previous release (incompatible with previous releases). A major release will also likely require a change of the container manager version used, -for example Containerd or CRI-O. Please refer to the release notes for further details. Important : the Kata Containers project doesn't have stable branches (see for details). Bug fixes are released as part of `MINOR` or `MAJOR` releases only. `PATCH` is always `0`. When the `kata-containers/kata-containers` repository is ready for a new release, first create a PR to set the release in the `VERSION` file and have it merged. We make use of in the file from the `kata-containers/kata-containers` repository to build and upload release artifacts. The action is manually triggered and is responsible for generating a new release (including a new tag), pushing those to the `kata-containers/kata-containers` repository. The new release is initially created as a draft. It is promoted to an official release when the whole workflow has completed successfully. Check the [actions status page](https://github.com/kata-containers/kata-containers/actions) to verify all steps in the actions workflow have completed successfully. On success, a static tarball containing Kata release artifacts will be uploaded to the [Release page](https://github.com/kata-containers/kata-containers/releases). If the workflow fails because of some external environmental causes, e.g. network timeout, simply re-run the failed jobs until they eventually succeed. If for some reason you need to cancel the workflow or re-run it entirely, go first to the and delete the draft release from the previous run. Release notes are auto-generated by the GitHub CLI tool used as part of our release workflow. However, some manual tweaking may still be necessary in order to highlight the most important features and bug fixes in a specific release. With this in mind, please, poke @channel on #kata-dev and people who worked on the release will be able to contribute to that. Publish in [Slack and Kata mailing list](https://github.com/kata-containers/community#join-us) that new release is ready.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup_logs.md

title: "ark backup logs" layout: docs Get backup logs Get backup logs ``` ark backup logs BACKUP [flags] ``` ``` -h, --help help for logs --timeout duration how long to wait to receive logs (default 1m0s) ``` ``` --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 backups
Project: Kilo (Runtime / Cloud Native Network)
File: monitoring.md

The following assumes that you have applied the monitoring stack onto your cluster. Monitor the Kilo DaemonSet with: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/podmonitor.yaml ``` Monitor the WireGuard interfaces with: ```shell kubectl create ns kilo kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/wg-exporter.yaml ``` The manifest will deploy the as a DaemonSet and a . By default the kube-prometheus stack only monitors the `default`, `kube-system` and `monitoring` namespaces. In order to allow Prometheus to monitor the `kilo` namespace, apply the Role and RoleBinding with: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/wg-exporter-role-kube-prometheus.yaml ``` Kilo exports some standard metrics with the Prometheus GoCollector and ProcessCollector. It also exposes some Kilo-specific metrics. ``` ``` The exports the following metrics: ``` ``` If your laptop is a Kilo peer of the cluster you can access the Prometheus UI by navigating your browser directly to the cluster IP of the `prometheus-k8s` service. Otherwise use `port-forward`: ```shell kubectl -n monitoring port-forward svc/prometheus-k8s 9090 ``` and navigate your browser to `localhost:9090`. Check if you can see the PodMonitors for Kilo and the WireGuard Exporter under Status -> Targets in the Prometheus web UI. If you don't see them, check the logs of the `prometheus-k8s` Pods; it may be that Prometheus doesn't have the permission to get Pods in the `kilo` namespace. In this case, you need to apply the Role and RoleBinding from above. Navigate to Graph and try to execute a simple query, e.g. type `kilo_nodes` and click on `execute`. You should see some data. Let's navigate to the Grafana dashboard. Again, if your laptop is not a Kilo peer, use `port-forward`: ```shell kubectl -n monitoring port-forward svc/grafana 3000 ``` Now navigate your browser to `localhost:3000`. The default user and password is `admin` `admin`. An example configuration for a dashboard displaying Kilo metrics can be found . You can import this dashboard by hitting + -> Import on the Grafana dashboard. The dashboard looks like this: <img src="./graphs/kilo.png" />
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-bugtool_completion.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Generate the autocompletion script for the specified shell Generate the autocompletion script for cilium-bugtool for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` - Collects agent & system information useful for bug reporting - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: Curve (Runtime / Cloud Native Storage)
File: CHANGELOG-1.2.md

Previous change logs can be found at Optimize ansible script, optimize build script, optimize log printing. Translate some document and code comment from chinese to english. Add a script for k8s to attach curve volume. curveopstool improve: - Hardware: 6 nodes, each with: 20x SATA SSD Intel SSD DC S3500 Series 800G 2x Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz 2x Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection, bond mode is 802.3ad with layer2+3 hash policy 251G RAM Performance test is based on curve-nbd, the size of each block device is 200GB, all configurations are default, and each Chunkserver is deployed on one SSD. 1 NBD block device: | item | iops/bandwidth | avg-latency | 99th-latency | striped volume<br>iops/bandwidth | striped volume<br>avg-latency | striped volume<br>99th-latency | | :-: | :-: | :-: | :-: | :-: |:-: |:-: | | 4K randwrite, 128 depth | 97,700 iops | 1.3 ms | 2.0 ms | 97,100 iops | 1.3 ms | 3.0 ms | | 4K randread, 128 depth | 119,000 iops | 1.07 ms | 1.8 ms | 98,000 iops | 1.3 ms | 2.2 ms | | 512K write, 128 depth | 208 MB/s | 307 ms | 347 ms | 462 MB/s | 138 ms | 228 ms | | 512K read, 128 depth | 311 MB/s | 206 ms | 264 ms | 843 MB/s | 75 ms | 102 ms | 10 NBD block device: | item | iops/bandwidth | avg-latency | 99th-latency | striped volume<br>iops/bandwidth | striped volume<br>avg-latency | striped volume<br>99th-latency | | :-: | :-: | :-: | :-: | :-: |:-: |:-: | | 4K randwrite, 128 depth | 231,000 iops | 5.6 ms | 50 ms | 227,000 iops | 5.9 ms | 53 ms | | 4K randread, 128 depth | 350,000 iops | 3.7 ms | 8.2 ms | 345,000 iops | 3.8 ms | 8.2 ms | | 512K write, 128 depth | 805 MB/s | 415 ms | 600 ms | 1,077 MB/s | 400 ms | 593 ms | | 512K read, 128 depth | 2,402 MB/s | 267 ms | 275 ms | 3,313 MB/s | 201 ms | 245 ms | <hr/> <hr/>
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup_delete.md

title: "ark backup delete" layout: docs Delete a backup Delete a backup ``` ark backup delete NAME [flags] ``` ``` --confirm Confirm deletion -h, --help help for delete ``` ``` --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 backups
Project: Kuasar (Runtime / Container Runtime)
File: containerd.md

Kuasar has make some changes on official containerd v1.7.0 based on commit:`1f236dc57aff44eafd95b3def26683a235b97241`. Please note that for compatibility with Containerd, it is recommended to use Go version 1.19 or later. `git` clone the codes of containerd fork version from kuasar repository. ```bash git clone https://github.com/kuasar-io/containerd.git cd containerd make make install ``` Refer to the following configuration to modify the configuration file, default path is `/etc/containerd/config.toml`. Important!!!: AppArmor feature is not support now, you need update `disable_apparmor = true` in the config file. For vmm: ```toml [proxy_plugins.vmm] type = "sandbox" address = "/run/vmm-sandboxer.sock" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.vmm] runtime_type = "io.containerd.kuasar.v1" sandboxer = "vmm" io_type = "hvsock" ``` For quark: ```toml [proxy_plugins.quark] type = "sandbox" address = "/run/quark-sandboxer.sock" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.quark] runtime_type = "io.containerd.quark.v1" sandboxer = "quark" ``` For wasm: ```toml [proxy_plugins.wasm] type = "sandbox" address = "/run/wasm-sandboxer.sock" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasm] runtime_type = "io.containerd.wasm.v1" sandboxer = "wasm" ``` To start containerd, run `ENABLECRISANDBOXES=1 containerd` In order to use the containerd Sandbox API, the containerd daemon should be started with the environment variable `ENABLECRISANDBOXES=1`.
Project: CubeFS (Runtime / Cloud Native Storage)
File: cluster.md

Get cluster information, including cluster name, address, number of volumes, number of nodes, and usage rate, etc. ```bash cfs-cli cluster info ``` Get usage, status, etc. of metaNodes and dataNodes by region. ```bash cfs-cli cluster stat ``` Freeze the cluster. After setting it to `true`, when the partition is full, the cluster will not automatically allocate new partitions. ```bash cfs-cli cluster freeze [true/false] ``` Set the memory threshold for each MetaNode in the cluster. If the memory usage reaches this threshold, all the metaPartition will be readOnly. [float] should be a float number between 0 and 1. ```bash cfs-cli cluster threshold [float] ``` Set the `volDeletionDelayTime` configuration, measured in hours, which represents the number of hours after enabling delayed volume deletion when the volume will be permanently deleted. Prior to that, it will be marked for deletion and can be recovered. default is 48 hours. ```bash cfs-cli cluster volDeletionDelayTime [VOLDELETIONDELAYTIME] ``` Set the configurations of the cluster. ```bash cfs-cli cluster set [flags] ``` ```bash Flags: --autoRepairRate string DataNode auto repair rate --batchCount string MetaNode delete batch count --deleteWorkerSleepMs string MetaNode delete worker sleep time with millisecond. if 0 for no sleep -h, --help help for set --loadFactor string Load Factor --markDeleteRate string DataNode batch mark delete limit rate. if 0 for no infinity limit --maxDpCntLimit string Maximum number of dp on each datanode, default 3000, 0 represents setting to default ```
Project: gVisor (Runtime / Container Runtime)
File: knative.md

is a platform for running serverless workloads on Kubernetes. This guide will show you how to run basic Knative workloads in gVisor. This guide assumes you have have a cluster that is capable of running gVisor workloads. This could be a enabled cluster on Google Cloud Platform or one you have set up yourself using . This guide will also assume you have Knative installed using as the network layer. You can follow the to install Knative. Knative allows the use of various parameters on Pods via . We will enable the feature flag to enable the use of the Kubernetes . Edit the feature flags ConfigMap. ```bash kubectl edit configmap config-features -n knative-serving ``` Add the `kubernetes.podspec-runtimeclassname: enabled` to the `data` field. Once you are finished the ConfigMap will look something like this (minus all the system fields). ```yaml apiVersion: v1 kind: ConfigMap metadata: name: config-features namespace: knative-serving labels: serving.knative.dev/release: v0.22.0 data: kubernetes.podspec-runtimeclassname: enabled ``` After you have set the Runtime Class feature flag you can now create Knative services that specify a `runtimeClassName` in the spec. ```bash cat <<EOF | kubectl apply -f - apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go spec: template: spec: runtimeClassName: gvisor containers: image: gcr.io/knative-samples/helloworld-go env: name: TARGET value: "gVisor User" EOF ``` You can see the pods running and their Runtime Class. ```bash kubectl get pods -o=custom-columns='NAME:.metadata.name,RUNTIME CLASS:.spec.runtimeClassName,STATUS:.status.phase' ``` Output should look something like the following. Note that your service might scale to zero. If you access it via it's URL you should get a new Pod. ``` NAME RUNTIME CLASS STATUS helloworld-go-00002-deployment-646c87b7f5-5v68s gvisor Running ``` Congrats! Your Knative service is now running in gVisor!