cwielenb/CNCF-Dataset huggingface dataset:
Project: Carina (Runtime / Cloud Native Storage)
File: pvc-expand.md

Carina support expanding PVC online, so user can resize carina pvc as needed. ```shell $ kubectl get pvc -n carina NAMESPACE NAME STATUS VOLUME Capacity STORAGECLASS AGE carina carina-pvc Bound pvc-80ede42a-90c3-4488-b3ca-85dbb8cd6c22 7G carina-sc 20d ``` Expanding it online. ```shell $ kubectl patch pvc/carina-pvc \ --namespace "carina" \ --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}' ``` Check if expanding works. ```shell $ kubectl exec -it web-server -n carina bash $ df -h Filesystem Size Used Avail Use% Mounted on overlay 199G 17G 183G 9% / tmpfs 64M 0 64M 0% /dev /dev/vda2 199G 17G 183G 9% /conf /dev/carina-vg-hdd/volume.... 15G 0 64M 0% /www/nginx/work tmpfs 3.9G 0 3.9G 0% /tmp/k8s-webhook-server/serving-certs ``` Note, if using cache tiering PVC, then user need to restart the pod to make the expanding work.
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-fs-mirror-crd.md

title: CephFilesystemMirror CRD This guide assumes you have created a Rook cluster as explained in the main Rook allows creation and updating the fs-mirror daemon through the custom resource definitions (CRDs). CephFS will support asynchronous replication of snapshots to a remote (different Ceph cluster) CephFS file system via cephfs-mirror tool. Snapshots are synchronized by mirroring snapshot data followed by creating a snapshot with the same name (for a given directory on the remote file system) as the snapshot being synchronized. For more information about user management and capabilities see the . To get you started, here is a simple example of a CRD to deploy an cephfs-mirror daemon. ```yaml apiVersion: ceph.rook.io/v1 kind: CephFilesystemMirror metadata: name: my-fs-mirror namespace: rook-ceph spec: {} ``` If any setting is unspecified, a suitable default will be used automatically. `name`: The name that will be used for the Ceph cephfs-mirror daemon. `namespace`: The Kubernetes namespace that will be created for the Rook cluster. The services, pods, and other resources created by the operator will be added to this namespace. `placement`: The cephfs-mirror pods can be given standard Kubernetes placement restrictions with `nodeAffinity`, `tolerations`, `podAffinity`, and `podAntiAffinity` similar to placement defined for daemons configured by the . `annotations`: Key value pair list of annotations to add. `labels`: Key value pair list of labels to add. `resources`: The resource requirements for the cephfs-mirror pods. `priorityClassName`: The priority class to set on the cephfs-mirror pods. In order to configure mirroring peers, please refer to the .
Project: Spiderpool (Runtime / Cloud Native Network)
File: spidercoodinator.md

| Case ID | Title | Priority | Smoke | Status | Other | | - | | -- | -- | | -- | | V00001 | Switch podCIDRType to `auto`, see if it could auto fetch the type | p3 | | done | | | V00002 | Switch podCIDRType to `auto` but no cni files in /etc/cni/net.d, Viewing should be consistent with `none` | p3 | | done | | | V00003 | Switch podCIDRType to `calico`, see if it could auto fetch the cidr from calico ippools | p3 | | done | | | V00004 | Switch podCIDRType to `cilium`, see if it works in ipam-mode: [cluster-pool,kubernetes,multi-pool] | p3 | | done | | | V00005 | Switch podCIDRType to `none`, expect the cidr of status to be empty | p3 | | done | | | V00006 | status.phase is not-ready, expect the cidr of status to be empty | p3 | | done | | | V00007 | spidercoordinator has the lowest priority | p3 | | done | | | V00008 | status.phase is not-ready, pods will fail to run | p3 | | done | | | V00009 | it can get the clusterCIDR from kubeadmConfig or kube-controller-manager pod | p3 | | done | | | V00010 | It can get service cidr from k8s serviceCIDR resoures | p3 | | done | | | V00011 | status should be NotReady if neither kubeadm-config configMap nor kube-controller-manager pod can be found | p3 | | done | |
Project: Kube-router (Runtime / Cloud Native Network)
File: see-it-in-action.md

