cwielenb/CNCF-Dataset huggingface dataset:
Project: Skipper (Orchestration & Management / Service Proxy)
File: deployment.md

Edge HTTP routing is the first hit to your production HTTP loadbalancer. Skipper can serve this well and reliably in production since 2016. On the edge you want to dispatch incoming HTTP requests to your backends, which could be a microservice architecture. In this deployment mode you might have 100k HTTP routes, which are used in production and modified by many parties. To support this scenario we have the . is a distributed database. TODO: why we use ETCD for this purpose is the component responsible to route traffic into your cluster. As deployer you can define an ingress object and an ingress controller will make sure incoming traffic gets routed to her backend service as defined. Skipper supports this scenario with the and is used in production since end of 2016. Skipper as ingress controller does not need to have any file configuration or anything external which configures Skipper. Skipper automatically finds Ingress objects and configures routes automatically, without reloading. The only requirement is to target all traffic you want to serve with Kubernetes to a loadbalancer pool of Skippers. This is a clear advantage over other ingress controllers like nginx, haproxy or envoy. Read more about . In demos you may want to show arbitrary hello world applications. You can easily describe html or json output on the command line with the . The most static deployment that is known from apache, nginx or haproxy is write your routes into a file and start your http server. This is what the is about.
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: quickstart.md

description: > Get started with kcp by running it locally. Visit our and download `kcp` and `kubectl-kcp-plugin` that match your operating system and architecture. Extract `kcp` and `kubectl-kcp-plugin` and place all the files in the `bin` directories somewhere in your `$PATH`. You can start kcp using this command: ```shell kcp start ``` This launches kcp in the foreground. You can press `ctrl-c` to stop it. To see a complete list of server options, run `kcp start options`. During its startup, kcp generates a kubeconfig in `.kcp/admin.kubeconfig`. Use this to connect to kcp and display the version to confirm it's working: ```shell $ export KUBECONFIG=.kcp/admin.kubeconfig $ kubectl version WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.4", GitCommit:"95ee5ab382d64cfe6c28967f36b53970b8374491", GitTreeState:"clean", BuildDate:"2022-08-17T18:46:11Z", GoVersion:"go1.19", Compiler:"gc", Platform:"darwin/amd64"} Kustomize Version: v4.5.4 Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.3+kcp-v0.8.0", GitCommit:"41863897", GitTreeState:"clean", BuildDate:"2022-09-02T18:10:37Z", GoVersion:"go1.18.5", Compiler:"gc", Platform:"darwin/amd64"} ``` Thanks for checking out our quickstart! If you're interested in learning more about all the features kcp has to offer, please check out our additional documentation: - a high level overview of kcp concepts - a more thorough introduction on kcp's workspaces - how kcp manages access control to workspaces and content - details on kcp's mechanism for virtual views of workspace content
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-0.9.10.md

+++ title = "CoreDNS-0.9.10 Release" description = "CoreDNS-0.9.10 Release Notes." tags = ["Release", "0.9.10", "Notes"] draft = false release = "0.9.10" date = "2017-11-03T20:45:43-00:00" author = "coredns" +++ CoreDNS-0.9.10 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. Release 0.9.10 is a minor release, with some fixes. The reverse zone syntax was extended to allow non-octet boundaries: ~~~ 192.168.1.0/17 { ... } ~~~ Will behave correctly. Lots of documentation clean ups. More platforms have binaries for each release. dnssec* will now insert DS records (and sign them) when it signs a delegation response. host* now checks for /etc/hosts updates in a separate go-routine. The following people helped with getting this release done: Chris O'Haver, Miek Gieben, Pat Moroney, Paul Hoffman, Sandeep Rajan, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: APISIX (Orchestration & Management / API Gateway)
File: external-plugin.md

