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

title: Uniform Fixed Clusters menu_order: 30 search_type: Documentation This scenario describes a production deployment of a fixed number of N nodes (N=1 in the simplest case). A uniform fixed cluster has the following characteristics: Recovers automatically from reboots and partitions. All peers have identical configuration. There is a controlled process for adding or removing nodes, however the end user is responsible for ensuring that only one instance of the process is in-flight at a time. While it is possible to automate, the potentially-blocking `weave prime` operation and the need for global serialization make it non-trivial. It is however relatively straightforward for a human to provide the necessary guarantees and exception handling manually, and so this scenario is best suited to deployments which change size infrequently as a planned maintenance event. On each initial peer, at boot, via : weave launch --no-restart $PEERS Where, `--no-restart` disables the Docker restart policy, since this will be handled by systemd. `$PEERS` is obtained from `/etc/sysconfig/weave` as described in the linked systemd documentation. For convenience, this may contain the address of the peer which is being launched, so that you don't have to compute separate lists of 'other' peers tailored to each peer - just supply the same complete list of peer addresses to every peer. Then on any peer run the following to force consensus: weave prime Note: You can run this safely on more than one or even all peers, but it's only strictly necessary to run it on one of them. Once this command completes successfully, IP address allocations can proceed under partition and it is safe to add new peers. If this command waits without exiting, it means that there is an issue (such as a network partition or failed peers) that is preventing a quorum from being reached you will need to [address that](/site/troubleshooting.md) before moving on. On the new peer, at boot, via run: weave launch --no-restart $PEERS Where, `$PEERS` is the new peer plus all other peers in the network, initial and subsequently added, which have not been explicitly removed. It should include peers which are temporarily offline or stopped. For maximum robustness, distribute an updated `/etc/sysconfig/weave` file including the new peer to all existing peers. On the peer to be removed: weave reset Then distribute an updated `/etc/sysconfig/weave` to the remaining peers, omitting the removed peer from `$PEERS`. On each remaining peer: weave forget <removed peer> This final step is not mandatory, but it will eliminate log noise and spurious network traffic by stopping any reconnection attempts.
Project: Inclavare Containers (Runtime / Container Runtime)
File: running_inclavare_containers_with_pouch_and_occlum.md

This user guide provides the steps to run inclavare-containers with pouch and Occlum. Please refer to to install pouch and refer to to configure the runtime of pouchd. Please refer to to install `rune`. Please refer to to install `shim-rune` and refer to to configure `shim-rune`. Please refer to to build your Occlum container image. Use the environment variable OCCLUMRELEASEENCLAVE to specify your enclave type OCCLUMRELEASEENCLAVE=0: debug enclave OCCLUMRELEASEENCLAVE=1: product enclave Then run pouch with Occlum container images refer to ```shell pouch run -it --rm --runtime=rune \ -e ENCLAVE_TYPE=intelSgx \ -e ENCLAVERUNTIMEPATH=/opt/occlum/build/lib/libocclum-pal.so \ -e ENCLAVERUNTIMEARGS=occlum_instance \ -e ENCLAVERUNTIMELOGLEVEL=info \ -e OCCLUMRELEASEENCLAVE=0 \ occlum-app ``` In addition, pouch supports to configure `annotation` options to run container image. You can run pouch with annotations instead of environment variables. ```shell pouch run -it --rm --runtime=rune \ --annotation "enclave.type=intelSgx" \ --annotation "enclave.runtime.path=/opt/occlum/build/lib/libocclum-pal.so" \ --annotation "enclave.runtime.args=occlum_instance" \ --annotation "enclave.runtime.loglevel=info" \ -e OCCLUMRELEASEENCLAVE=0 \ occlum-app ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_subscriber_add.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Add a remote subscriber to the multicast group. Add a remote subscriber to the multicast group. Only remote subscribers are added via command line. Local subscribers will be automatically populated in the map based on IGMP messages. Remote subscribers are typically other Cilium nodes, identified by internal IP of the node. To add remote subscriber, following information is required: group: multicast group address to which subscriber is added. subscriber-address: subscriber IP address. ``` cilium-dbg bpf multicast subscriber add <group> <subscriber-address> [flags] ``` ``` To add a remote node 10.100.0.1 to multicast group 229.0.0.1, use the following command: cilium-dbg bpf multicast subscriber add 229.0.0.1 10.100.0.1 ``` ``` -h, --help help for add ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage the multicast subscribers.
Project: MinIO (Runtime / Cloud Native Storage)
File: ISSUE_TEMPLATE.md

