cwielenb/CNCF-Dataset huggingface dataset:
Project: Velero (Runtime / Cloud Native Storage)
File: ark_schedule_describe.md

title: "ark schedule describe" layout: docs Describe schedules Describe schedules ``` ark schedule describe [NAME1] [NAME2] [NAME...] [flags] ``` ``` -h, --help help for describe -l, --selector string only show items matching this label selector ``` ``` --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: Cilium (Runtime / Cloud Native Network)
File: cilium-agent_completion_fish.md

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

sidebar_position: 2 sidebar_label: "Node Expansion" A storage system is usually expected to expand its capacity by adding a new storage node. In HwameiStor, it can be done with the following steps. Add the node into the Kubernetes cluster, or select a Kubernetes node. The node should have all the required items described in . For example, the new node and disk information are as follows: name: k8s-worker-4 devPath: /dev/sdb diskType: SSD disk After the new node is already added into the Kubernetes cluster, make sure the following HwameiStor pods are already running on this node. ```console $ kubectl get node NAME STATUS ROLES AGE VERSION k8s-master-1 Ready master 96d v1.24.3-2+63243a96d1c393 k8s-worker-1 Ready worker 96h v1.24.3-2+63243a96d1c393 k8s-worker-2 Ready worker 96h v1.24.3-2+63243a96d1c393 k8s-worker-3 Ready worker 96d v1.24.3-2+63243a96d1c393 k8s-worker-4 Ready worker 1h v1.24.3-2+63243a96d1c393 $ kubectl -n hwameistor get pod -o wide | grep k8s-worker-4 hwameistor-local-disk-manager-c86g5 2/2 Running 0 19h 10.6.182.105 k8s-worker-4 <none> <none> hwameistor-local-storage-s4zbw 2/2 Running 0 19h 192.168.140.82 k8s-worker-4 <none> <none> $ kubectl get localstoragenode k8s-worker-4 NAME IP STATUS AGE k8s-worker-4 10.6.182.103 Ready 8d ``` Construct the storage pool of the node by adding a LocalStorageClaim CR as below: ```console $ kubectl apply -f - <<EOF apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: k8s-worker-4 spec: nodeName: k8s-worker-4 owner: local-storage description: diskType: SSD EOF ``` Finally, check if the node has constructed the storage pool by checking the LocalStorageNode CR. ```bash kubectl get localstoragenode k8s-worker-4 -o yaml ``` The output may look like: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalStorageNode metadata: name: k8s-worker-4 spec: hostname: k8s-worker-4 storageIP: 10.6.182.103 topogoly: region: default zone: default status: pools: LocalStorage_PoolSSD: class: SSD disks: capacityBytes: 214744170496 devPath: /dev/sdb state: InUse type: SSD freeCapacityBytes: 214744170496 freeVolumeCount: 1000 name: LocalStorage_PoolSSD totalCapacityBytes: 214744170496 totalVolumeCount: 1000 type: REGULAR usedCapacityBytes: 0 usedVolumeCount: 0 volumeCapacityBytesLimit: 214744170496 volumes: state: Ready ```
Project: CRI-O (Runtime / Container Runtime)
File: kubernetes.md