title: External Plugin <!-- --> APISIX supports writing plugins in Lua. This type of plugin will be executed inside APISIX. Sometimes you want to develop plugins in other languages, so APISIX provides sidecars that load your plugins and run them when the requests hit APISIX. These sidecars are called plugin runners and your plugins are called external plugins. When you configure a plugin runner in APISIX, APISIX will run the plugin runner as a subprocess. The process will belong to the same user of the APISIX process. When we restart or reload APISIX, the plugin runner will be restarted too. Once you have configured `ext-plugin-*` plugins for a given route, the requests which hit the route will trigger RPC call from APISIX to the plugin runner via unix socket. The plugin runner will handle the RPC call, create a fake request at its side, run external plugins and return the result back to APISIX. The target external plugins and the execution order are configured in the `ext-plugin-*` plugins. Like other plugins, they can be enabled and reconfigured on the fly. If you are interested in the implementation of Plugin Runner, please refer to . Java: https://github.com/apache/apisix-java-plugin-runner Go: https://github.com/apache/apisix-go-plugin-runner Python: https://github.com/apache/apisix-python-plugin-runner JavaScript: https://github.com/zenozeng/apisix-javascript-plugin-runner To run the plugin runner in the prod, add the section below to `config.yaml`: ```yaml ext-plugin: cmd: ["blah"] # replace it to the real runner executable according to the runner you choice ``` Then APISIX will manage the runner as its subprocess. Note: APISIX can't manage the runner on the Mac in `v2.6`. During development, we want to run the runner separately so that we can restart it without restarting APISIX first. By specifying the environment variable `APISIXLISTENADDRESS`, we can force the runner to listen to a fixed address. For instance: ```bash APISIXLISTENADDRESS=unix:/tmp/x.sock ./the_runner ``` will force the runner to listen to `/tmp/x.sock`. Then you need to configure APISIX to send RPC to the fixed address: ```yaml ext-plugin: pathfortest: "/tmp/x.sock" # without 'unix:' prefix ``` In the prod environment, `pathfortest` should not be used and the unix socket path will be generated dynamically. Since `v2.7`, APISIX can pass environment variables to the runner. However, Nginx will hide all environment variables by default. So you need to declare your variable first in the `conf/config.yaml`: ```yaml nginx_config: envs: MYENVVAR ``` Since `v2.7`, APISIX will stop the runner with SIGTERM when it is running on OpenResty 1.19+. However, APISIX needs to wait for the runner to quit so that we can ensure the resource for the process group is freed. Therefore, we send SIGTERM first. And then after 1 second, if the runner is still running, we will send SIGKILL.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
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: Pipy (Orchestration & Management / Service Proxy)
File: README.md