name: Bug report about: Create a report to help us improve title: '' labels: community, triage assignees: '' All GitHub issues are addressed on a best-effort basis at MinIO's sole discretion. There are no Service Level Agreements (SLA) or Objectives (SLO). Remember our when engaging with MinIO Engineers and the larger community. For urgent issues (e.g. production down, etc.), subscribe to for direct to engineering support. <! Provide a general summary of the issue in the Title above --> <! If you're describing a bug, tell us what should happen --> <! If you're suggesting a change/improvement, tell us how it should work --> <! If describing a bug, tell us what happens instead of the expected behavior --> <! If suggesting a change/improvement, explain the difference from current behavior --> <! Not obligatory, but suggest a fix/reason for the bug, --> <! or ideas how to implement the addition or change --> <! Provide a link to a live example, or an unambiguous set of steps to --> <! reproduce this bug. Include code to reproduce, if relevant --> <! and make sure you have followed https://github.com/minio/minio/tree/release/docs/debugging to capture relevant logs --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <!-- Is this issue a regression? (Yes / No) --> <!-- If Yes, optionally please include minio version or commit id or PR# that caused this regression, if you have these details. --> <! Include as many relevant details about the environment you experienced the bug in --> Version used (`minio --version`): Server setup and configuration: Operating System and version (`uname -a`):
Project: Kuasar (Runtime / Container Runtime)
File: Benchmark.md

This repository contains all the scripts, source code and data. The benchmarking is divided into two groups: Kuasar and Kata. In order to control variables consistently, we use: same versions of cloud-hypervisor and guest-kernel same container image: docker.io/library/ubuntu:latest all pods are created using the hostNetwork mode, which means that CNI plugins are not used the container root filesystem storage driver uses overlayfs Performance Metrics: memory overhead & startup time memory overhead: Start 1/5/10/20/30/50 podsmeasure the Pss of Kuasar's sandboxer process and the total Pss of all `containerd-shim-kata-v2` processes. The Pss is obtained from the smaps_rollup file under the `/proc` dictionary. Measure three times and take the average value. startup time: The container startup time (including pod startup time) measured end-to-end through CRI. The testing is divided into two groups, one launching a single pod and the other launching 30 pods in parallel. Every group runs 500 times and obtains CDF data. | | version | ||-| | Contained | v1.7.0 | | Kata | v2.5.2 | | Operation System | centOS 8 | | Cloud-Hypervisor | v28.2 | | Guest-kernel | 6.1.6 | ```bash ENABLECRISANDBOXES=1 ./contained -l=info ``` ```bash ~/kuasar/vmm/target/x86_64-unknown-linux-musl/release/vmm-sandboxer --listen /run/kuasar-sandboxer.sock --dir /var/lib/kuasar ``` There are a bunch of scripts in `./scripts`. They assume you are in the `./scripts` directory when you run them. ```bash cd ./scripts ``` Time tests ```bash sh boot-serial-kuasar-time.sh ``` In `./data/raw` we could get the `.dat` file as the result of the script we run just now. For example `boot-serial-1000-kuasar-time.dat`. Then we use the command below to generate cdf file: ```bash ./utilgencdf.py ../data/raw/boot-serial-1000-kuasar-time.dat ../data/boot-serial-1000-kuasar-time-cdf.dat ``` Memory tests ```bash sh kuasar-mem-test.sh ``` Measure three times, record the result and take the average value. We use gnuplot to generate graph. Make sure that your `.dat` files and `.gpl` scripts are in the same dictionary. Or you can modify the `.gpl` scripts to specify the path and name of the `.dat` files. Run the `.gpl` script, and you will get the PDF file. Figure1: Cumulative distribution of wall-clock times for starting container in serial, for Kata and Kuasar. The boot time of Kata is about 850~950 ms while Kuasar is only 300~360 ms, which less than half of Kata. Figure2: Cumulative distribution of wall-clock times for starting containers in groups of 50 in parallel, for Kata and Kuasar. The boot time of Kata is about 1600~1800 ms while Kuasar is only 930~1050 ms, which nearly half of Kata. Figure3: Memory overhead (Pss) for Kuasar's sandboxer process and all the processes of Kata-shim. With the number of pods increases, the memory overhead of Kuasar's sandboxer grows very slowly.When the number of pods comes to 50, Pss is only about 15 MB. On the other hand, the average Pss of each pods for Kata is about 18 MB, which significantly higher than Kuasar.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_preflight.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Cilium upgrade helper CLI to help upgrade cilium ``` -h, --help help for preflight ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Prepare for DNS Polling upgrades to cilium 1.4 - Migrate KVStore-backed identities to kubernetes CRD-backed identities - Validate Cilium Network Policies deployed in the cluster
Project: Cilium (Runtime / Cloud Native Network)
File: BENCHMARK.md