In a standard Docker Kubernetes cluster, kubelet is running on each node as systemd service and is taking care of communication between runtime and the API service. It is responsible for starting microservices pods (such as `kube-proxy`, `kubedns`, etc. - they can be different for various ways of deploying k8s) and user pods. Configuration of kubelet determines which runtime is used and in what way. Kubelet itself is executed in Docker container (as we can see in `kubelet.service`), but, what is important, it's not a Kubernetes pod (at least for now), so we can keep kubelet running inside the container (as well as directly on the host), and regardless of this, run pods in the chosen runtime. Below, you can find an instruction how to switch one or more nodes on running Kubernetes cluster from Docker to CRI-O. At first, you need to stop kubelet service working on the node: ```shell systemctl stop kubelet ``` and stop all kubelet Docker containers that are still running. ```shell docker stop $(docker ps | grep k8s_ | awk '{print $1}') ``` We have to be sure that `kubelet.service` will start after `crio.service`. It can be done by adding `crio.service` to `Wants=` section in `/etc/systemd/system/kubelet.service`: ```shell $ cat /etc/systemd/system/kubelet.service | grep Wants Wants=docker.socket crio.service ``` If you'd like to change the way of starting kubelet (e.g., directly on the host instead of in a container), you can change it here, but, as mentioned, it's not necessary. Kubelet parameters are stored in `/etc/kubernetes/kubelet.env` file. ```shell $ cat /etc/kubernetes/kubelet.env | grep KUBELET_ARGS KUBELET_ARGS="--pod-manifest-path=/etc/kubernetes/manifests --pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0 --clusterdns=10.233.0.3 --clusterdomain=cluster.local --resolv-conf=/etc/resolv.conf --kubeconfig=/etc/kubernetes/node-kubeconfig.yaml --require-kubeconfig" ``` You need to add following parameters to `KUBELET_ARGS`: `--container-runtime-endpoint=unix:///var/run/crio/crio.sock` Socket for remote runtime (default `crio` socket localization). `--runtime-request-timeout=10m` - Optional but useful. Some requests, especially pulling huge images, may take longer than default (2 minutes) and will cause an error. You may need to add following parameter to `KUBELET_ARGS` (prior to Kubernetes `v1.24.0-alpha.2`). This flag is deprecated since `v1.24.0-alpha.2`, and will no longer be available starting from `v1.27.0`: `--container-runtime=remote` - Use remote runtime with provided socket. Kubelet is prepared now. If your cluster is using flannel network, your network configuration should be like: ```shell $ cat /etc/cni/net.d/10-crio.conf { "name": "crio", "type": "flannel" } ``` Then, kubelet will take parameters from `/run/flannel/subnet.env` - file generated by flannel kubelet microservice. Start crio first, then kubelet. If you created `crio` service: ```shell systemctl start crio systemctl start kubelet ``` You can follow the progress of preparing node using `kubectl get nodes` or `kubectl get pods --all-namespaces` on Kubernetes control-plane.
Project: CubeFS (Runtime / Cloud Native Storage)
File: management.md

``` bash curl -v "http://10.196.59.198:17010/raftNode/add?addr=10.196.59.197:17010&id=3" ``` Adds a new master node to the raft replication group. Parameter List | Parameter | Type | Description | |--|--|-| | addr | string | IP address of the master, in the format of ip:port | | id | uint64 | Node identifier of the master | ``` bash curl -v "http://10.196.59.198:17010/raftNode/remove?addr=10.196.59.197:17010&id=3" ``` Removes a node from the raft replication group. Parameter List | Parameter | Type | Description | |--|--|-| | addr | string | IP address of the master, in the format of ip:port | | id | uint64 | Node identifier of the master |
Project: Spiderpool (Runtime / Cloud Native Network)
File: assignip.md

| Case ID | Title | Priority | Smoke | Status | Other | ||-|-|-|--|-| | E00001 | Assign IP to a pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00002 | Assign IP to deployment/pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00003 | Assign IP to statefulSet/pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00004 | Assign IP to daemonSet/pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00005 | Assign IP to job/pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00006 | Assign IP to replicaset/pod for ipv4, ipv6 and dual-stack case | p1 | true | done | | | E00007 | Successfully run a pod with long yaml for ipv4, ipv6 and dual-stack case | p2 | | done | | | E00008 | Failed to run a pod when IP resource of an IPPool is exhausted | p3 | | done | | | E00009 | The cluster is dual stack, but the spiderpool can allocates ipv4 or ipv6 only with IPPools annotation | p2 | | done | | | E00010 | The cluster is dual stack, but the spiderpool can allocates ipv4 or ipv6 only with Subnet annotation | p2 | | done | |
Project: Velero (Runtime / Cloud Native Storage)
File: ark_client_config_set.md

title: "ark client config set" layout: docs Set client configuration file values Set client configuration file values ``` ark client config set KEY=VALUE [KEY=VALUE]... [flags] ``` ``` -h, --help help for set ``` ``` --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 ``` - Get and set client configuration file values
Project: Kata Containers (Runtime / Container Runtime)
File: ROADMAP.md

containerd uses the issues and milestones to define its roadmap. `ROADMAP.md` files are common in open source projects, but we find they quickly become out of date. We opt for an issues and milestone approach that our maintainers and community can keep up-to-date as work is added and completed. Issues tagged with the `roadmap` label are high level roadmap items. They are tasks and/or features that the containerd community wants completed. Smaller issues and pull requests can reference back to the main roadmap issue that is tagged to help detail progress towards the overall goal. Milestones define when an issue, pull request, and/or roadmap item is to be completed. Issues are the what, milestones are the when. Development is complex therefore roadmap items can move between milestones depending on the remaining development and testing required to release a change. To find the roadmap items currently planned for containerd you can filter on the `roadmap` label. After searching for roadmap items you can view what milestone they are scheduled to be completed in along with the progress.
Project: runc (Runtime / Container Runtime)
File: runc-checkpoint.8.md

