## 1. Project Overview & Quickstart (cncf/landscape) ## File: README.md # Cloud Native Landscape The [CNCF](https://www.cncf.io) Cloud Native [Landscape](https://landscape.cncf.io) is intended as a map through the previously uncharted terrain of cloud native technologies. This attempts to categorize most of the projects and product offerings in the cloud native space. There are many routes to deploying a cloud native application, with CNCF Projects representing a particularly well-traveled path. This repository contains the data files and images required to generate the [CNCF landscape](https://landscape.cncf.io). The software that generates it can be found at the [cncf/landscape2](https://github.com/cncf/landscape2) repository. Please see its [README file](https://github.com/cncf/landscape2#landscape2) for more information about how it works. ## New entries To add a new entry to the landscape, please open a pull request to add it in alphabetical order to the [landscape.yml](landscape.yml) file. The logo must be added to the `hosted_logos` directory (in SVG format) and referenced from the `logo` field. Before submitting a new entry it is important to review the following guidelines: * [Cloud native](https://github.com/cncf/toc/blob/main/DEFINITION.md) projects with at least 300 GitHub stars that clearly fit in an existing category are generally included. Put the project in the single category where it best fits. * We generally will only list a company's product in one box, to represent its major or best-known offering. We occasionally make exceptions for large companies. Note that if we allowed listing the same product or project in multiple boxes, the over +1k logos on the landscape would multiply to many times that many. * We are unlikely to create a new category for products/projects as we'd rather find the best home with the current options. * We are generally not including commercial versions of open source software. The exception is that we are showing all Certified Kubernetes implementations. * Closed source products need to link to a clear description of your product; no stealth mode companies. * Crunchbase organization should be the company or organization that controls the software. That is normally the owner of the trademark, whether or not a trademark has been formally filed. * Your project or company needs a logo in SVG format: * Logos must include the company, product or project name in English. It's fine to also include words from another language. * Don't use reversed logos (i.e. with a non-white, non-transparent background color). * When multiple variants exist, use stacked (not horizontal) logos. > [!NOTE] > At the moment the landscape is generated daily, so once your PR is merged your changes should be visible before 24 hours. ## Extra fields The `extra` section in the landscape.yml file allows you to include various fields to provide essential details about your project. This section helps users understand the project's purpose and find more information. For a detailed list of possible fields please refer to the [Extra Fields Documentation](https://github.com/cncf/landscape2/blob/main/docs/config/data.yml). ## Technical Advisory Groups (TAG) Projects can specify which TAG owns them in the `landscape.yml` file. This can be achieved by setting the `tag` field in the `extra` item's section to one of the following values: * `app-delivery` * `contributor-strategy` * `environmental-sustainability` * `network` * `observability` * `runtime` * `security` * `storage` When this information is not provided, we'll try to detect it automatically based on the [TAGs configuration section of the settings file](https://github.com/cncf/landscape2-sites/blob/4f24e07b22ab4cc05b8211c9ce5184797e931631/cncf/settings.yml#L277-L359). The automatic detection is based on a [pre-defined mapping between categories/subcategories and TAGs](https://github.com/cncf/landscape2-sites/blob/4f24e07b22ab4cc05b8211c9ce5184797e931631/cncf/settings.yml#L277-L359), so it may not be accurate in some cases. In those cases, the recommended approach is to provide the TAG manually as explained above. If you find an item with an incorrect TAG, we'd really appreciate if you could open a pull request to provide the correct one. ## Corrections If you find an error in the landscape, please open a pull request with the suggested changes to the [landscape.yml](landscape.yml) file. Some information displayed in the landscape is obtained from Crunchbase or GitHub, so errors on it should be fixed in the corresponding source. ## License The generated landscape contains data received from [Crunchbase](http://www.crunchbase.com). This data is not licensed pursuant to the Apache License. It is subject to Crunchbase’s Data Access Terms, available at [https://data.crunchbase.com/docs/terms](https://data.crunchbase.com/docs/terms), and is only permitted to be used with Linux Foundation landscape projects. Everything else is under the Apache License, Version 2.0, except for projects and products logos, which are generally copyrighted by the company that created them, and are simply cached here for reliability. The generated landscape and the [landscape.yml](landscape.yml) file are alternatively available under the [Creative Commons Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/). --- ## File: docs/item_summary.md # Item summary The landscape is able to display a summary section in the item's detail view when the required information is provided in the `landscape.yml` file. This information must be located in the `extra` section of the corresponding entry, and the available fields are described in the *reference* section below. > [!NOTE] > Please note that to update this information you have to be a project owner, maintainer, or have some type of strong project affiliation. ## Reference ```yaml ## (sample taken from Dragonfly) extra: summary_personas: SREs, Cloud Architects, Platform Engineers, DevOps Engineer, DevOps practitioners, DevSecOps practitioners summary_tags: image acceleration, file distribution, images, OCI, container, artefacts, registry, cloud native, p2p, dragonfly, d7y, nydus summary_use_case: >- Provide efficient, stable, securefile distribution and image acceleration based on p2p technology to be the best practice and standard solution in cloud native architectures. It is widely used in the fields of image distribution, file distribution, log distribution, inference model distribution, etc. summary_business_use_case: >- Reduce back-to-source download traffic and back-to-source requests, improve node idle bandwidth utilization. Solve the problem of insufficient bandwidth or overload to download resources when accessing centralized container registry or file service in large-scale Kubernetes cluster. Based on P2P technology, reduce the bandwidth and load of container registry or file service, and accelerate the download speed of images or files. summary_release_rate: Major release every 2 months. summary_integrations: >- Harbor, Docker, Containerd, CRI-O, Podman, ORAS, Nydus, eStargz, HDFS, AWS S3, Google GCS, Azure Blob, Aliyun OSS, HWC OBS, TensorFlow Serving, Triton Server, TorchServe summary_intro_url: https://www.youtube.com/watch?v=TsECBaAvm-g ``` **Target Users:** (summary_personas) Who is this project for? Who'll be using it? Developers, SRE/DevOps Engineers, Architects? **Tags:** (summary_tags) Add tags that describe your project's properties. Please focus on technical features. The goal is for the user to differentiate and compare projects on a high level. Tags will allow them to infer project features, qualities, and properties. Example: KubeEdge, Akri, OpenYurt, and SuperEdge will likely all share the Edge tag indicating that they relate to the network edge. OpenYurt and SuperEdge may also share the IoT tag, while KubeEdge and Akri won't. Metal3-io’s tags might show it to be the only project dealing with baremetal and provisioning. **Use case:** (summary_use_case) Focus on the technical problem your project solves. Why would someone need it? What technical pain points does it address? Be brief and limit your description to 500 characters. **Business use:** (summary_business_use_case) Comment on your project's business use case. How would it bring value to an organization? Does it reduce risk of some type (e.g., regulatory, reputational), or increase responsiveness to customer demand? Does it increase security in a way that reduces business support costs? What is the business problem your project is trying to solve? Be brief and limit your description to 500 characters. **Release cadence:** (summary_release_rate) How often do you release a new version? **Integrations:** (summary_integrations) What does it integrate with? **Overview video:** (summary_intro_url) Optional: 5 min product pitch. Same thing as above, but delivered in video format. ## 2. Official Technical Reference & Guides (cncf/website) # The Kubernetes documentation [](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](https://github.com/kubernetes/website/releases/latest) This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! + [Contributing to the docs](#contributing-to-the-docs) + [Localization ReadMes](#localization-readmemds) # Using this repository You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website. ## Prerequisites To use this repository, you need the following installed locally: - [npm](https://www.npmjs.com/) - [Go](https://golang.org/) - [Hugo (Extended version)](https://gohugo.io/) - A container runtime, like [Docker](https://www.docker.com/). Before you start, install the dependencies. Clone the repository and navigate to the directory: ``` git clone https://github.com/kubernetes/website.git cd website ``` The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following: ``` # pull in the Docsy submodule git submodule update --init --recursive --depth 1 ``` ## Running the website using a container To build the site in a container, run the following to build the container image and run it: ``` make container-image make container-serve ``` Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. ## Running the website locally using Hugo Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file. To build and test the site locally, run: ```bash # install dependencies npm ci make serve ``` This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh. ## Building the API reference pages The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs. To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to): 1. Pull the `kubernetes-resources-reference` submodule: ``` git submodule update --init --recursive --depth 1 ``` 2. Create a new API revision into the submodule, and add the Swagger specification: ``` mkdir api-ref-generator/gen-resourcesdocs/api/v1.20 curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-generator/gen-resourcesdocs/api/v1.20/swagger.json ``` 3. Copy the table of contents and fields configuration for the new release from a previous one: ``` mkdir api-ref-generator/gen-resourcesdocs/api/v1.20 cp api-ref-generator/gen-resourcesdocs/api/v1.19/* api-ref-generator/gen-resourcesdocs/api/v1.20/ ``` 4. Adapt the files `toc.yaml` and `fields.yaml` to reflect the changes between the two releases 5. Next, build the pages: ``` make api-reference ``` You can test the results locally by making and serving the site from a container image: ``` make container-image make container-serve ``` 6. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages. ## Troubleshooting ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version Hugo is shipped in two set of binaries for technical reasons. The current website runs based on the **Hugo Extended** version only. In the [release page](https://github.com/gohugoio/hugo/releases) look for archives with `extended` in the name. To confirm, run `hugo version` and look for the word `extended`. ### Troubleshooting macOS for too many open files If you run `make serve` on macOS and receive the following error: ``` ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files make: *** [serve] Error 1 ``` Try checking the current limit for open files: `launchctl limit maxfiles` Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c): ```shell #!/bin/sh # These are the original gist links, linking to my gists now. # curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist # curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist sudo mv limit.maxfiles.plist /Library/LaunchDaemons sudo mv limit.maxproc.plist /Library/LaunchDaemons sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist ``` This works for Catalina as well as Mojave macOS. # Get involved with SIG Docs Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). You can also reach the maintainers of this project at: - [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/) - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) # Contributing to the docs You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.** Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances. For more information about contributing to the Kubernetes documentation, see: * [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/) * [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/) * [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/) # Localization `README.md`'s | Language | Language | |---|---| |[Chinese](README-zh.md)|[Korean](README-ko.md)| |[French](README-fr.md)|[Polish](README-pl.md)| |[German](README-de.md)|[Portuguese](README-pt.md)| |[Hindi](README-hi.md)|[Russian](README-ru.md)| |[Indonesian](README-id.md)|[Spanish](README-es.md)| |[Italian](README-it.md)|[Ukrainian](README-uk.md)| |[Japanese](README-ja.md)|[Vietnamese](README-vi.md)| # Code of conduct Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). # Thank you! Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!