landscape Documentation

1. Project Overview & Quickstart (cncf/landscape) Copy Chapter

File: README.md Copy Chapter

Cloud Native Landscape

The CNCF Cloud Native Landscape 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. The software that generates it can be found at the cncf/landscape2 repository. Please see its README file for more information about how it works.

New entries Copy Chapter

To add a new entry to the landscape, please open a pull request to add it in alphabetical order to the 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 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 Copy Chapter

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.

Technical Advisory Groups (TAG) Copy Chapter

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. The automatic detection is based on a pre-defined mapping between categories/subcategories and TAGs, 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 Copy Chapter

If you find an error in the landscape, please open a pull request with the suggested changes to the 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 Copy Chapter

The generated landscape contains data received from Crunchbase. 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, 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 file are alternatively available under the Creative Commons Attribution 4.0 license.

File: docs/item_summary.md Copy Chapter

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 Copy Chapter

## (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) Copy Chapter

The Kubernetes documentation

This repository contains the assets required to build the Kubernetes website and documentation. We're glad that you want to contribute!

• Contributing to the docs
• Localization ReadMes

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 Copy Chapter

To use this repository, you need the following installed locally:

• npm
• Go
• Hugo (Extended version)
• A container runtime, like Docker.

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. 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 Copy Chapter

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 Copy Chapter

Make sure to install the Hugo extended version specified by the HUGO_VERSION environment variable in the netlify.toml file.

To build and test the site locally, run:

# 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 Copy Chapter

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 Copy Chapter

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 Copy Section

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 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 Copy Section

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):

#!/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.

You can also reach the maintainers of this project at:

• Slack Get an invite for this Slack
• Mailing List

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
• Page Content Types
• Documentation Style Guide
• Localizing Kubernetes Documentation

Localization `README.md`'s

Code of conduct

Participation in the Kubernetes community is governed by the CNCF Code of Conduct.

Thank you!

Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!