Validating the Kubernetes Swagger API ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 8549863982 ns/op 7067424936 B/op 59583275 allocs/op ``` ``` go test -bench Spec goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 4064535557 ns/op 3379715592 B/op 25320330 allocs/op ``` ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/validate cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkKubernetesSpec/validatingkubernetes_API-16 1 3758414145 ns/op 2593881496 B/op 17111373 allocs/op ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: disk.md

sidebar_position: 2 sidebar_label: "Use Disk Volume" HwameiStor provides another type of data volume known as raw disk data volume. This volume is based on the raw disk present on the node and can be directly mounted for container use. As a result, this type of data volume offers more efficient data read and write performance, thereby fully unleashing the performance of the disk. Create a nginx application and use `hwameistor-disk-volume` volume using the following command: ```console $ cat << EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: nginx namespace: default spec: containers: name: nginx image: docker.io/library/nginx:latest imagePullPolicy: IfNotPresent volumeMounts: name: data mountPath: /data ports: containerPort: 80 volumes: name: data persistentVolumeClaim: claimName: hwameistor-disk-volume EOF ```
Project: Virtual Kubelet (Runtime / Container Runtime)
File: virtual-kubelet-2019.md

work in progress Reduce the barrier of entry. Create a stable community. Release virtual kubelet 1.0. Core. Split out providers from the virtual kubelet core tree. Today the provider dependencies within the virtual kubelet cause more harm than good. Interface. Stablize the virtual kubelet interface so minimal changes to no changes will be needed in the future. Developer. Reduce the barrier of entry to create with virtual kubelet. Community. Grow and nurture the community for virtual kubelet core. Includes compiling use-cases past the cloud providers interests. IoT use-cases will be a big focus. Improve our e2e testing in virtual kubelet core. Add options & integration points to include any provider. Create a baseline for how quickly virtual kubelet can process requests. Test at high scale throughput. Work with sig-architecture in Kubernetes to develop a conformance test profile for virtual kubelet. Explore what it means to use virtual kubelet in an IoT Edge usecases and work with wg-io-edge in Kubernetes to develop a standard within virtual kubelet to enable those usecases. Create provider agnostic tools to scale into virtual kubelet. tba
Project: Rook (Runtime / Cloud Native Storage)
File: zone-group.md

A Rook Ceph cluster. Ideally a ceph-object-realm resource would have been started up already. The resource described in this design document represents the zone group in the . When the storage admin is ready to create a multisite zone group for object storage, the admin will name the zone group in the metadata section on the configuration file. In the config, the admin must configure the realm the zone group is in. The first ceph-object-zone-group resource created in a realm is designated as the master zone group in the Ceph cluster. This example `ceph-object-zone-group.yaml`, names a zone group `my-zonegroup`. ```yaml apiVersion: ceph.rook.io/v1alpha1 kind: CephObjectZoneGroup metadata: name: zone-group-a namespace: rook-ceph spec: realm: my-realm ``` Now create the ceph-object-zone-group. ```bash kubectl create -f ceph-object-zone-group.yaml ``` At this point the Rook operator recognizes that a new ceph-object-zone-group resource needs to be configured. The operator will start creating the resource to start the ceph-object-zone-group. After these steps the admin should start up: A with the name of the zone group in the `zoneGroup` section. A referring to the newly started up ceph-object-zone resource. A , with the same name as the `realm` field, if it has not already been started up already. The order in which these resources are created is not important. Once all of the resources in #2 are started up, the operator will create a zone group on the Rook Ceph cluster and the ceph-object-zone-group resource will be running. The realm named in the `realm` section must be the same as the ceph-object-realm resource the zone group is a part of. When resource is deleted, zone group are not deleted from the cluster. Zone group deletion must be done through toolboxes. At the moment creating an ceph-object-zone-group realm resource only handles Day 1 initial configuration for the realm. Changes made to the resource's configuration or deletion of the resource are not reflected on the Ceph cluster. To be clear, when the ceph-object-zone group resource is deleted or modified, the zone group is not deleted from the Ceph cluster. Zone Group deletion must be done through the toolbox. The Rook toolbox can modify the Ceph Multisite state via the radosgw-admin command. The following command, run via the toolbox, deletes the zone group. ```bash ``` The ceph-object-zone-group settings are exposed to Rook as a Custom Resource Definition (CRD). The CRD is the Kubernetes-native means by which the Rook operator can watch for new resources. The name of the resource provided in the `metadata` section becomes the name of the zone group. The following variables can be configured in the ceph-zone-group resource. `realm`: The realm named in the `realm` section of the ceph-realm resource the zone group is a part of. ```yaml apiVersion: ceph.rook.io/v1alpha1 kind: CephObjectZoneGroup metadata: name: zone-group-b namespace: rook-ceph spec: realm: my-realm ```
Project: rkt (Runtime / Container Runtime)
File: pod-manifest.md

The flag `--pod-manifest` can be passed to rkt's and subcommands. It allows users to specify a to run as a pod. A pod manifest completely specifies how the pod will be run, overriding any configuration present in the individual images of the apps in the pod. Thus, by encoding how a rkt pod should be executed in a file, it can then be saved in version control and users don't need to deal with very long CLI arguments everytime they want to run a complicated pod. The most convenient way to generate a pod manifest is running a pod by using the rkt CLI (without `--pod-manifest`), exporting the resulting pod manifest, and then tweaking it until satisfied with it. For example: ```bash $ sudo rkt run coreos.com/etcd:v2.0.10 kinvolk.io/aci/busybox:1.24 -- -c 'while true; do date; sleep 1; done' ... ^]^]Container rkt-07f1cfdc-950b-4b6e-a2c0-8fb1ed37f98b terminated by signal KILL. $ rkt cat-manifest 07f1cfdc > pod-manifest.json ``` The resulting pod manifest file is: ```json { "acVersion": "1.30.0", "acKind": "PodManifest", "apps": [ { "name": "etcd", "image": { "name": "coreos.com/etcd", "id": "sha512-c03b055d02e51e36f44a2be436eb77d5b0fbbbe37c00851188d8798912e8508a", "labels": [ { "name": "os", "value": "linux" }, { "name": "arch", "value": "amd64" }, { "name": "version", "value": "v2.0.10" } ] }, "app": { "exec": [ "/etcd" ], "user": "0", "group": "0" } }, { "name": "busybox", "image": { "name": "kinvolk.io/aci/busybox", "id": "sha512-140375b2a2bd836559a7c978f36762b75b80a7665e5d922db055d1792d6a4182", "labels": [ { "name": "version", "value": "1.24" }, { "name": "os", "value": "linux" }, { "name": "arch", "value": "amd64" } ] }, "app": { "exec": [ "sh", "-c", "while true; do date; sleep 1; done" ], "user": "0", "group": "0", "ports": [ { "name": "nc", "protocol": "tcp", "port": 1024, "count": 1, "socketActivated": false } ] } } ], "volumes": null, "isolators": null, "annotations": [ { "name": "coreos.com/rkt/stage1/mutable", "value": "false" } ], "ports": [] } ``` From there, you can edit the pod manifest following its . For example, we can add a memory isolator to etcd: ```json ... "exec": [ "/etcd" ], "isolators": [ { "name": "resource/memory", "value": {"limit": "1G"} } ], ... ``` Then, we can just run rkt with that pod manifest: ``` $ sudo rkt run --pod-manifest=pod-manifest.json ... ``` Note Images used by a pod manifest must be store in the local store, `--pod-manifest` won't do discovery or fetching. Another option is running rkt with different CLI arguments until we have a configuration we like, and then just save the resulting pod manifest to use it later.
Project: MinIO (Runtime / Cloud Native Storage)
File: minio-limits.md

For optimal production setup MinIO recommends Linux kernel version 4.x and later. | Item | Specification | |:-|:--| | Maximum number of servers per cluster | no-limit | | Minimum number of servers | 02 | | Minimum number of drives per server when server count is 1 | 02 | | Minimum number of drives per server when server count is 2 or 3 | 01 | | Minimum number of drives per server when server count is 4 | 01 | | Maximum number of drives per server | no-limit | | Read quorum | N/2 | | Write quorum | N/2+1 | | Item | Specification | |:--|:--| | Maximum number of buckets | unlimited (we recommend not beyond 500000 buckets) - see NOTE: | | Maximum number of objects per bucket | no-limit | | Maximum object size | 50 TiB | | Minimum object size | 0 B | | Maximum object size per PUT operation | 5 TiB | | Maximum number of parts per upload | 10,000 | | Part size range | 5 MiB to 5 TiB. Last part can be 0 B to 5 TiB | | Maximum number of parts returned per list parts request | 10000 | | Maximum number of objects returned per list objects request | 1000 | | Maximum number of multipart uploads returned per list multipart uploads request | 1000 | | Maximum length for bucket names | 63 | | Maximum length for object names | 1024 | | Maximum length for '/' separated object name segment | 255 | | Maximum number of versions per object | 10000 (can be configured to higher values but we do not recommend beyond 10000) | NOTE: While MinIO does not implement an upper boundary on buckets, your cluster's hardware has natural limits that depend on the workload and its scaling patterns. We strongly recommend for architecture and sizing guidance for your production use case. We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a with relevant details on why MinIO must implement them. BucketACL (Use instead) BucketCORS (CORS enabled by default on all buckets for all HTTP verbs, you can optionally restrict the CORS domains) BucketWebsite (Use or ) BucketAnalytics, BucketMetrics, BucketLogging (Use APIs) ObjectACL (Use instead) Object name restrictions on MinIO are governed by OS and filesystem limitations. For example object names that contain characters `^*|\/&";` are unsupported on Windows platform or any other file systems that do not support filenames with special characters. This list is non exhaustive, it depends on the operating system and filesystem under use - please consult your operating system vendor for a more comprehensive list of special characters. MinIO recommends using Linux operating system for production workloads. Objects must not have conflicting objects as parent objects, applications using this behavior should change their behavior and use non-conflicting unique keys, for example situations such as following conflicting key patterns are not supported. ``` PUT <bucketname>/a/b/1.txt PUT <bucketname>/a/b ``` ``` PUT <bucketname>/a/b PUT <bucketname>/a/b/1.txt ```
Project: Kuasar (Runtime / Container Runtime)
File: ADOPTERS.md

This document lists the organizations that use Kuasar on production or testing environment and projects that adopts Kuasar as their upstream. Please make a pull request on this document if any organization or project would like to be added or removed. | Adopter name | Adopter Type | Usage Scenario | |||-| | Menging Software | Service provider | FaaS platform based on WebAssembly | | Huawei Cloud Native | Service provider | Provide Kubernetes experience with kuasar | | iSulad | OSS project | Use Kuasar as low-level container runtime |