This example uses Pipy to implement an HTTP reverse proxy with two functionalities: serving static files and proxying upstream applications. It also provides both HTTP and HTTPS access. The `www` directory contains static files. The `secret` directory contains the certificate and key files for HTTPS access. The file defines an HTTP proxy: `listen`: Configures the proxy to listen on ports `8080` (TCP) and `8443` (TLS). `services`: Configures the proxy services. The `foo` service is a `files` type service for serving static files. `www`: The directory containing the static files. The `bar` service is a `proxy` type service for proxying upstream applications. `targets`: The list of upstream application addresses. `rewrite`: The path rewrite rule. `routes`: Configures the proxy routes. Start three upstream services: ```shell $ nohup pipy -e "pipy().listen(9000).serveHTTP(()=>new Message('9000\n'))" & $ nohup pipy -e "pipy().listen(9001).serveHTTP(()=>new Message('9001\n'))" & $ nohup pipy -e "pipy().listen(9002).serveHTTP(()=>new Message('9002\n'))" & ``` Run the proxy: ```shell $ pipy main.js ``` Test: ```shell $ curl localhost:8080/ # Returns the static page. $ curl localhost:8080/api # Returns 9000. $ curl localhost:8080/api # Returns 9001. $ curl localhost:8080/api # Returns 9002. ``` econd, in each proxy instance, right before we forward a request to the backend service using muxHTTP(), we generate an empty request and send it to the globally shared single-threaded throttling service on port 8001 via a forkJoin() filter. The original request won't continue until the subpipeline forked out from forkJoin() ends up with a StreamEnd, meaning that a response is received from the throttling service. ```js pipy.listen(8000, $=>$ .demuxHTTP().to($=>$ .forkJoin([1]).to($=>$ // [1], [2] or [whatever], as long as its length is one .onStart(new Message) // Generate an empty request .muxHTTP({ version: 2 }).to($=>$ .connect('localhost:8001') ) .replaceMessage(new StreamEnd) // forkJoin() needs this to know it's over ) .muxHTTP().to($=>$ .connect('localhost:8080') ) ) ) ``` Because the messages being throttled at first are really just empty requests (well, almost empty requests, with only paths for deciding the rate limitations), which in turn limit the rate of the original requests, the communication between all proxy nodes and the central rate limiting service is kept minimal. To speed up the communication even further, we also leverage HTTP/2 for this matter.
Project: Traefik (Orchestration & Management / API Gateway)
File: influxdb2.md

To enable the InfluxDB2: ```yaml tab="File (YAML)" metrics: influxDB2: {} ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] ``` ```bash tab="CLI" --metrics.influxdb2=true ``` Required, Default="http://localhost:8086" Address of the InfluxDB v2 instance. ```yaml tab="File (YAML)" metrics: influxDB2: address: http://localhost:8086 ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] address = "http://localhost:8086" ``` ```bash tab="CLI" --metrics.influxdb2.address=http://localhost:8086 ``` Required, Default="" Token with which to connect to InfluxDB v2. ```yaml tab="File (YAML)" metrics: influxDB2: token: secret ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] token = "secret" ``` ```bash tab="CLI" --metrics.influxdb2.token=secret ``` Required, Default="" Organisation where metrics will be stored. ```yaml tab="File (YAML)" metrics: influxDB2: org: my-org ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] org = "my-org" ``` ```bash tab="CLI" --metrics.influxdb2.org=my-org ``` Required, Default="" Bucket where metrics will be stored. ```yaml tab="File (YAML)" metrics: influxDB2: bucket: my-bucket ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] bucket = "my-bucket" ``` ```bash tab="CLI" --metrics.influxdb2.bucket=my-bucket ``` Optional, Default=true Enable metrics on entry points. ```yaml tab="File (YAML)" metrics: influxDB2: addEntryPointsLabels: true ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] addEntryPointsLabels = true ``` ```bash tab="CLI" --metrics.influxdb2.addEntryPointsLabels=true ``` Optional, Default=false Enable metrics on routers. ```yaml tab="File (YAML)" metrics: influxDB2: addRoutersLabels: true ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] addRoutersLabels = true ``` ```bash tab="CLI" --metrics.influxdb2.addrouterslabels=true ``` Optional, Default=true Enable metrics on services. ```yaml tab="File (YAML)" metrics: influxDB2: addServicesLabels: true ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] addServicesLabels = true ``` ```bash tab="CLI" --metrics.influxdb2.addServicesLabels=true ``` Optional, Default=10s The interval used by the exporter to push metrics to InfluxDB server. ```yaml tab="File (YAML)" metrics: influxDB2: pushInterval: 10s ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] pushInterval = "10s" ``` ```bash tab="CLI" --metrics.influxdb2.pushInterval=10s ``` Optional, Default={} Additional labels (InfluxDB tags) on all metrics. ```yaml tab="File (YAML)" metrics: influxDB2: additionalLabels: host: example.com environment: production ``` ```toml tab="File (TOML)" [metrics] [metrics.influxDB2] [metrics.influxDB2.additionalLabels] host = "example.com" environment = "production" ``` ```bash tab="CLI" --metrics.influxdb2.additionallabels.host=example.com --metrics.influxdb2.additionallabels.environment=production ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Clusternet (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Welcome to Clusternet! First off, thanks for taking the time to contribute! The following is a set of guidelines for contributing to Clusternet. These are just guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. Clusternet follows the . By participating, you are expected to uphold this code. Feel free to get participated if you've found a bug and requested a new feature.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_setup.md

