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

ngx\_http\_upstream\_session\_sticky\_module This module is a load balancing module. It sticks the session between client and backend server via cookie. In such case, it guarantees that requests from the same client are distributed to the same server. upstream foo { server 192.168.0.1; server 192.168.0.2; session_sticky; } server { location / { proxy_pass http://foo; } } upstream test { sessionsticky sessionsticky cookie=uid domain=www.xxx.com fallback=on path=/ mode=insert option=indirect; server 127.0.0.1:8080; } server { location / { sessionstickyhide_cookie upstream=test; proxy_pass http://test; } } Syntax: session_sticky `[cookie=name] [domain=yourdomain] [path=yourpath] [maxage=time] [mode=insert|rewrite|prefix] [option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]` Default: `session_sticky cookie=route mode=insert fallback=on` Context: `upstream` Description: This directive will turn on the session sticky module. Specific parameters are as follows: `cookie` sets name of session cookie. `domain` sets domain of cookie. It is not set by default. `path` sets url path of cookie. The default value is '/'. `maxage` set lifetime of cookie (cookie max-age attribute). If not set, it's a session cookie. It expires when the browser is closed. `mode` sets mode of cookie: insert: This mode inserts cookie into http response via Set-Cookie header. prefix: This mode doesn't generate new cookie, but it inserts specific prefix ahead of cookie value of http response (e.g. "Cookie: NAME=SRV~VALUE"). When client(browser) requests next time with this specific cookie, it will delete inserted prefix before passing request to backend server. The operation is transparent to backend server which will get origin cookie . rewrite: In this mode, backend server can set cookie of session sticky itself. If backend server doesn't set this cookie in response, it disables session sticky for this request. In this mode, backend server manages which request needs sesstion sticky. `option` sets option value(indirect and direct) for cookie of session sticky. If setting indirect, it hides cookie of session sticky from backend server, otherwise the opposite. `maxidle` sets max idle time of session. `maxlife` sets max lifetime of session. `fallback` sets whether it can retry others when current backend server is down. `hash` sets whether server flag in cookie is passed through plaintext or md5. By default, md5 is used. Syntax: session\_sticky\_hide\_cookie upstream=name; Default: none Context: server, location Description: This directive works with proxy_pass directive. It deletes cookie used as session sticky in insert+indirect and prefix mode, in which case cookie will be hidden from backend server. Upstream name specifies which upstream this directive takes effect in.
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve Capsule title: '' labels: blocked-needs-validation, bug assignees: '' <!-- Thanks for taking time reporting a Capsule bug! --> A clear and concise description of what the bug is. Steps to reproduce the behavior: Provide the Capsule Tenant YAML definitions Provide all managed Kubernetes resources A clear and concise description of what you expected to happen. If applicable, please provide logs of `capsule`. In a standard stand-alone installation of Capsule, you'd get this by running `kubectl -n capsule-system logs deploy/capsule-controller-manager`. Capsule version: (`capsule --version`) Helm Chart version: (`helm list -n capsule-system`) Kubernetes version: (`kubectl version`)
Project: BFE (Orchestration & Management / Service Proxy)
File: comparison.md

Here comparison will be made between BFE and several similar system. NOTE: Most of the projects below are under active development. Thus some of the information may become out of date. If that is the case please feedback to https://github.com/bfenetworks/bfe/issues. The brief descriptions of several systems are as follows: BFE: BFE is an open-source layer 7 load balancer. : nginx is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server. : Traefik is a modern HTTP reverse proxy and load balancer. : Envoy is an open source edge and service proxy, designed for cloud-native applications. All 4 systems support HTTPS and HTTP/2. BFE and Nginx only support "passive" health check. Traefik only supports "active" health check. Envoy supports active, passive and hybrid health check. NOTE: Nginx Plus (i.e., the commercial version of nginx) supports "active" health check. All 4 systems support instance-level load balancing. BFE, Traefik and Envoy support cluster-level load balancing. Nginx doesn't have this feature. NOTE: Envoy supports global and distributed load balancing. BFE provides . Nginx uses regular expression. Traefik supports traffic classification based on request content. But it can't support flexible AND or OR logic. Envoy supports rules based on Domain, Path and Header. Both BFE and Traefik are written in Golang Nginx is written in C and Lua. Envoy is written in C++. All 4 systems support pluggable architecture. Due to difference in language, cost for new features is lower for BFE and Traefik, while cost is higher for Nginx and Envoy. With recovery mechanism of Golang, Panic can be caught in BFE and Traefik. Both system are immune to sudden crash. While Nginx and Envoy can do nothing with wrong memory usage. Debugging such a bug is very time-consuming. BFE provides for external observation. Nginx and Traefik provide less internal status. Envoy also provides quite a lot internal status. All 4 systems support hot-reload of configuration. In Nginx, process must be restarted for the configuration to take effect, while active connections are terminated. NOTE: Nginx Plus supports hot-reload of configuration, with no process restart.
Project: Gloo (Orchestration & Management / API Gateway)
File: helm_advanced.md

title: "Last Mile Helm Chart Customization" menuTitle: "Kubernetes" description: How to make tweaks to the existing Gloo Edge Helm chart with Helm and Kustomize. weight: 20 Gloo Edge's helm chart is very customizable, but does not contain every possible kubernetes value you may want to tweak. In this document we will demonstrate a method of tweaking the helm release, without the need to directly modify Gloo Edge's helm chart. This allows you to tailor the installation manifests to your specific needs quickly and easily. We will use Helm 3.1 supports for . This allows us to tweak the rendered manifests just before they are applied to the cluster, without needed to modify the chart itself. In this example, we will add a `sysctl` value to the Gloo Edge's `gateway-proxy` pod. We are going to: Create customization file Create a patch to add our desired sysctl Demonstrate that it was applied correctly using `helm template` To complete this you will need: kubectl 1.14 OR kustomize helm 3.1 First, lets create the patch we want to apply. This patch will be merged to our existing objects, so it looks very similar to a regular deployment definition. We add a `securityContext` to the pod with out new sysctl value: ```bash cat > sysctl-patch.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: gateway-proxy spec: template: spec: securityContext: sysctls: name: net.netfilter.nfconntracktcptimeoutclose_wait value: "10" EOF ``` Helm post render works with stdin/stdout, and kustomize works with files. Let's bridge that gap with a shell script: ```bash cat > kustomize.sh <<EOF cat > base.yaml exec kubectl kustomize EOF chmod +x ./kustomize.sh ``` Finally, lets create our `kustomization.yaml` ```bash cat > kustomization.yaml <<EOF resources: base.yaml patchesStrategicMerge: sysctl-patch.yaml EOF ``` ```bash helm repo add gloo https://storage.googleapis.com/solo-public-helm helm repo update ``` We can render our chart using helm template and see our changes in it: ```bash helm template gloo/gloo --post-renderer ./kustomize.sh ``` In the output you will see our newly added sysctl: ```yaml mountPath: /etc/envoy name: envoy-config securityContext: sysctls: name: net.netfilter.nfconntracktcptimeoutclose_wait value: "10" ``` You can use this command to install \ upgrade your release: ```bash kubectl create ns gloo-system helm upgrade -i gloo gloo/gloo --namespace gloo-system --post-renderer ./kustomize.sh ``` Examine the `gateway-proxy` deployment, you will see the new value: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: gateway-proxy namespace: gloo-system spec: template: metadata: spec: securityContext: sysctls: name: net.netfilter.nfconntracktcptimeoutclose_wait value: "10" ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: doris.md

| Datasource | Description | |-|| | Datasource | Select DORIS. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the DORIS service IP.(If there are multiple IPs, please separate them with `,`) | | Port | Enter the DORIS service port. | | Username | Set the username for DORIS connection. | | Password | Set the password for DORIS connection. | | Database name | Enter the database name of the DORIS connection. | | Jdbc connection parameters | Parameter settings for DORIS connection, in JSON format. | No, read section example in `DataSource Center` section to activate this datasource.
Project: APISIX (Orchestration & Management / API Gateway)
File: api-gateway.md

title: API Gateway keywords: Apache APISIX API Gateway Gateway description: This article mainly introduces the role of the API gateway and why it is needed. <!-- --> An API gateway is a software pattern that sits in front of an application programming interface (API) or group of microservices, to facilitate requests and delivery of data and services. Its primary role is to act as a single entry point and standardized process for interactions between an organization's apps, data, and services and internal and external customers. The API gateway can also perform various other functions to support and manage API usage, from authentication to rate limiting to analytics. An API gateway also acts as a gateway between the API and the underlying infrastructure. It can be used to route requests to different backends, such as a load balancer, or route requests to different services based on the request headers. An API gateway comes with a lot of benefits over a traditional API microservice. The following are some of the benefits: It is a single entry point for all API requests. It can be used to route requests to different backends, such as a load balancer, or route requests to different services based on the request headers. It can be used to perform authentication, authorization, and rate-limiting. It can be used to support analytics, such as monitoring, logging, and tracing. It can protect the API from malicious attack vectors such as SQL injections, DDOS attacks, and XSS. It decreases the complexity of the API and microservices.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: disk-du.md

title: Apache Mesos - Disk Isolator Based on 'du' in Mesos Containerizer layout: documentation The `disk/du` (previously `posix/disk`) isolator provides basic disk isolation. It is able to report the disk usage for each sandbox and optionally enforce the disk quota. It can be used on both Linux and OS X. To enable the `disk/du` isolator, append `disk/du` to the `--isolation` flag when starting the agent. By default, the disk quota enforcement is disabled. To enable it, specify `--enforcecontainerdisk_quota` when starting the agent. The `disk/du` isolator reports disk usage for each sandbox by periodically running the `du` command. The disk usage can be retrieved from the resource statistics endpoint (). The interval between two `du`s can be controlled by the agent flag `--containerdiskwatch_interval`. For example, `--containerdiskwatch_interval=1mins` sets the interval to be 1 minute. The default interval is 15 seconds.
Project: Nasp (Orchestration & Management / Service Mesh)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at <CISCOEMAILADDRESS>. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_check.md

title: "glooctl check" weight: 5 Checks Gloo resources for errors (requires Gloo running on Kubernetes) usage: glooctl check [-o FORMAT] ``` glooctl check [flags] ``` ``` -x, --exclude strings check to exclude: (deployments, pods, upstreams, upstreamgroup, auth-configs, rate-limit-configs, secrets, virtual-services, gateways, proxies, xds-metrics) -h, --help help for check -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (json, table) (default table) -p, --pod-selector string Label selector for pod scanning (default "gloo") --read-only only do checks that dont require creating resources (i.e. port forwards) -r, --resource-namespaces stringArray Namespaces in which to scan gloo custom resources. If not provided, all watched namespaces (as specified in settings) will be scanned. ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - CLI for Gloo
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.5.2.md

+++ title = "CoreDNS-1.5.2 Release" description = "CoreDNS-1.5.2 Release Notes." tags = ["Release", "1.5.2", "Notes"] release = "1.5.2" date = 2019-07-03T07:35:47+01:00 author = "coredns" +++ The CoreDNS team has released . Small bugfixes and a change to Caddy's import path (mholt/caddy -> caddyserver/caddy). Doing a release helps plugins deal with the change better. For all plugins that use the `upstream` directive it use removed from the documentation; it's still accepted but is a noop. Currently these plugins use CoreDNS to resolve external queries. The plugin now supports meta data. The plugin closes the connection after an AXFR. It also loads secondary zones lazily on startup. bcebere, John Belamaric, JINMEI Tatuya, Miek Gieben, Timoses, Yong Tang. plugin/file: close correctly after AXFR (https://github.com/coredns/coredns/pull/2943) plugin/file: load secondary zones lazily on startup (https://github.com/coredns/coredns/pull/2944) plugin/template: support metadata (https://github.com/coredns/coredns/pull/2958) build: Update Caddy to 1.0.1, and update import path (https://github.com/coredns/coredns/pull/2961) plugins: set upstream unconditionally (https://github.com/coredns/coredns/pull/2956) tls: hardening (https://github.com/coredns/coredns/pull/2938)
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: hardware.md

This section briefs about the hardware requirements for DolphinScheduler. DolphinScheduler works as an open-source distributed workflow task scheduling system. It can deploy and run smoothly in Intel architecture server environments and mainstream virtualization environments. It also supports mainstream Linux operating system environments and ARM architecture. The Linux operating systems specified below can run on physical servers and mainstream virtualization environments such as VMware, KVM, and XEN. | Operating System | Version | |:-|::| | Red Hat Enterprise Linux | 7.0 and above | | CentOS | 7.0 and above | | Oracle Enterprise Linux | 7.0 and above | | Ubuntu LTS | 16.04 and above | Note: The above Linux operating systems can run on physical servers and mainstream virtualization environments such as VMware, KVM, and XEN. DolphinScheduler supports 64-bit hardware platforms with Intel x86-64 architecture. The following table shows the recommended server requirements in a production environment: | CPU | MEM | HD | NIC | Num | |||--||| | 4 core+ | 8 GB+ | SAS | GbE | 1+ | Note: The above recommended configuration is the minimum configuration for deploying DolphinScheduler. Higher configuration is strongly recommended for production environments. The recommended hard disk size is more than 50GB and separate the system disk and data disk. DolphinScheduler provides the following network port configurations for normal operation: | Server | Port | Desc | |-|-|-| | MasterServer | 5678 | not the communication port, require the native ports do not conflict | | WorkerServer | 1234 | not the communication port, require the native ports do not conflict | | ApiApplicationServer | 12345 | backend communication port | Note: MasterServer and WorkerServer do not need to enable communication between the networks. As long as the local ports do not conflict. Administrators can adjust relevant ports on the network side and host-side according to the deployment plan of DolphinScheduler components in the actual environment. The minimum supported version of Google Chrome is version 85, but version 90 or above is recommended. To avoid problems with internal cluster communications that can impact your task execution, make sure that the clocks on all of the cluster nodes are synchronized from a common clock source, such as using Chrony and/or NTP. Synchronizing the time ensures that every node in the cluster has the same time.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: index.md

Kusk is a Kubernetes API gateway powered by . The main difference with other API Gateways is that Kusk has native support for . Modern REST APIs are developed using OpenAPI specification that is then used to generate API documentation, tests, server stubs and clients all from the OpenAPI definition. Kusk enables the use of OpenAPI definitions to configure the Ingress Controller of your Kubernetes clusters: By using OpenAPI and Kusk you can: Rapidly prototype your APIs by mocking your API responses Protect your endpoints with automatic request and response validations Configure critical policies like request timeouts and CORS with no coding required Centrally manage your APIs from an open source dashboard Check out our section to install Kusk Gateway, deploy an example API and connect a service to the API.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_install_ingress.md

title: "glooctl install ingress" weight: 5 install the Gloo Ingress Controller on Kubernetes requires kubectl to be installed ``` glooctl install ingress [flags] ``` ``` --create-namespace Create the namespace to install gloo into (default true) -d, --dry-run Dump the raw installation yaml instead of applying it to kubernetes -f, --file string Install Gloo from this Helm chart archive file rather than from a release -h, --help help for ingress -n, --namespace string namespace to install gloo into (default "gloo-system") --release-name string helm release name (default "gloo") --values strings List of files with value overrides for the Gloo Helm chart, (e.g. --values file1,file2 or --values file1 --values file2) --version string version to install (e.g. 1.4.0, defaults to latest) ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) -v, --verbose If true, output from kubectl commands will print to stdout/stderr ``` - install gloo on different platforms