% runc-checkpoint "8" runc-checkpoint - checkpoint a running container runc checkpoint [option ...] container-id The checkpoint command saves the state of the running container instance with the help of criu(8) tool, to be restored later. --image-path path : Set path for saving criu image files. The default is ./checkpoint. --work-path path : Set path for saving criu work files and logs. The default is to reuse the image files directory. --parent-path path : Set path for previous criu image files, in pre-dump. --leave-running : Leave the process running after checkpointing. --tcp-established : Allow checkpoint/restore of established TCP connections. See . --ext-unix-sk : Allow checkpoint/restore of external unix sockets. See . --shell-job : Allow checkpoint/restore of shell jobs. --lazy-pages : Use lazy migration mechanism. See . --status-fd fd : Pass a file descriptor fd to criu. Once lazy-pages server is ready, criu writes \0 (a zero byte) to that fd. Used together with --lazy-pages. --page-server IP-address:port : Start a page server at the specified IP-address and port. This is used together with criu lazy-pages. See . --file-locks : Allow checkpoint/restore of file locks. See . --pre-dump : Do a pre-dump, i.e. dump container's memory information only, leaving the container running. See . --manage-cgroups-mode soft|full|strict|ignore. : Cgroups mode. Default is soft. See . --empty-ns namespace : Checkpoint a namespace, but don't save its properties. See . --auto-dedup : Enable auto deduplication of memory images. See . criu(8), runc-restore(8), runc(8), criu(8).
Project: Kata Containers (Runtime / Container Runtime)
File: Developers.md

`virtcontainers` has a few prerequisites for development: CNI golang To build `virtcontainers`, at the top level directory run: ```bash ``` Before testing `virtcontainers`, ensure you have met the . To test `virtcontainers`, at the top level run: ``` ``` This will: run static code checks on the code base. run `go test` unit tests from the code base. For details on the format and how to submit changes, refer to the document.
Project: Multus (Runtime / Cloud Native Network)
File: license.md

MIT License Copyright (c) 2019 Josh Bleecher Snyder Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Velero (Runtime / Cloud Native Storage)
File: backup.md

title: "Backup API Type" layout: docs Use the `Backup` API type to request the Velero server to perform a backup. Once created, the Velero Server immediately starts the backup process. Backup belongs to the API group version `velero.io/v1`. Here is a sample `Backup` object with each of the fields documented: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: name: a namespace: velero spec: csiSnapshotTimeout: 10m includedNamespaces: '*' excludedNamespaces: some-namespace includedResources: '*' excludedResources: storageclasses.storage.k8s.io includeClusterResources: null labelSelector: matchLabels: app: velero component: server orLabelSelectors: matchLabels: app: velero matchLabels: app: data-protection snapshotVolumes: null storageLocation: aws-primary volumeSnapshotLocations: aws-primary gcp-primary ttl: 24h0m0s defaultVolumesToRestic: true hooks: resources: name: my-hook includedNamespaces: '*' excludedNamespaces: some-namespace includedResources: pods excludedResources: [] labelSelector: matchLabels: app: velero component: server pre: exec: container: my-container command: /bin/uname -a onError: Fail timeout: 10s post: status: version: 1 expiration: null phase: "" validationErrors: null startTimestamp: 2019-04-29T15:58:43Z completionTimestamp: 2019-04-29T15:58:56Z volumeSnapshotsAttempted: 2 volumeSnapshotsCompleted: 1 warnings: 2 errors: 0 failureReason: "" ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_describe_backups.md

title: "ark describe backups" layout: docs Describe backups Describe backups ``` ark describe backups [NAME1] [NAME2] [NAME...] [flags] ``` ``` -h, --help help for backups -l, --selector string only show items matching this label selector --volume-details display details of restic volume backups ``` ``` --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 ``` - Describe ark resources
Project: Rook (Runtime / Cloud Native Storage)
File: performance-profiling.md

title: Performance Profiling !!! warn This is an advanced topic please be aware of the steps you're performing or reach out to the experts for further guidance. There are some cases where the debug logs are not sufficient to investigate issues like high CPU utilization of a Ceph process. In that situation, coredump and perf information of a Ceph process is useful to be collected which can be shared with the Ceph team in an issue. To collect this information, please follow these steps: Edit the rook-ceph-operator deployment and set `ROOKHOSTPATHREQUIRES_PRIVILEGED` to `true`. Wait for the pods to get reinitialized: ```console ``` Enter the respective pod of the Ceph process which needs to be investigated. For example: ```console ``` Install `gdb` , `perf` and `git` inside the pod. For example: ```console ``` Capture perf data of the respective Ceph process: ```console ``` Grab the `pid` of the respective Ceph process to collect its backtrace at multiple time instances, attach `gdb` to it and share the output `gdb.txt`: ```console set pag off set log on thr a a bt full # This captures the complete backtrace of the process backtrace Ctrl+C backtrace Ctrl+C backtrace Ctrl+C backtrace set log off q (to exit out of gdb) ``` Grab the live coredump of the respective process using `gcore`: ```console ``` Capture the data for the respective Ceph process and share the output `gdbpmp.data` generated: ```console ``` Collect the `perf.data`, `perf_report`, backtrace of the process `gdb.txt` , `core` file and profiler data `gdbpmp.data` and upload it to the tracker issue for troubleshooting purposes.
Project: rkt (Runtime / Container Runtime)
File: running-fly-stage1.md