You can install the Gloo Edge command line, `glooctl`, to help install, configure, and debug Gloo Edge. Depending on your operating system, you have several installation options. macOS*: You can use the package manager. ```shell brew install glooctl ``` Most platforms*: You can use the following installation script, which requires Python to execute properly. ```bash curl -sL https://run.solo.io/gloo/install | sh export PATH=$HOME/.gloo/bin:$PATH ``` Windows*: You can use the following installation script, which requires OpenSSL to execute properly. ```pwsh (New-Object System.Net.WebClient).DownloadString("https://run.solo.io/gloo/windows/install") | iex $env:Path += ";$env:userprofile/.gloo/bin/" ``` Direct download*: You can download `glooctl` directly via the GitHub releases page. In your browser, navigate to the . Choose the version to upgrade `glooctl` to. For Gloo Edge Enterprise, use the Gloo Edge OSS version that corresponds to the Gloo Edge Enterprise version you want to upgrade to. To find the OSS version that corresponds to each Gloo Edge Enterprise release, see the . Click the version of `glooctl` that you want to install. In the Assets, download the `glooctl` package that matches your operating system, and follow your operating system procedures for replacing your existing `glooctl` binary file with the upgraded version. After downloading, rename the executable to `glooctl` and add it to your system's `PATH`. When it's time to upgrade Gloo Edge, make sure to update the `glooctl` version before upgrading. You can use the `glooctl upgrade` command to upgrade or roll back the `glooctl` version. For example, you might change versions during an upgrade process, or when you have multiple versions of Gloo Edge across clusters that you manage from the same workstation. For more options, run `glooctl upgrade --help`. Set the version to upgrade `glooctl` to in an environment variable. Include the patch version. For Gloo Edge Enterprise, specify the Gloo Edge OSS version that corresponds to the Gloo Edge Enterprise version you want to upgrade to. To find the OSS version that corresponds to each Gloo Edge Enterprise release, see the . ```sh export GLOOCTL_VERSION=<version> ``` Upgrade your version of `glooctl`. ```bash glooctl upgrade --release v${GLOOCTL_VERSION} ``` Verify the `glooctl` CLI is installed and running the appropriate version. In the output, the Client is your local version. The Server is the version that runs in your cluster, and is `undefined` if Gloo Edge is not installed yet. ```bash glooctl version ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: redshift.md

| Datasource | Description | |-|-| | Datasource | Select Redshift. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the Redshift service IP. | | Port | Enter the Redshift service port. | | Validation | Enter the Redshift authentication mode. | | Username | Set the username for Redshift connection. | | Password | Set the password for Redshift connection. | | Database Name | Enter the database name of the Redshift connection. | | jdbc connect parameters | Parameter settings for Redshift connection, in JSON format. | | AccessKeyID | Mode IAM-accessKey access key ID. | | SecretAccessKey | Mode IAM-accessKey secret access key. | Use AWS redshift database username and password to login. Use cluster ID, AWS Region, port(optional) and IAM to login. Yes, could use this datasource by default. Read more about Redshift IAM JDBC driver configuration reference document
Project: Sermant (Orchestration & Management / Service Mesh)
File: MAINTAINERS.md

Official list of Sermant Maintainers. Please keep the below list sorted in ascending order. | Maintainer | GitHub ID | Affiliation | Email | | - | -- | -- | - | | Lai Li | @lilai23 | Huawei | lilai1@huawei.com | | Haopeng Zhang | @hanbingleixue | Huawei | hanbingleixue@hotmail.com | | Yuyi Peng | @provenceee | Huawei | provenceee@foxmail.com | | Zhenyu Dai | @daizhenyu | Huawei | daizhenyu10@gmail.com |
Project: Gloo (Orchestration & Management / API Gateway)
File: conventions.md

Bash Go - - Errors: Error variables with a fixed string should start with `Err` - Error types should be descriptive and end with `Error` - See for more details about writing tests. Avoid package sprawl. Find an appropriate subdirectory for new packages. Avoid general utility packages. Packages called "util" are suspect and instead names that describe the desired function should be preferred. All filenames should be lowercase. Go source files and directories use underscores, not dashes. Package directories should generally avoid using separators as much as possible. When package names are multiple words, they usually should be in nested subdirectories. Document directories and filenames should use dashes rather than underscores.
Project: Gloo (Orchestration & Management / API Gateway)
File: graphql.proto.sk.md

title: "graphql.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Only supported in enterprise with the GraphQL addon. This is the service spec describing GraphQL upstreams. This will usually be filled automatically via function discovery (if the upstream supports introspection). If your upstream service is a GraphQL service, use this service spec (an empty spec is fine). ```yaml "endpoint": .graphql.options.gloo.solo.io.ServiceSpec.Endpoint ``` | Field | Type | Description | | -- | - | -- | | `endpoint` | | Endpoint provides the endpoint information, and how to call the GraphQL Server. This endpoint must be called via HTTP POST sending form data as mentioned in . | Describes a GraphQL Endpoint information ```yaml "url": string ``` | Field | Type | Description | | -- | - | -- | | `url` | `string` | The url for the graphql endpoint. Automation via Discovery only supports `http://<host>/graphql` ie: http://myurl.com/graphql. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-003.md