Network services controller is responsible for reading the services and endpoints information from Kubernetes API server and configure IPVS on each cluster node accordingly. Please for design details and pros and cons compared to iptables based Kube-proxy Demo of Kube-router's IPVS based Kubernetes network service proxy ](https://asciinema.org/a/120312) Features: round robin load balancing client IP based session persistence source IP is preserved if service controller is used in conjuction with network routes controller (kube-router with --run-router flag) option to explicitly masquerade (SNAT) with --masquerade-all flag Network policy controller is responsible for reading the namespace, network policy and pods information from Kubernetes API server and configure iptables accordingly to provide ingress filter to the pods. Kube-router supports the networking.k8s.io/NetworkPolicy API or network policy V1/GA and also network policy beta semantics. Please for design details of Network Policy controller Demo of Kube-router's iptables based implementaton of network policies ](https://asciinema.org/a/120735) Network routes controller is responsible for reading pod CIDR allocated by controller manager to the node, and advertises the routes to the rest of the nodes in the cluster (BGP peers). Use of BGP is transparent to user for basic pod-to-pod networking. ](https://asciinema.org/a/120885) However BGP can be leveraged to other use cases like advertising the cluster ip, routable pod ip etc. Only in such use-cases understanding of BGP and configuration is required. Please see below demo how kube-router advertises cluster IP and pod cidrs to external BGP router ](https://asciinema.org/a/121635)
Project: Velero (Runtime / Cloud Native Storage)
File: 2019-04-09-Velero-is-an-Open-Source-Tool-to-Back-up-and-Migrate-Kubernetes-Clusters.md

title: Velero is an Open Source Tool to Back up and Migrate Kubernetes Clusters slug: Velero-is-an-Open-Source-Tool-to-Back-up-and-Migrate-Kubernetes-Clusters # Velero.io word list : ignore excerpt: Velero is an open source tool to safely back up, recover, and migrate Kubernetes clusters and persistent volumes. It works both on premises and in a public cloud. author_name: Velero Team categories: ['kubernetes'] tags: ['Velero Team'] Velero is an open source tool to safely back up, recover, and migrate Kubernetes clusters and persistent volumes. It works both on premises and in a public cloud. Velero consists of a server process running as a deployment in your Kubernetes cluster and a command-line interface (CLI) with which DevOps teams and platform operators configure scheduled backups, trigger ad-hoc backups, perform restores, and more. Unlike other tools which directly access the Kubernetes etcd database to perform backups and restores, Velero uses the Kubernetes API to capture the state of cluster resources and to restore them when necessary. This API-driven approach has a number of key benefits: Backups can capture subsets of the clusters resources, filtering by namespace, resource type, and/or label selector, providing a high degree of flexibility around whats backed up and restored. Users of managed Kubernetes offerings often do not have access to the underlying etcd database, so direct backups/restores of it are not possible. Resources exposed through aggregated API servers can easily be backed up and restored even if theyre stored in a separate etcd database. Additionally, Velero enables you to backup and restore your applications persistent data alongside their configurations, using either your storage platforms native snapshot capability or an integrated file-level backup tool called . Since Velero was initially released in August 2017, weve had nearly 70 contributors to the project, with a ton of support from the community. We also recently reached 2000 stars on GitHub. We are excited to keep building our great community and project. Twitter () Slack ( on Kubernetes) Google Group () We are continuing to work towards Velero 1.0 and would love your help working on the items in our roadmap. If youre interested in contributing, we have a number of GitHub issues labeled as and , including items related to Prometheus metrics, the CLI UX, improved documentation, and more. We are more than happy to work with new and existing contributors alike. Previously posted at: <https://blogs.vmware.com/cloudnative/2019/02/28/velero-v0-11-delivers-an-open-source-tool-to-back-up-and-migrate-kubernetes-clusters/> <!-- Velero.io word list : ignore -->
Project: Alluxio (Runtime / Cloud Native Storage)
File: pr_title_words.md

access add address adjust aggregate allocate allow alphabetize annotate append apply ask assert assign attempt audit augment avoid begin bind block break bring build bump cache call cancel capitalize cast catch centralize change check choose clarify clean cleanup clear close collect combine comment commit compact compile complete configure conform connect consider consolidate continue convert coordinate copy correct create cut debug declare decouple decrease define deflake delay delete denote depend deploy deprecate describe deserialize determine differentiate disable disallow discuss display distinguish do dockerize document downgrade drop dump duplicate edit elaborate eliminate enable enforce enhance ensure escape exclude exit explain expose extend extract factor fail fill filter find finish fix flush follow force forget format generalize generate get give group handle hardcode heartbeat hide ignore implement import improve include incorporate increase increment init initialize inline insert install integrate introduce invalidate isolate journal keep kill leave let limit link list load lock log login make manage mark mention merge migrate modify move name normalize open optimize order organize output overload override parallelize parse pass perform permit pin placate polish populate port prefer prepare preserve prevent print process propagate prototype provide publish put quote read rearrange rebase recompute recover redefine redirect reduce reenable refactor reference refine reformat regen regenerate register reimplement relax release relocate remove rename reorder reorg reorganize rephrase replace replay report request require rerun reserve reset resolve respect respond restore restructure retrieve retry return reuse revert review revise reword rewrite roll run save search send separate set shade share shift shorten show shutdown simplify skip sleep solve sort space specify spell split start stash state stop store supply support suppress switch sync synchronize tag terminate test throw time track translate trim try tune turn tweak undo unify unignore unmount unwrap update upgrade use validate verify wait wrap write
Project: CRI-O (Runtime / Container Runtime)
File: CHANGELOG.md

An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by `Decrypt` or `DecryptMulti`. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting. This release makes some breaking changes in order to more thoroughly address the vulnerabilities discussed in [Three New Attacks Against JSON Web Tokens][1], "Sign/encrypt confusion", "Billion hash attack", and "Polyglot token". Limit JWT encryption types (exclude password or public key types) (#78) Enforce minimum length for HMAC keys (#85) jwt: match any audience in a list, rather than requiring all audiences (#81) jwt: accept only Compact Serialization (#75) jws: Add expected algorithms for signatures (#74) Require specifying expected algorithms for ParseEncrypted, ParseSigned, ParseDetached, jwt.ParseEncrypted, jwt.ParseSigned, jwt.ParseSignedAndEncrypted (#69, #74) Usually there is a small, known set of appropriate algorithms for a program to use and it's a mistake to allow unexpected algorithms. For instance the "billion hash attack" relies in part on programs accepting the PBES2 encryption algorithm and doing the necessary work even if they weren't specifically configured to allow PBES2. Revert "Strip padding off base64 strings" (#82) The specs require base64url encoding without padding. Minimum supported Go version is now 1.21 ParseSignedCompact, ParseSignedJSON, ParseEncryptedCompact, ParseEncryptedJSON. These allow parsing a specific serialization, as opposed to ParseSigned and ParseEncrypted, which try to automatically detect which serialization was provided. It's common to require a specific serialization for a specific protocol - for instance JWT requires Compact serialization. Limit decompression output size to prevent a DoS. Backport from v4.0.1. DecryptMulti: handle decompression error (#19) jwe/CompactSerialize: improve performance (#67) Increase the default number of PBKDF2 iterations to 600k (#48) Return the proper algorithm for ECDSA keys (#45) Add Thumbprint support for opaque signers (#38) Security issue: an attacker specifying a large "p2c" value can cause JSONWebEncryption.Decrypt and JSONWebEncryption.DecryptMulti to consume large amounts of CPU, causing a DoS. Thanks to Matt Schwager (@mschwager) for the disclosure and to Tom Tervoort for originally publishing the category of attack. https://i.blackhat.com/BH-US-23/Presentations/US-23-Tervoort-Three-New-Attacks-Against-JSON-Web-Tokens.pdf Limit decompression output size to prevent a DoS. Backport from v4.0.1.
Project: Weave Net (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Kata Containers (Runtime / Container Runtime)
File: CpuFeatures.md

Name | Type | Description | Notes | - | - | - Amx | Pointer to bool | | [optional] `func NewCpuFeatures() *CpuFeatures` NewCpuFeatures instantiates a new CpuFeatures object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewCpuFeaturesWithDefaults() *CpuFeatures` NewCpuFeaturesWithDefaults instantiates a new CpuFeatures object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *CpuFeatures) GetAmx() bool` GetAmx returns the Amx field if non-nil, zero value otherwise. `func (o CpuFeatures) GetAmxOk() (bool, bool)` GetAmxOk returns a tuple with the Amx field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuFeatures) SetAmx(v bool)` SetAmx sets Amx field to given value. `func (o *CpuFeatures) HasAmx() bool` HasAmx returns a boolean if a field has been set.
Project: Multus (Runtime / Cloud Native Network)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Weave Net (Runtime / Cloud Native Network)
File: weavedns-design.md

title: WeaveDNS (service discovery) Design Notes layout: default The model is that each host has a service that is notified of hostnames and weave addresses for containers on the host. Like IPAM, this service is embedded within the router. It binds to the host bridge to answer DNS queries from local containers; for anything it can't answer, it uses the information in the host's /etc/resolv.conf to query an 'fallback' server. The service is comprised of a DNS server, which answers all DNS queries from containers, and a in-memory database of hostnames and IPs. The database on each node contains a complete copy of the hostnames and IPs for every containers in the cluster. For hostname queries in the local domain (default weave.local), the DNS server will consult the in-memory database. For reverse queries, we first consult the local database, and if not found we query the upstream server. For all other queries, we consult the upstream server. Updates to the in-memory database are broadcast to other DNS servers within the cluster. The in-memory database only contains entries from connected DNS servers; if a DNS server becomes partitioned from the cluster, entries belonging to that server are removed from each node in the cluster. When the partitioned DNS server reconnects, the entries are re-broadcast around the cluster. The DNS server also listens to the Docker event stream, and removes entries for containers when they die. Entries removed in this way are tombstoned, and the tombstone lazily broadcast around the cluster. After a short timeout the tombstones are independently removed from each host. The DNS server accepts HTTP requests on the following URL (patterns) and methods: `PUT /name/<identifier>/<ip-address>` Put a record for an IP, bound to a host-scoped identifier (e.g., a container ID), in the DNS database. The request body must contain a `fqdn=foo.weave.local` key pair. `DELETE /name/<identifier>/<ip-address>` Remove a specific record for an IP and host-scoped identifier. The request body can optionally contain a `fqdn=foo.weave.local` key pair. `DELETE /name/<identifier>` Remove all records for the host-scoped identifier. `GET /name/<fqdn>` List of all IPs (in JSON format) for givne FQDN. The updater component uses the Docker remote API to monitor containers coming and going, and tells the DNS server to update its records via its HTTP interface. It does not need to be attached to the weave network. The updater starts by subscribing to the events, and getting a list of the current containers. Any containers given a domain ending with ".weave" are considered for inclusion in the name database. When it sees a container start or stop, the updater checks the weave network attachment of the container, and updates the DNS server. How does it check the network attachment from within a container? Will it need to delay slightly so that `attach` has a chance to run? Perhaps it could put containers on a watch list when it's noticed them.
Project: rkt (Runtime / Container Runtime)
File: upgrading.md

Usually, upgrading rkt should work without doing anything special: pods started with the old version will continue running and new pods will be started with the new version. However, in some cases special care must be taken. If the api-service is running and the new version of rkt does a store version upgrade that requires migration, new invocations of rkt will be blocked. This is so because the api-service is a long running process that holds a lock on the store, and the store migration needs to take an exclusive lock on it. For this reason, it is recommended to stop the api-service and start the latest version when upgrading rkt. This recommendation doesn't apply if the new api-service is listening on a different port and using a different via the `--dir` flag.
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.5.2.md

This release introduces bug fixes and improvements, with the main focus on stability. Please try it and provide feedback. Thanks for all the contributions! For the definition of stable or latest release, please check . Please ensure your Kubernetes cluster is at least v1.21 before installing v1.5.2. Longhorn supports three installation ways including Rancher App Marketplace, Kubectl, and Helm. Follow the installation instructions . Please read the first and ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.5.2 from v1.4.x/v1.5.x, which are only supported source versions. Follow the upgrade instructions here. . N/A Please follow up on about any outstanding issues found after this release. - @c3y1huang @chriscchien - @derekbit - @PhanLe1010 @chriscchien - @PhanLe1010 @nitendra-suse - @james-munson @roger-ryao - @derekbit - @PhanLe1010 @ejweber @roger-ryao - @derekbit @roger-ryao - @ChanYiLin @roger-ryao - @james-munson - @ejweber @roger-ryao - @c3y1huang @roger-ryao - @smallteeths @chriscchien - @mantissahz - @PhanLe1010 @roger-ryao - @smallteeths @chriscchien - @ChanYiLin @roger-ryao - @mantissahz @roger-ryao - @ejweber @chriscchien - @ChanYiLin @roger-ryao - @c3y1huang @nitendra-suse - @ejweber @roger-ryao - @c3y1huang @roger-ryao - @derekbit @nitendra-suse - @derekbit @shuo-wu - @james-munson @chriscchien - @mantissahz @chriscchien - @ChanYiLin @nitendra-suse - @PhanLe1010 @chriscchien - @c3y1huang @nitendra-suse - @yangchiu @derekbit - @PhanLe1010 @chriscchien - @ChanYiLin @chriscchien - @ChanYiLin @roger-ryao - @votdev - @mantissahz @roger-ryao - @mantissahz @chriscchien - @c3y1huang - @mantissahz - @derekbit @chriscchien - @derekbit @chriscchien - @derekbit @roger-ryao - @ejweber - @derekbit @chriscchien - @shuo-wu - @c3y1huang @chriscchien - @derekbit @chriscchien @nitendra-suse - @c3y1huang @roger-ryao - @james-munson @chriscchien - @ejweber @chriscchien - @mantissahz - @PhanLe1010 @roger-ryao - @ejweber @chriscchien - @mantissahz @chriscchien - @mantissahz @chriscchien - @derekbit @roger-ryao @ChanYiLin @PhanLe1010 @c3y1huang @chriscchien @derekbit @ejweber @innobead @james-munson @mantissahz @nitendra-suse @roger-ryao @shuo-wu @smallteeths @votdev @yangchiu
Project: containerd (Runtime / Container Runtime)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_devices.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show contents of table "devices" ``` cilium-dbg statedb devices [flags] ``` ``` -h, --help help for devices -w, --watch duration Watch for new changes with the given interval (e.g. --watch=100ms) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Inspect StateDB