The fly stage1 is an alternative stage1 that runs a single-application ACI with only `chroot`-isolation. The motivation of the fly feature is to add the ability to run applications with full privileges on the host but still benefit from the image management and discovery from rkt. The Kubernetes is one candidate for rkt fly. In comparison to the default stage1, there is no process manager involved in the stage1. This a visual illustration for the differences in the process tree between the default and the fly stage1: stage1-coreos.aci: ``` host OS rkt systemd-nspawn systemd chroot user-app1 ``` stage1-fly.aci: ``` host OS rkt chroot user-app1 ``` The rkt application sets up bind mounts for `/dev`, `/proc`, `/sys`, and the user-provided volumes. In addition to the bind mounts, an additional tmpfs mount is done at `/tmp`. After the mounts are set up, rkt `chroot`s to the application's RootFS and finally executes the application. The fly stage1 makes use of Linux . If a volume source path is a mountpoint on the host, this mountpoint is made recursively shared before the host path is mounted on the target path in the container. Hence, changes to the mounts inside the container will be propagated back to the host. The bind mounts for `/dev`, `/proc`, and `/sys` are done automatically and are recursive, because their hierarchy contains mounts which also need to be available for the container to function properly. User-provided volumes are not mounted recursively. This is a safety measure to prevent system crashes when multiple containers are started that mount `/` into the container. You can either use `stage1-fly.aci` from the official release, or build rkt yourself with the right options: ``` $ ./autogen.sh && ./configure --with-stage1-flavors=fly && make ``` For more details about configure parameters, see the . This will build the rkt binary and the stage1-fly.aci in `build-rkt-1.30.0+git/bin/`. Here is a quick example of how to use a container with the official fly stage1: ``` ``` If the image is not in the store, `--stage1-name` will perform discovery and fetch the image. By design, the fly stage1 does not provide the same isolation and security features as the default stage1. Specifically, the following constraints are not available when using the fly stage1: network namespace isolation CPU isolators Memory isolators CAPABILITY bounding SELinux When using systemd on the host it is possible to to provide additional isolation. For more information please consult the systemd manual.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: ldm.md

sidebar_position: 1 sidebar_label: "Local Disk Manager" Local Disk Manager (LDM) is one of the modules of HwameiStor. `LDM` is used to simplify the management of disks on nodes. It can abstract the disk on a node into a resource for monitoring and management purposes. It's a daemon that will be deployed on each node, then detect the disk on the node, abstract it into local disk (LD) resources and save it to kubernetes. At present, the LDM project is still in the `alpha` stage. LocalDisk (LD): LDM abstracts disk resources into objects in kubernetes. An `LD` resource object represents the disk resources on the host. LocalDiskClaim (LDC): This is a way to use disks. A user can add the disk description to select a disk for use. At present, LDC supports the following options to describe disk: NodeName Capacity DiskType (such as HDD/SSD/NVMe) Get the LocalDisk information. ```bash kubectl get localdisk NAME NODEMATCH PHASE 10-6-118-11-sda 10-6-118-11 Available 10-6-118-11-sdb 10-6-118-11 Available ``` Get locally discovered disk resource information with three columns displayed. NAME: represents how this disk is displayed in the cluster resources. NODEMATCH: indicates which host this disk is on. PHASE: represents the current state of the disk. Use `kubectl get localdisk <name> -o yaml` to view more information about disks. Claim available disks. Apply a LocalDiskClaim. ```bash cat << EOF | kubectl apply -f - apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: <localDiskClaimName> spec: description: diskType: <diskType> nodeName: <nodeName> owner: <ownerName> EOF ``` Allocate available disks by issuing a disk usage request. In the request description, you can add more requirements about the disk, such as disk type and capacity. Get the LocalDiskClaim information. ```bash kubectl get localdiskclaim <name> ``` Once the LDC is processed successfully, it will be cleanup by the system automatically. The result will be recorded in the `LocalStorageNode` if the owner is `local-storage`.