+++ date = "2016-11-11T16:38:32Z" description = "CoreDNS-003 Release Notes." release = "003" tags = ["Release", "003", "Notes"] title = "CoreDNS-003 Release" author = "coredns" +++ CoreDNS-003 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. Refused queries are properly logged and exported if metrics are enabled. proxy*: allow `/etc/resolv.conf` to be used in the configuration. metrics*: add tests and normalize some of the metrics. Removed the AXFR size metrics. cache*: Added size and capacity of the cache (for both `denial` and `success` cache types). Don't cache meta data records and zone transfers. dnssec*: metrics were unused, hooked them up: export size and capacity of the signature cache. loadbalance*: balance MX records as well. auto*: numerous bugfixes. file*: fix data race in reload process and also reload a zone when it is `mv`ed (newly created) into place. Also rewrite the zone lookup algorithm and be more standards compliant, esp. in the area of DNSSEC, wildcards and empty-non-terminals; handle secure delegations. kubernetes*: vendor the k8s dependency and updates to be compatible with Kubernetes 1.4 and 1.5. Multiple cleanups and fixes. Kubernetes services can now be resolved. The following people helped with getting this release done: Ben Kochie, Chris O'Haver, John Belamaric, Jonathan Dickinson, Manuel Alejandro de Brito Fontes, Michael Grosser, Miek Gieben, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: writing-kcp-aware-controllers.md

linkTitle: "kcp-aware controllers" weight: 1 description: > How to write a kcp-aware controller. When you need to get an object from a kcp-aware lister or an indexer, you can't just pass the object's name to the `Get()` function, like you do with a typical controller targeting Kubernetes. Projects using kcp's copy of client-go are using a modified key function. Here are what keys look like for an object `foo` for both cluster-scoped and namespace-scoped varieties: |Organization|Workspace|Logical Cluster|Namespace|Key| |-|-|-|-|-| |-|-|root|-|root|foo| |-|-|root|default|default/root|foo| |root|my-org|root:my-org|-|root:my-org|foo| |root|my-org|root:my-org|default|default/root:my-org|foo| |my-org|my-workspace|my-org:my-workspace|-|my-org:my-workspace|foo| |my-org|my-workspace|my-org:my-workspace|default|default/my-org:my-workspace|foo| Use the `github.com/kcp-dev/apimachinery/pkg/cache` package to encode and decode keys.