whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of github.com:kubernetes/website into pt-controllers-cronjobs

Browse Source
This commit is contained in:
Jhon Mike
2020-04-08 12:15:24 -03:00
parent 5ed756714e 2d8009bd8d
commit c668f57f4d
147 changed files with 5841 additions and 1882 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2020-04-06-API-Priority-and-Fairness-Alpha.md
+68
View File
@@ -0,0 +1,68 @@
---
layout: blog
title: "API Priority and Fairness Alpha"
date: 2020-04-06
slug: kubernetes-1-18-feature-api-priority-and-fairness-alpha
---
**Authors:** Min Kim (Ant Financial), Mike Spreitzer (IBM), Daniel Smith (Google)
This blog describes “API Priority And Fairness”, a new alpha feature in Kubernetes 1.18. API Priority And Fairness permits cluster administrators to divide the concurrency of the control plane into different weighted priority levels. Every request arriving at a kube-apiserver will be categorized into one of the priority levels and get its fair share of the control plane’s throughput.
## What problem does this solve?
Today the apiserver has a simple mechanism for protecting itself against CPU and memory overloads: max-in-flight limits for mutating and for readonly requests. Apart from the distinction between mutating and readonly, no other distinctions are made among requests; consequently, there can be undesirable scenarios where one subset of the requests crowds out other requests.
In short, it is far too easy for Kubernetes workloads to accidentally DoS the apiservers, causing other important traffic--like system controllers or leader elections---to fail intermittently. In the worst cases, a few broken nodes or controllers can push a busy cluster over the edge, turning a local problem into a control plane outage.
## How do we solve the problem?
The new feature “API Priority and Fairness” is about generalizing the existing max-in-flight request handler in each apiserver, to make the behavior more intelligent and configurable. The overall approach is as follows.
1. Each request is matched by a _Flow Schema_. The Flow Schema states the Priority Level for requests that match it, and assigns a “flow identifier” to these requests. Flow identifiers are how the system determines whether requests are from the same source or not.
2. Priority Levels may be configured to behave in several ways. Each Priority Level gets its own isolated concurrency pool. Priority levels also introduce the concept of queuing requests that cannot be serviced immediately.
3. To prevent any one user or namespace from monopolizing a Priority Level, they may be configured to have multiple queues. [“Shuffle Sharding”](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/#What_is_shuffle_sharding.3F) is used to assign each flow of requests to a subset of the queues.
4. Finally, when there is capacity to service a request, a [“Fair Queuing”](https://en.wikipedia.org/wiki/Fair_queuing) algorithm is used to select the next request. Within each priority level the queues compete with even fairness.
Early results have been very promising! Take a look at this [analysis](https://github.com/kubernetes/kubernetes/pull/88177#issuecomment-588945806).
## How do I try this out?
You are required to prepare the following things in order to try out the feature:
* Download and install a kubectl greater than v1.18.0 version
* Enabling the new API groups with the command line flag `--runtime-config="flowcontrol.apiserver.k8s.io/v1alpha1=true"` on the kube-apiservers
* Switch on the feature gate with the command line flag `--feature-gates=APIPriorityAndFairness=true` on the kube-apiservers
After successfully starting your kube-apiservers, you will see a few default FlowSchema and PriorityLevelConfiguration resources in the cluster. These default configurations are designed for a general protection and traffic management for your cluster.
You can examine and customize the default configuration by running the usual tools, e.g.:
* `kubectl get flowschemas`
* `kubectl get prioritylevelconfigurations`
## How does this work under the hood?
Upon arrival at the handler, a request is assigned to exactly one priority level and exactly one flow within that priority level. Hence understanding how FlowSchema and PriorityLevelConfiguration works will be helping you manage the request traffic going through your kube-apiservers.
* FlowSchema: FlowSchema will identify a PriorityLevelConfiguration object and the way to compute the request’s “flow identifier”. Currently we support matching requests according to: the identity making the request, the verb, and the target object. The identity can match in terms of: a username, a user group name, or a ServiceAccount. And as for the target objects, we can match by apiGroup, resource[/subresource], and namespace.
* The flow identifier is used for shuffle sharding, so it’s important that requests have the same flow identifier if they are from the same source! We like to consider scenarios with “elephants” (which send many/heavy requests) vs “mice” (which send few/light requests): it is important to make sure the elephant’s requests all get the same flow identifier, otherwise they will look like many different mice to the system!
* See the API Documentation [here](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)!
* PriorityLevelConfiguration: Defines a priority level.
* For apiserver self requests, and any reentrant traffic (e.g., admission webhooks which themselves make API requests), a Priority Level can be marked “exempt”, which means that no queueing or limiting of any sort is done. This is to prevent priority inversions.
* Each non-exempt Priority Level is configured with a number of "concurrency shares" and gets an isolated pool of concurrency to use. Requests of that Priority Level run in that pool when it is not full, never anywhere else. Each apiserver is configured with a total concurrency limit (taken to be the sum of the old limits on mutating and readonly requests), and this is then divided among the Priority Levels in proportion to their concurrency shares.
* A non-exempt Priority Level may select a number of queues and a "hand size" to use for the shuffle sharding. Shuffle sharding maps flows to queues in a way that is better than consistent hashing. A given flow has access to a small collection of queues, and for each incoming request the shortest queue is chosen. When a Priority Level has queues, it also sets a limit on queue length. There is also a limit placed on how long a request can wait in its queue; this is a fixed fraction of the apiserver's request timeout. A request that cannot be executed and cannot be queued (any longer) is rejected.
* Alternatively, a non-exempt Priority Level may select immediate rejection instead of waiting in a queue.
* See the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) for this feature.
## What’s missing? When will there be a beta?
We’re already planning a few enhancements based on alpha and there will be more as users send feedback to our community. Here’s a list of them:
* Traffic management for WATCH and EXEC requests
* Adjusting and improving the default set of FlowSchema/PriorityLevelConfiguration
* Enhancing observability on how this feature works
* Join the discussion [here](https://github.com/kubernetes/enhancements/pull/1632)
Possibly treat LIST requests differently depending on an estimate of how big their result will be.
## How can I get involved?
As always! Reach us on slack [#sig-api-machinery](https://kubernetes.slack.com/messages/sig-api-machinery), or through the [mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-api-machinery). We have lots of exciting features to build and can use all sorts of help.
Many thanks to the contributors that have gotten this feature this far: Aaron Prindle, Daniel Smith, Jonathan Tomer, Mike Spreitzer, Min Kim, Bruce Ma, Yu Liao!
content/en/docs/concepts/architecture/master-node-communication.md
+17 -2
View File
@@ -97,13 +97,28 @@ public networks.
### SSH Tunnels
Kubernetes supports SSH tunnels to protect the Master -> Cluster communication
Kubernetes supports SSH tunnels to protect the Master → Cluster communication
paths. In this configuration, the apiserver initiates an SSH tunnel to each node
in the cluster (connecting to the ssh server listening on port 22) and passes
all traffic destined for a kubelet, node, pod, or service through the tunnel.
This tunnel ensures that the traffic is not exposed outside of the network in
which the nodes are running.
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. A replacement for this communication channel is being designed.
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you
know what you are doing. The Konnectivity service is a replacement for this
communication channel.
### Konnectivity service
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
As a replacement to the SSH tunnels, the Konnectivity service provides TCP
level proxy for the Master → Cluster communication. The Konnectivity consists of
two parts, the Konnectivity server and the Konnectivity agents, running in the
Master network and the Cluster network respectively. The Konnectivity agents
initiate connections to the Konnectivity server and maintain the connections.
All Master → Cluster traffic then goes through these connections.
See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set
it up in your cluster.
{{% /capture %}}
content/en/docs/concepts/cluster-administration/flow-control.md
+4 -4
View File
@@ -18,12 +18,12 @@ potentially crashing the API server, but these flags are not enough to ensure
that the most important requests get through in a period of high traffic.
The API Priority and Fairness feature (APF) is an alternative that improves upon
aforementioned max-inflight limitations. APF classifies
and isolates requests in a more fine-grained way. It also introduces
aforementioned max-inflight limitations. APF classifies
and isolates requests in a more fine-grained way. It also introduces
a limited amount of queuing, so that no requests are rejected in cases
of very brief bursts. Requests are dispatched from queues using a
fair queuing technique so that, for example, a poorly-behaved {{<
glossary_tooltip text="controller" term_id="controller" >}}) need not
fair queuing technique so that, for example, a poorly-behaved
{{< glossary_tooltip text="controller" term_id="controller" >}} need not
starve others (even at the same priority level).
{{< caution >}}
content/en/docs/concepts/cluster-administration/manage-deployment.md
+1 -1
View File
@@ -427,7 +427,7 @@ We'll guide you through how to create and update applications with Deployments.
Let's say you were running version 1.14.2 of nginx:
```shell
kubectl run my-nginx --image=nginx:1.14.2 --replicas=3
kubectl create deployment my-nginx --image=nginx:1.14.2
```
```shell
deployment.apps/my-nginx created
content/en/docs/concepts/services-networking/service.md
+19
View File
@@ -534,6 +534,25 @@ to just expose one or more nodes' IPs directly.
Note that this Service is visible as `<NodeIP>:spec.ports[*].nodePort`
and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
For example:
```yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
app: MyApp
ports:
# By default and for convenience, the `targetPort` is set to the same value as the `port` field.
- port: 80
targetPort: 80
# Optional field
# By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
nodePort: 30007
```
### Type LoadBalancer {#loadbalancer}
On cloud providers which support external load balancers, setting the `type`
content/en/docs/concepts/storage/persistent-volumes.md
+2 -2
View File
@@ -28,9 +28,9 @@ This document describes the current state of _persistent volumes_ in Kubernetes.
Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted once read/write or many times read-only).
While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the _StorageClass_ resource.
content/en/docs/concepts/workloads/pods/init-containers.md
+7 -4
View File
@@ -71,8 +71,8 @@ have some advantages for start-up related code:
a mechanism to block or delay app container startup until a set of preconditions are met. Once
preconditions are met, all of the app containers in a Pod can start in parallel.
* Init containers can securely run utilities or custom code that would otherwise make an app
container image less secure. By keeping unnecessary tools separate you can limit the attack
surface of your app container image.
container image less secure. By keeping unnecessary tools separate you can limit the attack
surface of your app container image.
### Examples
@@ -245,8 +245,11 @@ init containers. [What's next](#what-s-next) contains a link to a more detailed
## Detailed behavior
During the startup of a Pod, each init container starts in order, after the
network and volumes are initialized. Each container must exit successfully before
During Pod startup, the kubelet delays running init containers until the networking
and storage are ready. Then the kubelet runs the Pod's init containers in the order
they appear in the Pod's spec.
Each init container must exit successfully before
the next container starts. If a container fails to start due to the runtime or
exits with failure, it is retried according to the Pod `restartPolicy`. However,
if the Pod `restartPolicy` is set to Always, the init containers use
content/en/docs/contribute/_index.md
+50 -35
View File
@@ -4,59 +4,74 @@ title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
weight: 80
card:
name: contribute
weight: 10
title: Start contributing
---
{{% capture overview %}}
If you would like to help contribute to the Kubernetes documentation or website,
we're happy to have your help! Anyone can contribute, whether you're new to the
project or you've been around a long time, and whether you self-identify as a
developer, an end user, or someone who just can't stand seeing typos.
This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
Kubernetes documentation contributors:
- Improve existing content
- Create new content
- Translate the documentation
- Manage and publish the documentation parts of the Kubernetes release cycle
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
{{% /capture %}}
{{% capture body %}}
## Getting Started
## Getting started
Anyone can open an issue describing problems or desired improvements with documentation, or contribute a change with a pull request (PR).
Some tasks require more trust and need more access in the Kubernetes organization.
See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
of roles and permissions.
Kubernetes documentation resides in a GitHub repository. While we welcome
contributions from anyone, you do need basic comfort with git and GitHub to
operate effectively in the Kubernetes community.
Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
3. Make sure you understand the basic processes for [improving content](https://kubernetes.io/docs/contribute/start/#improve-existing-content) and [reviewing changes](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests).
3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/open-a-pr/) and [reviewing changes](/docs/contribute/review/reviewing-prs/).
## Contributions best practices
Some tasks require more trust and more access in the Kubernetes organization.
See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
roles and permissions.
- Do write clear and meaningful GIT commit messages.
- Make sure to include _Github Special Keywords_ which references the issue and automatically closes the issue when PR is merged.
- When you make a small change to a PR like fixing a typo, any style change, or changing grammar. Make sure you squash your commits so that you dont get a large number of commits for a relatively small change.
- Make sure you include a nice PR description depicting the code you have changes, why to change a following piece of code and ensuring there is sufficient information for the reviewer to understand your PR.
- Additional Readings :
- [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
- [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
- [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )
## Your first contribution
- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute.
- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
- Learn how to [use page templates](/docs/contribute/style/page-templates/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to make bigger changes.
## Next steps
- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the repository.
- Document [features in a release](/docs/contribute/new-content/new-features/).
- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities).
- Start or help with a [localization](/docs/contribute/localization/).
## Get involved with SIG Docs
[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the webwsite. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project.
SIG Docs communicates with different methods:
- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
## Other ways to contribute
- To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/).
- To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started.
- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
{{% /capture %}}
{{% capture whatsnext %}}
- For more information about the basics of contributing to documentation, read [Start contributing](/docs/contribute/start/).
- Follow the [Kubernetes documentation style guide](/docs/contribute/style/style-guide/) when proposing changes.
- For more information about SIG Docs, read [Participating in SIG Docs](/docs/contribute/participating/).
- For more information about localizing Kubernetes docs, read [Localizing Kubernetes documentation](/docs/contribute/localization/).
{{% /capture %}}
{{% /capture %}}
content/en/docs/contribute/advanced.md
+24 -24
View File
@@ -2,14 +2,14 @@
title: Advanced contributing
slug: advanced
content_template: templates/concept
weight: 30
weight: 98
---
{{% capture overview %}}
This page assumes that you've read and mastered the
[Start contributing](/docs/contribute/start/) and
[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready
This page assumes that you understand how to
[contribute to new content](/docs/contribute/new-content/overview) and
[review others' work](/docs/contribute/review/reviewing-prs/), and are ready
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
@@ -19,7 +19,7 @@ client and other tools for some of these tasks.
## Be the PR Wrangler for a week
SIG Docs [approvers](/docs/contribute/participating/#approvers) take regular turns as the PR wrangler for the repository and are added to the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers#2019-schedule-q1q2) for weekly rotations.
SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
The PR wrangler’s duties include:
@@ -37,9 +37,9 @@ The PR wrangler’s duties include:
- Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status.
- Assign`Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed.
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata.
- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
### Helpful GitHub queries for wranglers
@@ -60,9 +60,9 @@ reviewed is usually small. These queries specifically exclude localization PRs,
### When to close Pull Requests
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
- Close any PR where the CLA hasn’t been signed for two weeks.
- Close any PR where the CLA hasn’t been signed for two weeks.
PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
@@ -82,7 +82,7 @@ An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically
SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.
After you've been contributing to the Kubernetes documentation for a while, you
may have ideas for improvement to the [Style Guide](/docs/contribute/style/style-guide/)
may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/)
, the [Content Guide](/docs/contribute/style/content-guide/), the toolchain used to build
the documentation, the website style, the processes for reviewing and merging
pull requests, or other aspects of the documentation. For maximum transparency,
@@ -134,21 +134,21 @@ rotated among SIG Docs approvers.
## Serve as a New Contributor Ambassador
SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as
New Contributor Ambassadors.
New Contributor Ambassadors.
New Contributor Ambassadors work together to welcome new contributors to SIG-Docs,
New Contributor Ambassadors welcome new contributors to SIG-Docs,
suggest PRs to new contributors, and mentor new contributors through their first
few PR submissions.
few PR submissions.
Responsibilities for New Contributor Ambassadors include:
Responsibilities for New Contributor Ambassadors include:
- Being available on the [Kubernetes #sig-docs channel](https://kubernetes.slack.com) to answer questions from new contributors.
- Working with PR wranglers to identify good first issues for new contributors.
- Mentoring new contributors through their first few PRs to the docs repo.
- Monitoring the [#sig-docs Slack channel](https://kubernetes.slack.com) for questions from new contributors.
- Working with PR wranglers to identify good first issues for new contributors.
- Mentoring new contributors through their first few PRs to the docs repo.
- Helping new contributors create the more complex PRs they need to become Kubernetes members.
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
- [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
## Sponsor a new contributor
@@ -180,12 +180,12 @@ Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
### Responsibilities
The role of co-chair is primarily one of service: co-chairs handle process and policy, schedule and run meetings, schedule PR wranglers, and generally do the things that no one else wants to do in order to build contributor capacity.
The role of co-chair is one of service: co-chairs build contributor capacity, handle process and policy, schedule and run meetings, schedule PR wranglers, advocate for docs in the Kubernetes community, make sure that docs succeed in Kubernetes release cycles, and keep SIG Docs focused on effective priorities.
Responsibilities include:
@@ -228,7 +228,7 @@ For weekly meetings, copypaste the previous week's notes into the "Past meetings
**Honor folks' time**:
- Begin and end meetings punctually
Begin and end meetings on time.
**Use Zoom effectively**:
@@ -240,9 +240,9 @@ For weekly meetings, copypaste the previous week's notes into the "Past meetings
### Recording meetings on Zoom
When you’re ready to start the recording, click Record to Cloud.
When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
{{% /capture %}}
{{% /capture %}}
content/en/docs/contribute/intermediate.md
-967
View File
@@ -1,967 +0,0 @@
---
title: Intermediate contributing
slug: intermediate
content_template: templates/concept
weight: 20
card:
name: contribute
weight: 50
---
{{% capture overview %}}
This page assumes that you've read and mastered the tasks in the
[start contributing](/docs/contribute/start/) topic and are ready to
learn about more ways to contribute.
{{< note >}}
Some tasks require you to use the Git command line client and other tools.
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
Now that you've gotten your feet wet and helped out with the Kubernetes docs in
the ways outlined in the [start contributing](/docs/contribute/start/) topic,
you may feel ready to do more. These tasks assume that you have, or are willing
to gain, deeper knowledge of the following topic areas:
- Kubernetes concepts
- Kubernetes documentation workflows
- Where and how to find information about upcoming Kubernetes features
- Strong research skills in general
These tasks are not as sequential as the beginner tasks. There is no expectation
that one person does all of them all of the time.
## Learn about Prow
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
enables chatbot-style commands to handle GitHub actions across the Kubernetes
organization. You can perform a variety of actions such as [adding and removing
labels](#add-and-remove-labels), closing issues, and assigning an approver. Type
the Prow command into a comment field using the `/<command-name>` format. Some common
commands are:
- `/lgtm` (looks good to me): adds the `lgtm` label, signalling that a reviewer has finished reviewing the PR
- `/approve`: approves a PR so it can merge (approver use only)
- `/assign`: assigns a person to review or approve a PR
- `/close`: closes an issue or PR
- `/hold`: adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged
- `/hold cancel`: removes the `do-not-merge/hold` label
{{% note %}}
Not all commands are available to every user. The Prow bot will tell you if you
try to execute a command beyond your authorization level.
{{% /note %}}
Familiarize yourself with the [list of Prow
commands](https://prow.k8s.io/command-help) before you review PRs or triage issues.
## Review pull requests
In any given week, a specific docs approver volunteers to do initial triage
and review of [pull requests and issues](#triage-and-categorize-issues). This
person is the "PR Wrangler" for the week. The schedule is maintained using the
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers).
To be added to this list, attend the weekly SIG Docs meeting and volunteer. Even
if you are not on the schedule for the current week, you can still review pull
requests (PRs) that are not already under active review.
In addition to the rotation, an automated system comments on each new PR and
suggests reviewers and approvers for the PR, based on the list of approvers and
reviewers in the affected files. The PR author is expected to follow the
guidance of the bot, and this also helps PRs to get reviewed quickly.
We want to get pull requests (PRs) merged and published as quickly as possible.
To ensure the docs are accurate and up to date, each PR needs to be reviewed by
people who understand the content, as well as people with experience writing
great documentation.
Reviewers and approvers need to provide actionable and constructive feedback to
keep contributors engaged and help them to improve. Sometimes helping a new
contributor get their PR ready to merge takes more time than just rewriting it
yourself, but the project is better in the long term when we have a diversity of
active participants.
Before you start reviewing PRs, make sure you are familiar with the
[Documentation Content Guide](/docs/contribute/style/content-guide/), the
[Documentation Style Guide](/docs/contribute/style/style-guide/),
and the [code of conduct](/community/code-of-conduct/).
### Find a PR to review
To see all open PRs, go to the **Pull Requests** tab in the GitHub repository.
A PR is eligible for review when it meets all of the following criteria:
- Has the `cncf-cla:yes` tag
- Does not have WIP in the description
- Does not a have tag including the phrase `do-not-merge`
- Has no merge conflicts
- Is based against the correct branch (usually `master` unless the PR relates to
a feature that has not yet been released)
- Is not being actively reviewed by another docs person (other technical
reviewers are fine), unless that person has explicitly asked for your help. In
particular, leaving lots of new comments after other review cycles have
already been completed on a PR can be discouraging and counter-productive.
If a PR is not eligible to merge, leave a comment to let the author know about
the problem and offer to help them fix it. If they've been informed and have not
fixed the problem in several weeks or months, eventually their PR will be closed
without merging.
If you're new to reviewing, or you don't have a lot of bandwidth, look for PRs
with the `size/XS` or `size/S` tag set. The size is automatically determined by
the number of lines the PR changes.
#### Reviewers and approvers
The Kubernetes website repo operates differently than some of the Kubernetes
code repositories when it comes to the roles of reviewers and approvers. For
more information about the responsibilities of reviewers and approvers, see
[Participating](/docs/contribute/participating/). Here's an overview.
- A reviewer reviews pull request content for technical accuracy. A reviewer
indicates that a PR is technically accurate by leaving a `/lgtm` comment on
the PR.
{{< note >}}Don't add a `/lgtm` unless you are confident in the technical
accuracy of the documentation modified or introduced in the PR.{{< /note >}}
- An approver reviews pull request content for docs quality and adherence to
SIG Docs guidelines found in the Content and Style guides. Only people listed as
approvers in the
[`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can
approve a PR. To approve a PR, leave an `/approve` comment on the PR.
A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes
organization and an `/approve` comment from an approver in the
`sig-docs-maintainers` group, as long as it is not on hold and the PR author
has signed the CLA.
{{< note >}}
The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers.
{{< /note >}}
### Review a PR
1. Read the PR description and read any attached issues or links, if
applicable. "Drive-by reviewing" is sometimes more harmful than helpful, so
make sure you have the right knowledge to provide a meaningful review.
2. If someone else is the best person to review this particular PR, let them
know by adding a comment with `/assign @<github-username>`. If you have
asked a non-docs person for technical review but still want to review the PR
from a docs point of view, keep going.
3. Go to the **Files changed** tab. Look over all the changed lines. Removed
content has a red background, and those lines also start with a `-` symbol.
Added content has a green background, and those lines also start with a `+`
symbol. Within a line, the actual modified content has a slightly darker
green background than the rest of the line.
- Especially if the PR uses tricky formatting or changes CSS, Javascript,
or other site-wide elements, you can preview the website with the PR
applied. Go to the **Conversation** tab and click the **Details** link
for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default, so open it in a new window so you
don't lose your partial review. Switch back to the **Files changed** tab
to resume your review.
- Make sure the PR complies with the Content and Style guides; link the
author to the relevant part of the guide(s) if it doesn't.
- If you have a question, comment, or other feedback about a given
change, hover over a line and click the blue-and-white `+` symbol that
appears. Type your comment and click **Start a review**.
- If you have more comments, leave them in the same way.
- By convention, if you see a small problem that does not have to do with
the main purpose of the PR, such as a typo or whitespace error, you can
call it out, prefixing your comment with `nit:` so that the author knows
you consider it trivial. They should still address it.
- When you've reviewed everything, or if you didn't have any comments, go
back to the top of the page and click **Review changes**. Choose either
**Comment** or **Request Changes**. Add a summary of your review, and
add appropriate
[Prow commands](https://prow.k8s.io/command-help) to separate lines in
the Review Summary field. SIG Docs follows the
[Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
All of your comments will be sent to the PR author in a single
notification.
- If you think the PR is ready to be merged, add the text `/approve` to
your summary.
- If the PR does not need additional technical review, add the
text `/lgtm` as well.
- If the PR *does* need additional technical review, add the text
`/assign` with the GitHub username of the person who needs to
provide technical review. Look at the `reviewers` field in the
front-matter at the top of a given Markdown file to see who can
provide technical review.
- To prevent the PR from being merged, add `/hold`. This sets the
label `do-not-merge/hold`.
- If a PR has no conflicts and has the `lgtm` and `approve` labels but
no `hold` label, it is merged automatically.
- If a PR has the `lgtm` and/or `approve` labels and new changes are
detected, these labels are removed automatically.
See
[the list of all available slash commands](https://prow.k8s.io/command-help)
that can be used in PRs.
- If you previously selected **Request changes** and the PR author has
addressed your concerns, you can change your review status either in the
**Files changed** tab or at the bottom of the **Conversation** tab. Be
sure to add the `/approve` tag and assign technical reviewers if necessary,
so that the PR can be merged.
### Commit into another person's PR
Leaving PR comments is helpful, but there may be times when you need to commit
into another person's PR, rather than just leaving a review.
Resist the urge to "take over" for another person unless they explicitly ask
you to, or you want to resurrect a long-abandoned PR. While it may be faster
in the short term, it deprives the person of the chance to contribute.
The process you use depends on whether you need to edit a file that is already
in the scope of the PR or a file that the PR has not yet touched.
You can't commit into someone else's PR if either of the following things is
true:
- If the PR author pushed their branch directly to the
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
repository, only a reviewer with push access can commit into their PR.
Authors should be encouraged to push their branch to their fork before
opening the PR.
- If the PR author explicitly disallowed edits from approvers, you can't
commit into their PR unless they change this setting.
#### If the file is already changed by the PR
This method uses the GitHub UI. If you prefer, you can use the command line
even if the file you want to change is part of the PR, if you are more
comfortable working that way.
1. Click the **Files changed** tab.
2. Scroll down to the file you want to edit, and click the pencil icon for
that file.
3. Make your changes, add a commit message in the field below the editor, and
click **Commit changes**.
Your commit is now pushed to the branch the PR represents (probably on the
author's fork) and now shows up in the PR and your changes are reflected in
the **Files changed** tab. Leave a comment letting the PR author know you
changed the PR.
If the author is using the command line rather than the GitHub UI to work on
this PR, they need to fetch their fork's changes and rebase their local branch
on the branch in their fork, before doing additional work on the PR.
#### If the file has not yet been changed by the PR
If changes need to be made to a file that is not yet included in the PR, you
need to use the command line. You can always use this method, if you prefer it
to the GitHub UI.
1. Get the URL for the author's fork. You can find it near the bottom of the
**Conversation** tab. Look for the text **Add more commits by pushing to**.
The first link after this phrase is to the branch, and the second link is
to the fork. Copy the second link. Note the name of the branch for later.
2. Add the fork as a remote. In your terminal, go to your clone of the
repository. Decide on a name to give the remote (such as the author's
GitHub username), and add the remote using the following syntax:
```bash
git remote add <name> <url-of-fork>
```
3. Fetch the remote. This doesn't change any local files, but updates your
clone's notion of the remote's objects (such as branches and tags) and
their current state.
```bash
git remote fetch <name>
```
4. Check out the remote branch. This command will fail if you already have a
local branch with the same name.
```bash
git checkout <branch-from-PR>
```
5. Make your changes, use `git add` to add them, and commit them.
6. Push your changes to the author's remote.
```bash
git push <remote-name> <branch-name>
```
7. Go back to the GitHub IU and refresh the PR. Your changes appear. Leave the
PR author a comment letting them know you changed the PR.
If the author is using the command line rather than the GitHub UI to work on
this PR, they need to fetch their fork's changes and rebase their local branch
on the branch in their fork, before doing additional work on the PR.
## Work from a local clone
For changes that require multiple files or changes that involve creating new
files or moving files around, working from a local Git clone makes more sense
than relying on the GitHub UI. These instructions use the `git` command and
assume that you have it installed locally. You can adapt them to use a local
graphical Git client instead.
### Clone the repository
You only need to clone the repository once per physical system where you work
on the Kubernetes documentation.
1. Create a fork of the `kubernetes/website` repository on GitHub. In your
web browser, go to
[https://github.com/kubernetes/website](https://github.com/kubernetes/website)
and click the **Fork** button. After a few seconds, you are redirected to
the URL for your fork, which is `https://github.com/<github_username>/website`.
2. In a terminal window, use `git clone` to clone the your fork.
```bash
git clone git@github.com/<github_username>/website
```
The new directory `website` is created in your current directory, with
the contents of your GitHub repository. Your fork is your `origin`.
3. Change to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote.
```bash
cd website
git remote add upstream https://github.com/kubernetes/website.git
```
4. Confirm your `origin` and `upstream` repositories.
```bash
git remote -v
```
Output is similar to:
```bash
origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website (fetch)
upstream https://github.com/kubernetes/website (push)
```
### Work on the local repository
Before you start a new unit of work on your local repository, you need to figure
out which branch to base your work on. The answer depends on what you are doing,
but the following guidelines apply:
- For general improvements to existing content, start from `master`.
- For new content that is about features that already exist in a released
version of Kubernetes, start from `master`.
- For long-running efforts that multiple SIG Docs contributors will collaborate on,
such as content reorganization, use a specific feature branch created for that
effort.
- For new content that relates to upcoming but unreleased Kubernetes versions,
use the pre-release feature branch created for that Kubernetes version.
For more guidance, see
[Choose which branch to use](/docs/contribute/start/#choose-which-git-branch-to-use).
After you decide which branch to start your work (or _base it on_, in Git
terminology), use the following workflow to be sure your work is based on the
most up-to-date version of that branch.
1. There are three different copies of the repository when you work locally:
`local`, `upstream`, and `origin`. Fetch both the `origin` and `upstream` remotes. This
updates your cache of the remotes without actually changing any of the copies.
```bash
git fetch origin
git fetch upstream
```
This workflow deviates from the one defined in the Community's [GitHub
Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md).
In this workflow, you do not need to merge your local copy of `master` with `upstream/master` before
pushing the updates to your fork. That step is not required in
`kubernetes/website` because you are basing your branch on the upstream repository.
2. Create a local working branch based on the most appropriate upstream branch:
`upstream/dev-1.xx` for feature developers or `upstream/master` for all other
contributors. This example assumes you are basing your work on
`upstream/master`. Because you didn't update your local `master` to match
`upstream/master` in the previous step, you need to explicitly create your
branch off of `upstream/master`.
```bash
git checkout -b <my_new_branch> upstream/master
```
3. With your new branch checked out, make your changes using a text editor.
At any time, use the `git status` command to see what you've changed.
4. When you are ready to submit a pull request, commit your changes. First
use `git status` to see what changes need to be added to the changeset.
There are two important sections: `Changes staged for commit` and
`Changes not staged for commit`. Any files that show up in the latter
section under `modified` or `untracked` need to be added if you want them to
be part of this commit. For each file that needs to be added, use `git add`.
```bash
git add example-file.md
```
When all your intended changes are included, create a commit using the
`git commit` command:
```bash
git commit -m "Your commit message"
```
{{< note >}}
Do not reference a GitHub issue or pull request by ID or URL in the
commit message. If you do, it will cause that issue or pull request to get
a notification every time the commit shows up in a new Git branch. You can
link issues and pull requests together later in the GitHub UI.
{{< /note >}}
5. Optionally, you can test your change by staging the site locally using the
`hugo` command. See [View your changes locally](#view-your-changes-locally).
You'll be able to view your changes after you submit the pull request, as
well.
6. Before you can create a pull request which includes your local commit, you
need to push the branch to your fork, which is the endpoint for the `origin`
remote.
```bash
git push origin <my_new_branch>
```
Technically, you can omit the branch name from the `push` command, but
the behavior in that case depends upon the version of Git you are using.
The results are more repeatable if you include the branch name.
7. Go to https://github.com/kubernetes/website in your web browser. GitHub
detects that you pushed a new branch to your fork and offers to create a pull
request. Fill in the pull request template.
- The title should be no more than 50 characters and summarize the intent
of the change.
- The long-form description should contain more information about the fix,
including a line like `Fixes #12345` if the pull request fixes a GitHub
issue. This will cause the issue to be closed automatically when the
pull request is merged.
- You can add labels or other metadata and assign reviewers. See
[Triage and categorize issues](#triage-and-categorize-issues) for the
syntax.
Click **Create pull request**.
8. Several automated tests will run against the state of the website with your
changes applied. If any of the tests fail, click the **Details** link for
more information. If the Netlify test completes successfully, its
**Details** link goes to a staged version of the Kubernetes website with
your changes applied. This is how reviewers will check your changes.
9. When you need to make more changes, address the feedback locally and amend
your original commit.
```bash
git commit -a --amend
```
- `-a`: commit all changes
- `--amend`: amend the previous commit, rather than creating a new one
An editor will open so you can update your commit message if necessary.
If you use `git commit -m` as in Step 4, you will create a new commit rather
than amending changes to your original commit. Creating a new commit means
you must squash your commits before your pull request can be merged.
Follow the instructions in Step 6 to push your commit. The commit is added
to your pull request and the tests run again, including re-staging the
Netlify staged site.
10. If a reviewer adds changes to your pull request, you need to fetch those
changes from your fork before you can add more changes. Use the following
commands to do this, assuming that your branch is currently checked out.
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
After rebasing, you need to add the `--force-with-lease` flag to
force push the branch's new changes to your fork.
```bash
git push --force-with-lease origin <your-branch-name>
```
11. If someone else's change is merged into the branch your work is based on,
and you have made changes to the same parts of the same files, a conflict
might occur. If the pull request shows that there are conflicts to resolve,
you can resolve them using the GitHub UI or you can resolve them locally.
First, do step 10 to be sure that your fork and your local branch are in
the same state.
Next, fetch `upstream` and rebase your branch on the branch it was
originally based on, like `upstream/master`.
```bash
git fetch upstream
git rebase upstream/master
```
If there are conflicts Git can't automatically resolve, you can see the
conflicted files using the `git status` command. For each conflicted file,
edit it and look for the conflict markers `>>>`, `<<<`, and `===`. Resolve
the conflict and remove the conflict markers. Then add the changes to the
changeset using `git add <filename>` and continue the rebase using
`git rebase --continue`. When all commits have been applied and there are
no more conflicts, `git status` will show that you are not in a rebase and
there are no changes that need to be committed. At that point, force-push
the branch to your fork, and the pull request should no longer show any
conflicts.
12. If your PR still has multiple commits after amending previous commits, you
must squash multiple commits into a single commit before your PR can be merged.
You can check the number of commits on your PR's `Commits` tab or by running
`git log` locally. Squashing commits is a form of rebasing.
```bash
git rebase -i HEAD~<number_of_commits>
```
The `-i` switch tells git you want to rebase interactively. This enables
you to tell git which commits to squash into the first one. For
example, you have 3 commits on your branch:
```
12345 commit 4 (2 minutes ago)
6789d commit 3 (30 minutes ago)
456df commit 2 (1 day ago)
```
You must squash your last three commits into the first one.
```
git rebase -i HEAD~3
```
That command opens an editor with the following:
```
pick 456df commit 2
pick 6789d commit 3
pick 12345 commit 4
```
Change `pick` to `squash` on the commits you want to squash, and make sure
the one `pick` commit is at the top of the editor.
```
pick 456df commit 2
squash 6789d commit 3
squash 12345 commit 4
```
Save and close your editor. Then push your squashed
commit with `git push --force-with-lease origin <branch_name>`.
If you're having trouble resolving conflicts or you get stuck with
anything else related to your pull request, ask for help on the `#sig-docs`
Slack channel or the
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
### View your changes locally
{{< tabs name="tab_with_hugo" >}}
{{% tab name="Hugo in a container" %}}
If you aren't ready to create a pull request but you want to see what your
changes look like, you can build and run a docker image to generate all the documentation and
serve it locally.
1. Build the image locally:
```bash
make docker-image
```
2. Once the `kubernetes-hugo` image has been built locally, you can build and serve the site:
```bash
make docker-serve
```
3. In your browser's address bar, enter `localhost:1313`. Hugo will watch the
filesystem for changes and rebuild the site as needed.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`
or just close the terminal window.
{{% /tab %}}
{{% tab name="Hugo locally" %}}
Alternatively, you can install and use the `hugo` command on your development machine:
1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
2. In a terminal, go to the root directory of your clone of the Kubernetes
docs, and enter this command:
```bash
hugo server
```
3. In your browser’s address bar, enter `localhost:1313`.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`
or just close the terminal window.
{{% /tab %}}
{{< /tabs >}}
## Triage and categorize issues
People in SIG Docs are responsible only for triaging and categorizing
documentation issues. General website issues are also filed in the
`kubernetes/website` repository.
When you triage an issue, you:
- Validate the issue
- Make sure the issue is about website documentation. Some issues can be closed quickly by
answering a question or pointing the reporter to a resource. See the
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
- Assess whether the issue has merit. Add the `triage/needs-information` label if the issue doesn't have enough
detail to be actionable or the template is not filled out adequately.
Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
- Add a priority label (the
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)
define Priority labels in detail)
- `priority/critical-urgent` - do this right now
- `priority/important-soon` - do this within 3 months
- `priority/important-longterm` - do this within 6 months
- `priority/backlog` - this can be deferred indefinitely; lowest priority;
do this when resources are available
- `priority/awaiting-more-evidence` - placeholder for a potentially good issue
so it doesn't get lost
- Optionally, add a `help` or `good first issue` label if the issue is suitable
for someone with very little Kubernetes or SIG Docs experience. Consult
[Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)
for guidance.
- At your discretion, take ownership of an issue and submit a PR for it
(especially if it is quick or relates to work you were already doing).
This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
finds all the issues that need to be triaged.
If you have questions about triaging an issue, ask in `#sig-docs` on Slack or
the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
### Add and remove labels
To add a label, leave a comment like `/<label-to-add>` or `/<label-category> <label-to-add>`. The label must
already exist. If you try to add a label that does not exist, the command is
silently ignored.
Examples:
- `/triage needs-information`
- `/priority important-soon`
- `/language ja`
- `/help`
- `/good-first-issue`
- `/lifecycle frozen`
To remove a label, leave a comment like `/remove-<label-to-remove>` or `/remove-<label-category> <label-to-remove>`.
Examples:
- `/remove-triage needs-information`
- `/remove-priority important-soon`
- `/remove-language ja`
- `/remove-help`
- `/remove-good-first-issue`
- `/remove-lifecycle frozen`
The list of all the labels used across Kubernetes is
[here](https://github.com/kubernetes/kubernetes/labels). Not all labels
are used by SIG Docs.
### More about labels
- An issue can have multiple labels.
- Some labels use slash notation for grouping, which can be thought of like
"sub-labels". For instance, many `sig/` labels exist, such as `sig/cli` and
`sig/api-machinery` ([full list](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=sig%2F)).
- Some labels are automatically added based on metadata in the files involved
in the issue, slash commands used in the comments of the issue, or
information in the issue text.
- Additional labels are manually added by the person triaging the issue (or the person
reporting the issue)
- `kind/bug`, `kind/feature`, and `kind/documentation`: A bug is a problem with existing content or
functionality, and a feature is a request for new content or functionality.
The `kind/documentation` label is seldom used.
- `language/ja`, `language/ko` and similar [language
labels](https://github.com/kubernetes/website/labels?utf8=%E2%9C%93&q=language)
if the issue is about localized content.
### Issue lifecycle
Issues are generally opened and closed within a relatively short time span.
However, sometimes an issue may not have associated activity after it is
created. Other times, an issue may need to remain open for longer than 90 days.
`lifecycle/stale`: after 90 days with no activity, an issue is automatically
labeled as stale. The issue will be automatically closed if the lifecycle is not
manually reverted using the `/remove-lifecycle stale` command.
`lifecycle/frozen`: an issue with this label will not become stale after 90 days
of inactivity. A user manually adds this label to issues that need to remain
open for much longer than 90 days, such as those with a
`priority/important-longterm` label.
### Handling special issue types
We encounter the following types of issues often enough to document how
to handle them.
#### Duplicate issues
If a single problem has one or more issues open for it, the problem should be
consolidated into a single issue. You should decide which issue to keep open (or
open a new issue), port over all relevant information and link related issues.
Finally, label all other issues that describe the same problem with
`triage/duplicate` and close them. Only having a single issue to work on will
help reduce confusion and avoid duplicating work on the same problem.
#### Dead link issues
Depending on where the dead link is reported, different actions are required to
resolve the issue. Dead links in the API and Kubectl docs are automation issues
and should be assigned `/priority critical-urgent` until the problem can be fully understood. All other
dead links are issues that need to be manually fixed and can be assigned `/priority important-longterm`.
#### Blog issues
[Kubernetes Blog](https://kubernetes.io/blog/) entries are expected to become
outdated over time, so we maintain only blog entries that are less than one year old.
If an issue is related to a blog entry that is more than one year old, it should be closed
without fixing.
#### Support requests or code bug reports
Some issues opened for docs are instead issues with the underlying code, or
requests for assistance when something (like a tutorial) didn’t work. For issues
unrelated to docs, close the issue with the `triage/support` label and a comment
directing the requester to support venues (Slack, Stack Overflow) and, if
relevant, where to file an issue for bugs with features (kubernetes/kubernetes
is a great place to start).
Sample response to a request for support:
```none
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](http://slack.k8s.io/). You can also search
resources like
[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.
If this is a documentation issue, please re-open this issue.
```
Sample code bug report response:
```none
This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
```
## Document new features
Each major Kubernetes release includes new features, and many of them need
at least a small amount of documentation to show people how to use them.
Often, the SIG responsible for a feature submits draft documentation for the
feature as a pull request to the appropriate release branch of
`kubernetes/website` repository, and someone on the SIG Docs team provides
editorial feedback or edits the draft directly.
### Find out about upcoming features
To find out about upcoming features, attend the weekly sig-release meeting (see
the [community](https://kubernetes.io/community/) page for upcoming meetings)
and monitor the release-specific documentation
in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
repository. Each release has a sub-directory under the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
directory. Each sub-directory contains a release schedule, a draft of the release
notes, and a document listing each person on the release team.
- The release schedule contains links to all other documents, meetings,
meeting minutes, and milestones relating to the release. It also contains
information about the goals and timeline of the release, and any special
processes in place for this release. Near the bottom of the document, several
release-related terms are defined.
This document also contains a link to the **Feature tracking sheet**, which is
the official way to find out about all new features scheduled to go into the
release.
- The release team document lists who is responsible for each release role. If
it's not clear who to talk to about a specific feature or question you have,
either attend the release meeting to ask your question, or contact the release
lead so that they can redirect you.
- The release notes draft is a good place to find out a little more about
specific features, changes, deprecations, and more about the release. The
content is not finalized until late in the release cycle, so use caution.
#### The feature tracking sheet
The feature tracking sheet
[for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases) lists each feature that is planned for a release.
Each line item includes the name of the feature, a link to the feature's main
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
individual responsible for implementing it, whether it
needs docs, a draft release note for the feature, and whether it has been
merged. Keep the following in mind:
- Beta and Stable features are generally a higher documentation priority than
Alpha features.
- It's hard to test (and therefore, document) a feature that hasn't been merged,
or is at least considered feature-complete in its PR.
- Determining whether a feature needs documentation is a manual process and
just because a feature is not marked as needing docs doesn't mean it doesn't
need them.
### Document a feature
As stated above, draft content for new features is usually submitted by the SIG
responsible for implementing the new feature. This means that your role may be
more of a shepherding role for a given feature than developing the documentation
from scratch.
After you've chosen a feature to document/shepherd, ask about it in the `#sig-docs`
Slack channel, in a weekly sig-docs meeting, or directly on the PR filed by the
feature SIG. If you're given the go-ahead, you can edit into the PR using one of
the techniques described in
[Commit into another person's PR](#commit-into-another-persons-pr).
If you need to write a new topic, the following links are useful:
- [Writing a New Topic](/docs/contribute/style/write-new-topic/)
- [Using Page Templates](/docs/contribute/style/page-templates/)
- [Documentation Style Guide](/docs/contribute/style/style-guide/)
- [Documentation Content Guide](/docs/contribute/style/content-guide/)
### SIG members documenting new features
If you are a member of a SIG developing a new feature for Kubernetes, you need
to work with SIG Docs to be sure your feature is documented in time for the
release. Check the
[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
or check in the #sig-release Slack channel to verify scheduling details and
deadlines. Some deadlines related to documentation are:
- **Docs deadline - Open placeholder PRs**: Open a pull request against the
`release-X.Y` branch in the `kubernetes/website` repository, with a small
commit that you will amend later. Use the Prow command `/milestone X.Y` to
assign the PR to the relevant milestone. This alerts the docs person managing
this release that the feature docs are coming. If your feature does not need
any documentation changes, make sure the sig-release team knows this, by
mentioning it in the #sig-release Slack channel. If the feature does need
documentation but the PR is not created, the feature may be removed from the
milestone.
- **Docs deadline - PRs ready for review**: Your PR now needs to contain a first
draft of the documentation for your feature. Don't worry about formatting or
polishing. Just describe what the feature does and how to use it. The docs
person managing the release will work with you to get the content into shape
to be published. If your feature needs documentation and the first draft
content is not received, the feature may be removed from the milestone.
- **Docs complete - All PRs reviewed and ready to merge**: If your PR has not
yet been merged into the `release-X.Y` branch by this deadline, work with the
docs person managing the release to get it in. If your feature needs
documentation and the docs are not ready, the feature may be removed from the
milestone.
If your feature is an Alpha feature and is behind a feature gate, make sure you
add it to [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
as part of your pull request. If your feature is moving to Beta
or to General Availability, update the feature gates file.
## Contribute to other repos
The [Kubernetes project](https://github.com/kubernetes) contains more than 50
individual repositories. Many of these repositories contain code or content that
can be considered documentation, such as user-facing help text, error messages,
user-facing text in API references, or even code comments.
If you see text and you aren't sure where it comes from, you can use GitHub's
search tool at the level of the Kubernetes organization to search through all
repositories for that text. This can help you figure out where to submit your
issue or PR.
Each repository may have its own processes and procedures. Before you file an
issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and
`code-of-conduct.md`, if they exist.
Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
## Localize content
The Kubernetes documentation is written in English first, but we want people to
be able to read it in their language of choice. If you are comfortable
writing in another language, especially in the software domain, you can help
localize the Kubernetes documentation or provide feedback on existing localized
content. See [Localization](/docs/contribute/localization/) and ask on the
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
or in `#sig-docs` on Slack if you are interested in helping out.
### Working with localized content
Follow these guidelines for working with localized content:
- Limit PRs to a single language.
Each language has its own reviewers and approvers.
- Reviewers, verify that PRs contain changes to only one language.
If a PR contains changes to source in more than one language, ask the PR contributor to open separate PRs for each language.
{{% /capture %}}
{{% capture whatsnext %}}
When you are comfortable with all of the tasks discussed in this topic and you
want to engage with the Kubernetes docs team in even deeper ways, read the
[advanced docs contributor](/docs/contribute/advanced/) topic.
{{% /capture %}}
content/en/docs/contribute/localization.md
+16 -15
View File
@@ -1,13 +1,14 @@
---
title: Localizing Kubernetes Documentation
title: Localizing Kubernetes documentation
content_template: templates/concept
approvers:
- remyleone
- rlenferink
- zacharysarah
weight: 50
card:
name: contribute
weight: 30
weight: 50
title: Translating the docs
---
@@ -21,9 +22,9 @@ This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i
## Getting started
Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization.
Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization.
All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you.
All localization teams must be self-sustaining with their own resources. The Kubernetes website is happy to host your work, but it's up to you to translate it.
### Find your two-letter language code
@@ -31,7 +32,7 @@ First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/p
### Fork and clone the repo
First, [create your own fork](/docs/contribute/start/#improve-existing-content) of the [kubernetes/website](https://github.com/kubernetes/website) repository.
First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository.
Then, clone your fork and `cd` into it:
@@ -42,12 +43,12 @@ cd website
### Open a pull request
Next, [open a pull request](/docs/contribute/start/#submit-a-pull-request) (PR) to add a localization to the `kubernetes/website` repository.
Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository.
The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved.
For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548).
### Join the Kubernetes GitHub organization
Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository.
@@ -74,7 +75,7 @@ For an example of adding a label, see the PR for adding the [Italian language la
Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). Other localization teams are happy to help you get started and answer any questions you have.
You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605).
You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding channels for Indonesian and Portuguese](https://github.com/kubernetes/community/pull/3605).
## Minimum required content
@@ -105,11 +106,11 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber
mkdir content/de
```
### Localize the Community Code of Conduct
### Localize the community code of conduct
Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language.
### Add a localized README
### Add a localized README file
To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`.
@@ -192,10 +193,10 @@ mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
```
Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text.
Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text.
{{< caution >}}
Machine-generated translation alone does not meet the minimum standard of quality and requires extensive human review to meet that standard.
Machine-generated translation is insufficient on its own. Localization requires extensive human review to meet minimum standards of quality.
{{< /caution >}}
To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing.
@@ -211,7 +212,7 @@ To find source files for the most recent release:
The latest version is {{< latest-version >}}, so the most recent release branch is [`{{< release-branch >}}`](https://github.com/kubernetes/website/tree/{{< release-branch >}}).
### Site strings in i18n/
### Site strings in i18n
Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`.
@@ -264,7 +265,7 @@ Teams must merge localized content into the same release branch from which the c
An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch.
At the beginning of every team milestone, it's helpful to open an issue [comparing upstream changes](https://github.com/kubernetes/website/blob/master/scripts/upstream_changes.py) between the previous development branch and the current development branch.
While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
@@ -272,7 +273,7 @@ For more information about working from forks or directly from the repository, s
## Upstream contributions
SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source.
SIG Docs welcomes upstream contributions and corrections to the English source.
## Help an existing localization
content/en/docs/contribute/new-content/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Contributing new content
weight: 20
---
content/en/docs/contribute/new-content/blogs-case-studies.md
+60
View File
@@ -0,0 +1,60 @@
---
title: Submitting blog posts and case studies
linktitle: Blogs and case studies
slug: blogs-case-studies
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Anyone can write a blog post and submit it for review.
Case studies require extensive review before they're approved.
{{% /capture %}}
{{% capture body %}}
## Write a blog post
Blog posts should not be
vendor pitches. They must contain content that applies broadly to
the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
To submit a blog post, you can either:
- Use the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- The front matter must include the following:
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/)
to submit your proposal.
{{% /capture %}}
{{% capture whatsnext %}}
{{% /capture %}}
content/en/docs/contribute/new-content/new-features.md
+134
View File
@@ -0,0 +1,134 @@
---
title: Documenting a feature for a release
linktitle: Documenting for a release
content_template: templates/concept
main_menu: true
weight: 20
card:
name: contribute
weight: 45
title: Documenting a feature for a release
---
{{% capture overview %}}
Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
Generally, the SIG responsible for a feature submits draft documentation of the
feature as a pull request to the appropriate release branch of the
`kubernetes/website` repository, and someone on the SIG Docs team provides
editorial feedback or edits the draft directly. This section covers the branching
conventions and process used during a release by both groups.
{{% /capture %}}
{{% capture body %}}
## For documentation contributors
In general, documentation contributors don't write content from scratch for a release.
Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
After you've chosen a feature to document or assist, ask about it in the `#sig-docs`
Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
feature SIG. If you're given the go-ahead, you can edit into the PR using one of
the techniques described in
[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr).
### Find out about upcoming features
To find out about upcoming features, attend the weekly SIG Release meeting (see
the [community](https://kubernetes.io/community/) page for upcoming meetings)
and monitor the release-specific documentation
in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
directory. The sub-directory contains a release schedule, a draft of the release
notes, and a document listing each person on the release team.
The release schedule contains links to all other documents, meetings,
meeting minutes, and milestones relating to the release. It also contains
information about the goals and timeline of the release, and any special
processes in place for this release. Near the bottom of the document, several
release-related terms are defined.
This document also contains a link to the **Feature tracking sheet**, which is
the official way to find out about all new features scheduled to go into the
release.
The release team document lists who is responsible for each release role. If
it's not clear who to talk to about a specific feature or question you have,
either attend the release meeting to ask your question, or contact the release
lead so that they can redirect you.
The release notes draft is a good place to find out about
specific features, changes, deprecations, and more about the release. The
content is not finalized until late in the release cycle, so use caution.
### Feature tracking sheet
The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases)
lists each feature that is planned for a release.
Each line item includes the name of the feature, a link to the feature's main
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
individual responsible for implementing it, whether it
needs docs, a draft release note for the feature, and whether it has been
merged. Keep the following in mind:
- Beta and Stable features are generally a higher documentation priority than
Alpha features.
- It's hard to test (and therefore to document) a feature that hasn't been merged,
or is at least considered feature-complete in its PR.
- Determining whether a feature needs documentation is a manual process and
just because a feature is not marked as needing docs doesn't mean it doesn't
need them.
## For developers or other SIG members
This section is information for members of other Kubernetes SIGs documenting new features
for a release.
If you are a member of a SIG developing a new feature for Kubernetes, you need
to work with SIG Docs to be sure your feature is documented in time for the
release. Check the
[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and
deadlines.
### Open a placeholder PR
1. Open a pull request against the
`release-X.Y` branch in the `kubernetes/website` repository, with a small
commit that you will amend later.
2. Use the Prow command `/milestone X.Y` to
assign the PR to the relevant milestone. This alerts the docs person managing
this release that the feature docs are coming.
If your feature does not need
any documentation changes, make sure the sig-release team knows this, by
mentioning it in the `#sig-release` Slack channel. If the feature does need
documentation but the PR is not created, the feature may be removed from the
milestone.
### PR ready for review
When ready, populate your placeholder PR with feature documentation.
Do your best to describe your feature and how to use it. If you need help structuring your documentation, ask in the `#sig-docs` slack channel.
When you complete your content, the documentation person assigned to your feature reviews it. Use their suggestions to get the content to a release ready state.
If your feature needs documentation and the first draft
content is not received, the feature may be removed from the milestone.
### All PRs reviewed and ready to merge
If your PR has not yet been merged into the `release-X.Y` branch by the release deadline, work with the
docs person managing the release to get it in by the deadline. If your feature needs
documentation and the docs are not ready, the feature may be removed from the
milestone.
If your feature is an Alpha feature and is behind a feature gate, make sure you
add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table
as part of your pull request. If your feature is moving out of Alpha, make sure to
remove it from that table.
{{% /capture %}}
content/en/docs/contribute/new-content/open-a-pr.md
+484
View File
@@ -0,0 +1,484 @@
---
title: Opening a pull request
slug: new-content
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 40
---
{{% capture overview %}}
{{< note >}}
**Code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, see
[Document a new feature](/docs/contribute/new-content/new-features/).
{{< /note >}}
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](#before-you-begin) section.
If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page.
If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer.
{{% /capture %}}
{{% capture body %}}
## Changes using GitHub
If you're less experienced with git workflows, here's an easier method of
opening a pull request.
1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**.
2. Make your changes in the GitHub markdown editor.
3. Below the editor, fill in the **Propose file change**
form. In the first field, give your commit message a title. In
the second field, provide a description.
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
4. Select **Propose file change**.
5. Select **Create pull request**.
6. The **Open a pull request** screen appears. Fill in the form:
- The **Subject** field of the pull request defaults to the commit summary.
You can change it if needed.
- The **Body** contains your extended commit message, if you have one,
and some template text. Add the
details the template text asks for, then delete the extra template text.
- Leave the **Allow edits from maintainers** checkbox selected.
{{< note >}}
PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr).
{{</ note >}}
7. Select **Create pull request**.
### Addressing feedback in GitHub
Before merging a pull request, Kubernetes community members review and
approve it. The `k8s-ci-robot` suggests reviewers based on the nearest
owner mentioned in the pages. If you have someone specific in mind,
leave a comment with their GitHub username in it.
If a reviewer asks you to make changes:
1. Go to the **Files changed** tab.
2. Select the pencil (edit) icon on any files changed by the
pull request.
3. Make the changes requested.
4. Commit the changes.
If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel.
When your review is complete, a reviewer merges your PR and your changes go live a few minutes later.
## Work from a local fork {#fork-the-repo}
If you're more experienced with git, or if your changes are larger than a few lines,
work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
### Fork the kubernetes/website repository
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **Fork**.
### Create a local clone and set the upstream
3. In a terminal window, clone your fork:
```bash
git clone git@github.com/<github_username>/website
```
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
```bash
cd website
git remote add upstream https://github.com/kubernetes/website.git
```
5. Confirm your `origin` and `upstream` repositories:
```bash
git remote -v
```
Output is similar to:
```bash
origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website (fetch)
upstream https://github.com/kubernetes/website (push)
```
6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
```bash
git fetch origin
git fetch upstream
```
This makes sure your local repository is up to date before you start making changes.
{{< note >}}
This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork.
{{< /note >}}
### Create a branch
1. Decide which branch base to your work on:
- For improvements to existing content, use `upstream/master`.
- For new content about existing features, use `upstream/master`.
- For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that
effort.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`:
```bash
git checkout -b <my_new_branch> upstream/master
```
3. Make your changes using a text editor.
At any time, use the `git status` command to see what files you've changed.
### Commit your changes
When you are ready to submit a pull request, commit your changes.
1. In your local repository, check which files you need to commit:
```bash
git status
```
Output is similar to:
```bash
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
```
2. Add the files listed under **Changes not staged for commit** to the commit:
```bash
git add <your_file_name>
```
Repeat this for each file.
3. After adding all the files, create a commit:
```bash
git commit -m "Your commit message"
```
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
4. Push your local branch and its new commit to your remote fork:
```bash
git push origin <my_new_branch>
```
### Preview your changes locally {#preview-locally}
It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems.
You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
{{< tabs name="tab_with_hugo" >}}
{{% tab name="Hugo in a container" %}}
1. Build the image locally:
```bash
make docker-image
```
2. After building the `kubernetes-hugo` image locally, build and serve the site:
```bash
make docker-serve
```
3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
{{% /tab %}}
{{% tab name="Hugo on the command line" %}}
Alternately, install and use the `hugo` command on your computer:
5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
6. In a terminal, go to your Kubernetes website repository and start the Hugo server:
```bash
cd <path_to_your_repo>/website
hugo server
```
7. In your browser’s address bar, enter `https://localhost:1313`.
8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
{{% /tab %}}
{{< /tabs >}}
### Open a pull request from your fork to kubernetes/website {#open-a-pr}
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**.
3. Select **compare across forks**.
4. From the **head repository** drop-down menu, select your fork.
5. From the **compare** drop-down menu, select your branch.
6. Select **Create Pull Request**.
7. Add a description for your pull request:
- **Title** (50 characters or less): Summarize the intent of the change.
- **Description**: Describe the change in more detail.
- If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well.
- If you want advice on something specific, include any questions you'd like reviewers to think about in your description.
8. Select the **Create pull request** button.
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
- If the Netlify build fails, select **Details** for more information.
- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes.
GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
### Addressing feedback locally
1. After making your changes, amend your previous commit:
```bash
git commit -a --amend
```
- `-a`: commits all changes
- `--amend`: amends the previous commit, rather than creating a new one
2. Update your commit message if needed.
3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
{{< note >}}
If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging.
{{< /note >}}
#### Changes from reviewers
Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits.
1. Fetch commits from your remote fork and rebase your working branch:
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
2. After rebasing, force-push new changes to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
#### Merge conflicts and rebasing
{{< note >}}
For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR.
1. Update your fork and rebase your local branch:
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
Then force-push the changes to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
```bash
git fetch upstream
git rebase upstream/master
```
3. Inspect the results of the rebase:
```bash
git status
```
This results in a number of files marked as conflicted.
4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker.
{{< note >}}
For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
{{< /note >}}
5. Add the files to the changeset:
```bash
git add <filename>
```
6. Continue the rebase:
```bash
git rebase --continue
```
7. Repeat steps 2 to 5 as needed.
After applying all commits, the `git status` command shows that the rebase is complete.
8. Force-push the branch to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
The pull request no longer shows any conflicts.
### Squashing commits
{{< note >}}
For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally.
{{< note >}}
This topic assumes `vim` as the command line text editor.
{{< /note >}}
1. Start an interactive rebase:
```bash
git rebase -i HEAD~<number_of_commits_in_branch>
```
Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase.
Output is similar to:
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
# Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
...
# These lines can be re-ordered; they are executed from top to bottom.
```
The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete.
For the purposes of rebasing, focus on `squash` and `pick`.
{{< note >}}
For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
{{< /note >}}
2. Start editing the file.
Change the original text:
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
```
To:
```bash
pick d875112ca Original commit
squash 4fa167b80 Address feedback 1
squash 7d54e15ee Address feedback 2
```
This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline.
3. Save and exit your file.
4. Push your squashed commit:
```bash
git push --force-with-lease origin <branch_name>
```
## Contribute to other repos
The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments.
If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization.
This can help you figure out where to submit your issue or PR.
Each repository has its own processes and procedures. Before you file an
issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and
`code-of-conduct.md`, if they exist.
Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
{{% /capture %}}
{{% capture whatsnext %}}
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
{{% /capture %}}
content/en/docs/contribute/new-content/overview.md
+73
View File
@@ -0,0 +1,73 @@
---
title: Contributing new content overview
linktitle: Overview
content_template: templates/concept
main_menu: true
weight: 5
---
{{% capture overview %}}
This section contains information you should know before contributing new content.
{{% /capture %}}
{{% capture body %}}
## Contributing basics
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page templates](/docs/contribute/style/page-templates/) control the presentation of documentation content in Hugo.
- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
### Sign the CNCF CLA {#sign-the-cla}
All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Pull requests from contributors who haven't signed the CLA fail the automated tests.
### Configure commit signoffs
All commits to Kubernetes repositories must be _signed off_ using the Git `--signoff` or `-s` flag.
The signoff acknowledges that you have the rights to submit contributions under the same
license and [Developer Certificate of Origin](https://developercertificate.org/).
If you're using a Git UI app, you can use the app's commit template functionality if it
exists, or add the following to your commit message body:
```
Signed-off-by: Your Name <youremail@domain.com>
```
In both cases, the name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
### Choose which Git branch to use
When opening a pull request, you need to know in advance which branch to base your work on.
Scenario | Branch
:---------|:------------
Existing or new English language content for the current release | `master`
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
{{< note >}}
If you already submitted your pull request and you know that the base branch
was wrong, you (and only you, the submitter) can change it.
{{< /note >}}
### Languages per PR
Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
{{% /capture %}}
content/en/docs/contribute/participating.md
+7 -5
View File
@@ -1,9 +1,10 @@
---
title: Participating in SIG Docs
content_template: templates/concept
weight: 60
card:
name: contribute
weight: 40
weight: 60
---
{{% capture overview %}}
@@ -35,7 +36,7 @@ aspects of Kubernetes -- the Kubernetes website and documentation.
## Roles and responsibilities
- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/start#sign-the-cla) and have a GitHub account.
- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) and have a GitHub account.
- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria.
- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has
expressed interest in reviewing documentation pull requests, and has been
@@ -61,7 +62,7 @@ Anyone can do the following:
If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems.
{{< /note >}}
After [signing the CLA](/docs/contribute/start#sign-the-cla), anyone can also:
After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also:
- Open a pull request to improve existing content, add new content, or write a blog post or case study.
## Members
@@ -307,7 +308,8 @@ SIG Docs approvers. Here's how it works.
For more information about contributing to the Kubernetes documentation, see:
- [Start contributing](/docs/contribute/start/)
- [Documentation style](/docs/contribute/style/)
- [Contributing new content](/docs/contribute/overview/)
- [Reviewing content](/docs/contribute/review/reviewing-prs)
- [Documentation style guide](/docs/contribute/style/)
{{% /capture %}}
content/en/docs/contribute/review/_index.md
+14
View File
@@ -0,0 +1,14 @@
---
title: Reviewing changes
weight: 30
---
{{% capture overview %}}
This section describes how to review content.
{{% /capture %}}
{{% capture body %}}
{{% /capture %}}
content/en/docs/contribute/review/for-approvers.md
+228
View File
@@ -0,0 +1,228 @@
---
title: Reviewing for approvers and reviewers
linktitle: For approvers and reviewers
slug: for-approvers
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
person is the "PR Wrangler" for the week. See the
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull
requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
{{% /capture %}}
{{% capture body %}}
## Reviewing a PR
Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following:
- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important
when it comes to requesting technical review from code contributors.
{{< note >}}
Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can
provide technical review.
{{< /note >}}
- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't.
- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author.
- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented.
## Commit into another person's PR
Leaving PR comments is helpful, but there might be times when you need to commit
into another person's PR instead.
Do not "take over" for another person unless they explicitly ask
you to, or you want to resurrect a long-abandoned PR. While it may be faster
in the short term, it deprives the person of the chance to contribute.
The process you use depends on whether you need to edit a file that is already
in the scope of the PR, or a file that the PR has not yet touched.
You can't commit into someone else's PR if either of the following things is
true:
- If the PR author pushed their branch directly to the
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
repository. Only a reviewer with push access can commit to another user's PR.
{{< note >}}
Encourage the author to push their branch to their fork before
opening the PR next time.
{{< /note >}}
- The PR author explicitly disallows edits from approvers.
## Prow commands for reviewing
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
enables chatbot-style commands to handle GitHub actions across the Kubernetes
organization, like [adding and removing
labels](#add-and-remove-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
The most common prow commands reviewers and approvers use are:
{{< table caption="Prow commands for reviewing" >}}
Prow Command | Role Restrictions | Description
:------------|:------------------|:-----------
`/lgtm` | Anyone, but triggers automation if a Reviewer or Approver uses it | Signals that you've finished reviewing a PR and are satisfied with the changes.
`/approve` | Approvers | Approves a PR for merging.
`/assign` | Reviewers or Approvers | Assigns a person to review or approve a PR
`/close` | Reviewers or Approvers | Closes an issue or PR.
`/hold` | Anyone | Adds the `do-not-merge/hold` label, indicating the PR cannot be automatically merged.
`/hold cancel` | Anyone | Removes the `do-not-merge/hold` label.
{{< /table >}}
See [the Prow command reference](https://prow.k8s.io/command-help) to see the full list
of commands you can use in a PR.
## Triage and categorize issues
In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels.
This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
finds issues that might need triage.
### Triaging an issue
1. Validate the issue
- Make sure the issue is about website documentation. Some issues can be closed quickly by
answering a question or pointing the reporter to a resource. See the
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
- Assess whether the issue has merit.
- Add the `triage/needs-information` label if the issue doesn't have enough
detail to be actionable or the template is not filled out adequately.
- Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
2. Add a priority label (the
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail)
{{< table caption="Issue labels" >}}
Label | Description
:------------|:------------------
`priority/critical-urgent` | Do this right now.
`priority/important-soon` | Do this within 3 months.
`priority/important-longterm` | Do this within 6 months.
`priority/backlog` | Deferrable indefinitely. Do when resources are available.
`priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
`help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
{{< /table >}}
At your discretion, take ownership of an issue and submit a PR for it
(especially if it's quick or relates to work you're already doing).
If you have questions about triaging an issue, ask in `#sig-docs` on Slack or
the [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
## Adding and removing issue labels
To add a label, leave a comment in one of the following formats:
- `/<label-to-add>` (for example, `/good-first-issue`)
- `/<label-category> <label-to-add>` (for example, `/triage needs-information` or `/language ja`)
To remove a label, leave a comment in one of the following formats:
- `/remove-<label-to-remove>` (for example, `/remove-help`)
- `/remove-<label-category> <label-to-remove>` (for example, `/remove-triage needs-information`)`
In both cases, the label must already exist. If you try to add a label that does not exist, the command is
silently ignored.
For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs.
### Issue lifecycle labels
Issues are generally opened and closed quickly.
However, sometimes an issue is inactive after its opened.
Other times, an issue may need to remain open for longer than 90 days.
{{< table caption="Issue lifecycle labels" >}}
Label | Description
:------------|:------------------
`lifecycle/stale` | After 90 days with no activity, an issue is automatically labeled as stale. The issue will be automatically closed if the lifecycle is not manually reverted using the `/remove-lifecycle stale` command.
`lifecycle/frozen` | An issue with this label will not become stale after 90 days of inactivity. A user manually adds this label to issues that need to remain open for much longer than 90 days, such as those with a `priority/important-longterm` label.
{{< /table >}}
## Handling special issue types
SIG Docs encounters the following types of issues often enough to document how
to handle them.
### Duplicate issues
If a single problem has one or more issues open for it, combine them into a single issue.
You should decide which issue to keep open (or
open a new issue), then move over all relevant information and link related issues.
Finally, label all other issues that describe the same problem with
`triage/duplicate` and close them. Only having a single issue to work on reduces confusion
and avoids duplicate work on the same problem.
### Dead link issues
If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed.
### Blog issues
We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become
outdated over time. Therefore, we only maintain blog entries less than a year old.
If an issue is related to a blog entry that is more than one year old,
close the issue without fixing.
### Support requests or code bug reports
Some docs issues are actually issues with the underlying code, or requests for
assistance when something, for example a tutorial, doesn't work.
For issues unrelated to docs, close the issue with the `triage/support` label and a comment
directing the requester to support venues (Slack, Stack Overflow) and, if
relevant, the repository to file an issue for bugs with features (`kubernetes/kubernetes`
is a great place to start).
Sample response to a request for support:
```none
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the `#kubernetes-users` channel in
[Kubernetes slack](http://slack.k8s.io/). You can also search
resources like
[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes.
If this is a documentation issue, please re-open this issue.
```
Sample code bug report response:
```none
This sounds more like an issue with the code than an issue with
the documentation. Please open an issue at
https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
```
{{% /capture %}}
content/en/docs/contribute/review/reviewing-prs.md
+98
View File
@@ -0,0 +1,98 @@
---
title: Reviewing pull requests
content_template: templates/concept
main_menu: true
weight: 10
---
{{% capture overview %}}
Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests.
Reviewing documentation pull requests is a
great way to introduce yourself to the Kubernetes community.
It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
- Read the [content guide](/docs/contribute/style/content-guide/) and
[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments.
- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community.
{{% /capture %}}
{{% capture body %}}
## Before you begin
Before you start a review:
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times.
- Be polite, considerate, and helpful.
- Comment on positive aspects of PRs as well as changes.
- Be empathetic and mindful of how your review may be received.
- Assume good intent and ask clarifying questions.
- Experienced contributors, consider pairing with new contributors whose work requires extensive changes.
## Review process
In general, review pull requests for content and style in English.
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
You see a list of every open pull request against the Kubernetes website and
docs.
2. Filter the open PRs using one or all of the following labels:
- `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information.
- `language/en` (Recommended): Filters for english language PRs only.
- `size/<size>`: filters for PRs of a certain size. If you're new, start with smaller PRs.
Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet.
3. Once you've selected a PR to review, understand the change by:
- Reading the PR description to understand the changes made, and read any linked issues
- Reading any comments by other reviewers
- Clicking the **Files changed** tab to see the files and lines changed
- Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link.
4. Go to the **Files changed** tab to start your review.
1. Click on the `+` symbol beside the line you want to comment on.
2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make).
3. When finished, click **Review changes** at the top of the page. Here, you can add
add a summary of your review (and leave some positive comments for the contributor!),
approve the PR, comment or request changes as needed. New contributors should always
choose **Comment**.
## Reviewing checklist
When reviewing, use the following as a starting point.
### Language and grammar
- Are there any obvious errors in language or grammar? Is there a better way to phrase something?
- Are there any complicated or archaic words which could be replaced with a simpler word?
- Are there any words, terms or phrases in use which could be replaced with a non-discriminatory alternative?
- Does the word choice and its capitalization follow the [style guide](/docs/contribute/style/style-guide/)?
- Are there long sentences which could be shorter or less complex?
- Are there any long paragraphs which might work better as a list or table?
### Content
- Does similar content exist elsewhere on the Kubernetes site?
- Does the content excessively link to off-site, individual vendor or non-open source documentation?
### Website
- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug?
- Does the PR introduce a new page? If so:
- Is the page using the right [page template](/docs/contribute/style/page-templates/) and associated Hugo shortcodes?
- Does the page appear correctly in the section's side navigation (or at all)?
- Should the page appear on the [Docs Home](/docs/home/) listing?
- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images.
### Other
For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical.
{{% /capture %}}
content/en/docs/contribute/start.md
-421
View File
@@ -1,421 +0,0 @@
---
title: Start contributing
slug: start
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 10
---
{{% capture overview %}}
If you want to get started contributing to the Kubernetes documentation, this
page and its linked topics can help you get started. You don't need to be a
developer or a technical writer to make a big impact on the Kubernetes
documentation and user experience! All you need for the topics on this page is
a [GitHub account](https://github.com/join) and a web browser.
If you're looking for information on how to start contributing to Kubernetes
code repositories, refer to
[the Kubernetes community guidelines](https://github.com/kubernetes/community/blob/master/governance.md).
{{% /capture %}}
{{% capture body %}}
## The basics about our docs
The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
You can file issues, edit content, and review changes from others, all from the
GitHub website. You can also use GitHub's embedded history and search tools.
Not all tasks can be done in the GitHub UI, but these are discussed in the
[intermediate](/docs/contribute/intermediate/) and
[advanced](/docs/contribute/advanced/) docs contribution guides.
### Participating in SIG Docs
The Kubernetes documentation is maintained by a
{{< glossary_tooltip text="Special Interest Group" term_id="sig" >}} (SIG)
called SIG Docs. We [communicate](#participate-in-sig-docs-discussions) using a Slack channel, a mailing list, and
weekly video meetings. New participants are welcome. For more information, see
[Participating in SIG Docs](/docs/contribute/participating/).
### Content guidelines
The SIG Docs community created guidelines about what kind of content is allowed
in the Kubernetes documentation. Look over the [Documentation Content
Guide](/docs/contribute/style/content-guide/) to determine if the content
contribution you want to make is allowed. You can ask questions about allowed
content in the [#sig-docs](#participate-in-sig-docs-discussions) Slack
channel.
### Style guidelines
We maintain a [style guide](/docs/contribute/style/style-guide/) with information
about choices the SIG Docs community has made about grammar, syntax, source
formatting, and typographic conventions. Look over the style guide before you
make your first contribution, and use it when you have questions.
Changes to the style guide are made by SIG Docs as a group. To propose a change
or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more
information.
### Page templates
We use page templates to control the presentation of our documentation pages.
Be sure to understand how these templates work by reviewing
[Using page templates](/docs/contribute/style/page-templates/).
### Hugo shortcodes
The Kubernetes documentation is transformed from Markdown to HTML using Hugo.
We make use of the standard Hugo shortcodes, as well as a few that are custom to
the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for
information about how to use them.
### Multiple languages
Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide.
If you're interested in starting a new localization, see ["Localization"](/docs/contribute/localization/).
## File actionable issues
Anyone with a GitHub account can file an issue (bug report) against the
Kubernetes documentation. If you see something wrong, even if you have no idea
how to fix it, [file an issue](#how-to-file-an-issue). The exception to this
rule is a tiny bug like a typo that you intend to fix yourself. In that case,
you can instead [fix it](#improve-existing-content) without filing a bug first.
### How to file an issue
- **On an existing page**
If you see a problem in an existing page in the [Kubernetes docs](/docs/),
go to the bottom of the page and click the **Create an Issue** button. If
you are not currently logged in to GitHub, log in. A GitHub issue form
appears with some pre-populated content.
Using Markdown, fill in as many details as you can. In places where you see
empty square brackets (`[ ]`), put an `x` between the set of brackets that
represents the appropriate choice. If you have a proposed solution to fix
the issue, add it.
- **Request a new page**
If you think content should exist, but you aren't sure where it should go or
you don't think it fits within the pages that currently exist, you can
still file an issue. You can either choose an existing page near where you think the
new content should go and file the issue from that page, or go straight to
[https://github.com/kubernetes/website/issues/new/](https://github.com/kubernetes/website/issues/new/)
and file the issue from there.
### How to file great issues
To ensure that we understand your issue and can act on it, keep these guidelines
in mind:
- Use the issue template, and fill out as many details as you can.
- Clearly explain the specific impact the issue has on users.
- Limit the scope of a given issue to a reasonable unit of work. For problems
with a large scope, break them down into smaller issues.
For instance, "Fix the security docs" is not an actionable issue, but "Add
details to the 'Restricting network access' topic" might be.
- If the issue relates to another issue or pull request, you can refer to it
either by its full URL or by the issue or pull request number prefixed
with a `#` character. For instance, `Introduced by #987654`.
- Be respectful and avoid venting. For instance, "The docs about X suck" is not
helpful or actionable feedback. The
[Code of Conduct](/community/code-of-conduct/) also applies to interactions on
Kubernetes GitHub repositories.
## Participate in SIG Docs discussions
The SIG Docs team communicates using the following mechanisms:
- [Join the Kubernetes Slack instance](http://slack.k8s.io/), then join the
`#sig-docs` channel, where we discuss docs issues in real-time. Be sure to
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
- Participate in the [weekly SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) video meeting, which is announced on the Slack channel and the mailing list. Currently, these meetings take place on Zoom, so you'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
{{< note >}}
You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
{{< /note >}}
## Improve existing content
To improve existing content, you file a _pull request (PR)_ after creating a
_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
For the purposes of this topic, you don't need to know everything about them,
because you can do everything using your web browser. When you continue to the
[intermediate docs contributor guide](/docs/contribute/intermediate/), you will
need more background in Git terminology.
{{< note >}}
**Kubernetes code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, your process is a bit different. See
[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for
process guidelines and information about deadlines.
{{< /note >}}
### Sign the CNCF CLA {#sign-the-cla}
Before you can contribute code or documentation to Kubernetes, you **must** read
the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and
[sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Don't worry -- this doesn't take long!
### Find something to work on
If you see something you want to fix right away, just follow the instructions
below. You don't need to [file an issue](#file-actionable-issues) (although you
certainly can).
If you want to start by finding an existing issue to work on, go to
[https://github.com/kubernetes/website/issues](https://github.com/kubernetes/website/issues)
and look for issues with the label `good first issue` (you can use
[this](https://github.com/kubernetes/website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) shortcut). Read through the comments and make sure there is not an open pull
request against the issue and that nobody has left a comment saying they are
working on the issue recently (3 days is a good rule). Leave a comment saying
that you would like to work on the issue.
### Choose which Git branch to use
The most important aspect of submitting pull requests is choosing which branch
to base your work on. Use these guidelines to make the decision:
- Use `master` for fixing problems in content that is already published, or
making improvements to content that already exists.
- Use `master` to document something that is already part of the current
Kubernetes release, but isn't yet documented. You should write this content
in English first, and then localization teams will pick that change up as a
localization task.
- If you're working on a localization, you should follow the convention for
that particular localization. To find this out, you can look at other
pull requests (tip: search for `is:pr is:merged label:language/xx`)
{{< comment >}}Localization note: when localizing that tip, replace `xx`
with the actual ISO3166 two-letter code for your target locale.{{< /comment >}}
- Some localization teams work with PRs that target `master`
- Some localization teams work with a series of long-lived branches, and
periodically merge these to `master`. This kind of branch has a name like
dev-\<version>-\<language code>.\<team milestone>; for example:
`dev-{{< latest-semver >}}-ja.1`
- If you're writing or updating documentation for a feature change release,
then you need to know the major and minor version of Kubernetes that
the change will first appear in.
- For example, if the feature gate JustAnExample is going to move from alpha
to beta in the next minor version, you need to know what the next minor
version number is.
- Find the release branch named for that version. For example, features that
changed in the {{< latest-version >}} release got documented in the branch
named `dev-{{< latest-semver >}}`.
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or
attend a weekly SIG Docs meeting to get clarity.
{{< note >}}
If you already submitted your pull request and you know that the Base Branch
was wrong, you (and only you, the submitter) can change it.
{{< /note >}}
### Submit a pull request
Follow these steps to submit a pull request to improve the Kubernetes
documentation.
1. On the page where you see the issue, click the pencil icon at the top right.
A new GitHub page appears, with some help text.
2. If you have never created a fork of the Kubernetes documentation
repository, you are prompted to do so. Create the fork under your GitHub
username, rather than another organization you may be a member of. The
fork usually has a URL such as `https://github.com/<username>/website`,
unless you already have a repository with a conflicting name.
The reason you are prompted to create a fork is that you do not have
access to push a branch directly to the definitive Kubernetes repository.
3. The GitHub Markdown editor appears with the source Markdown file loaded.
Make your changes. Below the editor, fill in the **Propose file change**
form. The first field is the summary of your commit message and should be
no more than 50 characters long. The second field is optional, but can
include more detail if appropriate.
{{< note >}}
Do not include references to other GitHub issues or pull
requests in your commit message. You can add those to the pull request
description later.
{{< /note >}}
Click **Propose file change**. The change is saved as a commit in a
new branch in your fork, which is automatically named something like
`patch-1`.
4. The next screen summarizes the changes you made, by comparing your new
branch (the **head fork** and **compare** selection boxes) to the current
state of the **base fork** and **base** branch (`master` on the
`kubernetes/website` repository by default). You can change any of the
selection boxes, but don't do that now. Have a look at the difference
viewer on the bottom of the screen, and if everything looks right, click
**Create pull request**.
{{< note >}}
If you don't want to create the pull request now, you can do it
later, by browsing to the main URL of the Kubernetes website repository or
your fork's repository. The GitHub website will prompt you to create the
pull request if it detects that you pushed a new branch to your fork.
{{< /note >}}
5. The **Open a pull request** screen appears. The subject of the pull request
is the same as the commit summary, but you can change it if needed. The
body is populated by your extended commit message (if present) and some
template text. Read the template text and fill out the details it asks for,
then delete the extra template text. If you add to the description `fixes #<000000>`
or `closes #<000000>`, where `#<000000>` is the number of an associated issue,
GitHub will automatically close the issue when the PR merges.
Leave the **Allow edits from maintainers** checkbox selected. Click
**Create pull request**.
Congratulations! Your pull request is available in
[Pull requests](https://github.com/kubernetes/website/pulls).
After a few minutes, you can preview the website with your PR's changes
applied. Go to the **Conversation** tab of your PR and click the **Details**
link for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default.
{{< note >}}
Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
{{< /note >}}
6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`.
If a reviewer asks you to make changes, you can go to the **Files changed**
tab and click the pencil icon on any files that have been changed by the
pull request. When you save the changed file, a new commit is created in
the branch being monitored by the pull request. If you are waiting on a
reviewer to review the changes, proactively reach out to the reviewer
once every 7 days. You can also drop into #sig-docs Slack channel,
which is a good place to ask for help regarding PR reviews.
7. If your change is accepted, a reviewer merges your pull request, and the
change is live on the Kubernetes website a few minutes later.
This is only one way to submit a pull request. If you are already a Git and
GitHub advanced user, you can use a local GUI or command-line Git client
instead of using the GitHub UI. Some basics about using the command-line Git
client are discussed in the [intermediate](/docs/contribute/intermediate/) docs
contribution guide.
## Review docs pull requests
People who are new to documentation can still review pull requests. You can
learn the code base and build trust with your fellow contributors. English docs
are the authoritative source for content. We communicate in English during
weekly meetings and in community announcements. Contributors' English skills
vary, so use simple and direct language in your reviews. Effective reviews focus
on both small details and a change's potential impact.
The reviews are not considered "binding", which means that your review alone
won't cause a pull request to be merged. However, it can still be helpful. Even
if you don't leave any review comments, you can get a sense of pull request
conventions and etiquette and get used to the workflow. Familiarize yourself with the
[content guide](/docs/contribute/style/content-guide/) and
[style guide](/docs/contribute/style/style-guide/) before reviewing so you
get an idea of what the content should contain and how it should look.
### Best practices
- Be polite, considerate, and helpful
- Comment on positive aspects of PRs as well
- Be empathetic and mindful of how your review may be received
- Assume good intent and ask clarifying questions
- Experienced contributors, consider pairing with new contributors whose work requires extensive changes
### How to find and review a pull request
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
You see a list of every open pull request against the Kubernetes website and
docs.
2. By default, the only filter that is applied is `open`, so you don't see
pull requests that have already been closed or merged. It's a good idea to
apply the `cncf-cla: yes` filter, and for your first review, it's a good
idea to add `size/S` or `size/XS`. The `size` label is applied automatically
based on how many lines of code the PR modifies. You can apply filters using
the selection boxes at the top of the page, or use
[this shortcut](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+yes%22+label%3Asize%2FS) for only small PRs. All filters are `AND`ed together, so
you can't search for both `size/XS` and `size/S` in the same query.
3. Go to the **Files changed** tab. Look through the changes introduced in the
PR, and if applicable, also look at any linked issues. If you see a problem
or room for improvement, hover over the line and click the `+` symbol that
appears.
You can type a comment, and either choose **Add single comment** or **Start
a review**. Typically, starting a review is better because it allows you to
leave multiple comments and notifies the PR owner only when you have
completed the review, rather than a separate notification for each comment.
4. When finished, click **Review changes** at the top of the page. You can
summarize your review, and you can choose to comment, approve, or request
changes. New contributors should always choose **Comment**.
Thanks for reviewing a pull request! When you are new to the project, it's a
good idea to ask for feedback on your pull request reviews. The `#sig-docs`
Slack channel is a great place to do this.
## Write a blog post
Anyone can write a blog post and submit it for review. Blog posts should not be
commercial in nature and should consist of content that will apply broadly to
the Kubernetes community.
To submit a blog post, you can either submit it using the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform),
or follow the steps below.
1. [Sign the CLA](#sign-the-cla) if you have not yet done so.
2. Have a look at the Markdown format for existing blog posts in the
[website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
3. Write out your blog post in a text editor of your choice.
4. On the same link from step 2, click the **Create new file** button. Paste
your content into the editor. Name the file to match the proposed title of
the blog post, but don't put the date in the file name. The blog reviewers
will work with you on the final file name and the date the blog will be
published.
5. When you save the file, GitHub will walk you through the pull request
process.
6. A blog post reviewer will review your submission and work with you on
feedback and final details. When the blog post is approved, the blog will be
scheduled for publication.
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. They are written in collaboration with the Kubernetes
marketing team, which is handled by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/)
to submit your proposal.
{{% /capture %}}
{{% capture whatsnext %}}
When you are comfortable with all of the tasks discussed in this topic and you
want to engage with the Kubernetes docs team in deeper ways, read the
[intermediate docs contribution guide](/docs/contribute/intermediate/).
{{% /capture %}}
content/en/docs/contribute/style/content-guide.md
-4
View File
@@ -3,10 +3,6 @@ title: Documentation Content Guide
linktitle: Content guide
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 20
title: Documentation Content Guide
---
{{% capture overview %}}
content/en/docs/contribute/style/hugo-shortcodes/index.md
+1 -1
View File
@@ -243,4 +243,4 @@ Renders to:
* Learn about [using page templates](/docs/home/contribute/page-templates/).
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/)
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
{{% /capture %}}
{{% /capture %}}
content/en/docs/contribute/style/style-guide.md
+6 -8
View File
@@ -3,10 +3,6 @@ title: Documentation Style Guide
linktitle: Style guide
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 20
title: Documentation Style Guide
---
{{% capture overview %}}
@@ -15,10 +11,12 @@ These are guidelines, not rules. Use your best judgment, and feel free to
propose changes to this document in a pull request.
For additional information on creating new content for the Kubernetes
documentation, read the [Documentation Content
Guide](/docs/contribute/style/content-guide/) and follow the instructions on
[using page templates](/docs/contribute/style/page-templates/) and [creating a
documentation pull request](/docs/contribute/start/#improve-existing-content).
documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/) and follow the instructions on
[using page templates](/docs/contribute/style/page-templates/) and [creating a documentation pull request](/docs/contribute/new-content/open-a-pr).
Changes to the style guide are made by SIG Docs as a group. To propose a change
or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
discussion.
{{% /capture %}}
content/en/docs/contribute/style/write-new-topic.md
+5 -6
View File
@@ -10,7 +10,7 @@ This page shows how to create a new topic for the Kubernetes docs.
{{% capture prerequisites %}}
Create a fork of the Kubernetes documentation repository as described in
[Start contributing](/docs/contribute/start/).
[Open a PR](/docs/new-content/open-a-pr/).
{{% /capture %}}
{{% capture steps %}}
@@ -24,8 +24,8 @@ Type | Description
:--- | :----------
Concept | A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see <a href="/docs/concepts/architecture/nodes/">Nodes</a>.
Task | A task page shows how to do a single thing. The idea is to give readers a sequence of steps that they can actually do as they read the page. A task page can be short or long, provided it stays focused on one area. In a task page, it is OK to blend brief explanations with the steps to be performed, but if you need to provide a lengthy explanation, you should do that in a concept topic. Related task and concept topics should link to each other. For an example of a short task page, see <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">Configure a Pod to Use a Volume for Storage</a>. For an example of a longer task page, see <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">Configure Liveness and Readiness Probes</a>
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
{{< /table >}}
Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features.
{{< /table >}}
Use a template for each new page. Each page type has a
[template](/docs/contribute/style/page-templates/)
@@ -162,7 +162,6 @@ image format is SVG.
{{% /capture %}}
{{% capture whatsnext %}}
* Learn about [using page templates](/docs/home/contribute/page-templates/).
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/).
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
* Learn about [using page templates](/docs/contribute/page-templates/).
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
{{% /capture %}}
content/en/docs/contribute/suggesting-improvements.md
+65
View File
@@ -0,0 +1,65 @@
---
title: Suggesting content improvements
slug: suggest-improvements
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 20
---
{{% capture overview %}}
If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser.
In most cases, new work on Kubernetes documentation begins with an issue in GitHub. Kubernetes contributors
then review, categorize and tag issues as needed. Next, you or another member
of the Kubernetes community open a pull request with changes to resolve the issue.
{{% /capture %}}
{{% capture body %}}
## Opening an issue
If you want to suggest improvements to existing content, or notice an error, then open an issue.
1. Go to the bottom of the page and click the **Create an Issue** button. This redirects you
to a GitHub issue page pre-populated with some headers.
2. Describe the issue or suggestion for improvement. Provide as many details as you can.
3. Click **Submit new issue**.
After submitting, check in on your issue occasionally or turn on GitHub notifications.
Reviewers and other community members might ask questions before
they can take action on your issue.
## Suggesting new content
If you have an idea for new content, but you aren't sure where it should go, you can
still file an issue. Either:
- Choose an existing page in the section you think the content belongs in and click **Create an issue**.
- Go to [GitHub](https://github.com/kubernetes/website/issues/new/) and file the issue directly.
## How to file great issues
Keep the following in mind when filing an issue:
- Provide a clear issue description. Describe what specifically is missing, out of date,
wrong, or needs improvement.
- Explain the specific impact the issue has on users.
- Limit the scope of a given issue to a reasonable unit of work. For problems
with a large scope, break them down into smaller issues. For example, "Fix the security docs"
is too broad, but "Add details to the 'Restricting network access' topic" is specific enough
to be actionable.
- Search the existing issues to see if there's anything related or similar to the
new issue.
- If the new issue relates to another issue or pull request, refer to it
either by its full URL or by the issue or pull request number prefixed
with a `#` character. For example, `Introduced by #987654`.
- Follow the [Code of Conduct](/community/code-of-conduct/). Respect your
fellow contributors. For example, "The docs are terrible" is not
helpful or polite feedback.
{{% /capture %}}
content/en/docs/reference/using-api/api-concepts.md
+11
View File
@@ -334,6 +334,17 @@ are not vulnerable to ordering changes in the list.
Once the last finalizer is removed, the resource is actually removed from etcd.
## Single resource API
API verbs GET, CREATE, UPDATE, PATCH, DELETE and PROXY support single resources only.
These verbs with single resource support have no support for submitting
multiple resources together in an ordered or unordered list or transaction.
Clients including kubectl will parse a list of resources and make
single-resource API requests.
API verbs LIST and WATCH support getting multiple resources, and
DELETECOLLECTION supports deleting multiple resources.
## Dry-run
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
content/en/docs/setup/_index.md
+3 -7
View File
@@ -40,19 +40,15 @@ If you're learning Kubernetes, use the Docker-based solutions: tools supported b
|Community |Ecosystem |
| ------------ | -------- |
| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| | [Minishift](https://docs.okd.io/latest/minishift/)|
| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
| | [MicroK8s](https://microk8s.io/)|
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
| | [k3s](https://k3s.io)|
## Production environment
When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider.
For a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers, see "[Partners](https://kubernetes.io/partners/#conformance)".
[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
{{% /capture %}}
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+41 -35
View File
@@ -43,21 +43,39 @@ To enable the rolling update feature of a DaemonSet, you must set its
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well.
### Creating a DaemonSet with `RollingUpdate` update strategy
### Step 1: Checking DaemonSet `RollingUpdate` update strategy
This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate'
First, check the update strategy of your DaemonSet, and make sure it's set to
{{< codenew file="controllers/fluentd-daemonset.yaml" >}}
After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
```shell
kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
```
Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
update the DaemonSet with `kubectl apply`.
```shell
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
```
### Checking DaemonSet `RollingUpdate` update strategy
Check the update strategy of your DaemonSet, and make sure it's set to
`RollingUpdate`:
```shell
kubectl get ds/<daemonset-name> -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
```
If you haven't created the DaemonSet in the system, check your DaemonSet
manifest with the following command instead:
```shell
kubectl apply -f ds.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
```
The output from both commands should be:
@@ -69,28 +87,13 @@ RollingUpdate
If the output isn't `RollingUpdate`, go back and modify the DaemonSet object or
manifest accordingly.
### Step 2: Creating a DaemonSet with `RollingUpdate` update strategy
If you have already created the DaemonSet, you may skip this step and jump to
step 3.
After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
```shell
kubectl create -f ds.yaml
```
Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
update the DaemonSet with `kubectl apply`.
```shell
kubectl apply -f ds.yaml
```
### Step 3: Updating a DaemonSet template
### Updating a DaemonSet template
Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling
update. This can be done with several different `kubectl` commands.
update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands.
{{< codenew file="controllers/fluentd-daemonset-update.yaml" >}}
#### Declarative commands
@@ -99,21 +102,17 @@ If you update DaemonSets using
use `kubectl apply`:
```shell
kubectl apply -f ds-v2.yaml
kubectl apply -f https://k8s.io/examples/application/fluentd-daemonset-update.yaml
```
#### Imperative commands
If you update DaemonSets using
[imperative commands](/docs/tasks/manage-kubernetes-objects/imperative-command/),
use `kubectl edit` or `kubectl patch`:
use `kubectl edit` :
```shell
kubectl edit ds/<daemonset-name>
```
```shell
kubectl patch ds/<daemonset-name> -p=<strategic-merge-patch>
kubectl edit ds/fluentd-elasticsearch -n kube-system
```
##### Updating only the container image
@@ -122,21 +121,21 @@ If you just need to update the container image in the DaemonSet template, i.e.
`.spec.template.spec.containers[*].image`, use `kubectl set image`:
```shell
kubectl set image ds/<daemonset-name> <container-name>=<container-new-image>
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
```
### Step 4: Watching the rolling update status
### Watching the rolling update status
Finally, watch the rollout status of the latest DaemonSet rolling update:
```shell
kubectl rollout status ds/<daemonset-name>
kubectl rollout status ds/fluentd-elasticsearch -n kube-system
```
When the rollout is complete, the output is similar to this:
```shell
daemonset "<daemonset-name>" successfully rolled out
daemonset "fluentd-elasticsearch" successfully rolled out
```
## Troubleshooting
@@ -156,7 +155,7 @@ When this happens, find the nodes that don't have the DaemonSet pods scheduled o
by comparing the output of `kubectl get nodes` and the output of:
```shell
kubectl get pods -l <daemonset-selector-key>=<daemonset-selector-value> -o wide
kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
```
Once you've found those nodes, delete some non-DaemonSet pods from the node to
@@ -183,6 +182,13 @@ If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between
master and nodes will make DaemonSet unable to detect the right rollout
progress.
## Clean up
Delete DaemonSet from a namespace :
```shell
kubectl delete ds fluentd-elasticsearch -n kube-system
```
{{% /capture %}}
content/en/docs/tasks/setup-konnectivity/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "Setup Konnectivity Service"
weight: 20
---
content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md
+52
View File
@@ -0,0 +1,52 @@
---
title: Set up Konnectivity service
content_template: templates/task
weight: 70
---
{{% capture overview %}}
The Konnectivity service provides TCP level proxy for the Master → Cluster
communication.
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}}
{{% /capture %}}
{{% capture steps %}}
## Configure the Konnectivity service
First, you need to configure the API Server to use the Konnectivity service
to direct its network traffic to cluster nodes:
1. Set the `--egress-selector-config-file` flag of the API Server, it is the
path to the API Server egress configuration file.
1. At the path, create a configuration file. For example,
{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
Next, you need to deploy the Konnectivity server and agents.
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
is a reference implementation.
Deploy the Konnectivity server on your master node. The provided yaml assumes
that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod"
term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity
server as a DaemonSet.
{{< codenew file="admin/konnectivity/konnectivity-server.yaml" >}}
Then deploy the Konnectivity agents in your cluster:
{{< codenew file="admin/konnectivity/konnectivity-agent.yaml" >}}
Last, if RBAC is enabled in your cluster, create the relevant RBAC rules:
{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}
{{% /capture %}}
content/en/docs/tasks/tools/install-kubectl.md
+1 -1
View File
@@ -59,7 +59,7 @@ You must use a kubectl version that is within one minor version difference of yo
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https
sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
content/en/docs/tutorials/stateful-application/cassandra.md
+93 -79
View File
@@ -1,5 +1,5 @@
---
title: "Example: Deploying Cassandra with Stateful Sets"
title: "Example: Deploying Cassandra with a StatefulSet"
reviewers:
- ahmetb
content_template: templates/tutorial
@@ -7,79 +7,66 @@ weight: 30
---
{{% capture overview %}}
This tutorial shows you how to develop a native cloud [Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. In this example, a custom Cassandra *SeedProvider* enables Cassandra to discover new Cassandra nodes as they join the cluster.
This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster.
*StatefulSets* make it easier to deploy stateful applications within a clustered environment. For more information on the features used in this tutorial, see the [*StatefulSet*](/docs/concepts/workloads/controllers/statefulset/) documentation.
*StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
**Cassandra on Docker**
The *Pods* in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)
and includes OpenJDK 8.
This image includes a standard Cassandra installation from the Apache Debian repo.
By using environment variables you can change values that are inserted into `cassandra.yaml`.
| ENV VAR | DEFAULT VALUE |
| ------------- |:-------------: |
| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` |
| `CASSANDRA_NUM_TOKENS` | `32` |
| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` |
{{< note >}}
Cassandra and Kubernetes both use the term _node_ to mean a member of a cluster. In this
tutorial, the Pods that belong to the StatefulSet are Cassandra nodes and are members
of the Cassandra cluster (called a _ring_). When those Pods run in your Kubernetes cluster,
the Kubernetes control plane schedules those Pods onto Kubernetes
{{< glossary_tooltip text="Nodes" term_id="node" >}}.
When a Cassandra node starts, it uses a _seed list_ to bootstrap discovery of other
nodes in the ring.
This tutorial deploys a custom Cassandra seed provider that lets the database discover
new Cassandra Pods as they appear inside your Kubernetes cluster.
{{< /note >}}
{{% /capture %}}
{{% capture objectives %}}
* Create and validate a Cassandra headless [*Service*](/docs/concepts/services-networking/service/).
* Use a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) to create a Cassandra ring.
* Validate the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
* Modify the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
* Delete the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) and its [Pods](/docs/concepts/workloads/pods/pod/).
* Create and validate a Cassandra headless {{< glossary_tooltip text="Service" term_id="service" >}}.
* Use a {{< glossary_tooltip term_id="StatefulSet" >}} to create a Cassandra ring.
* Validate the StatefulSet.
* Modify the StatefulSet.
* Delete the StatefulSet and its {{< glossary_tooltip text="Pods" term_id="pod" >}}.
{{% /capture %}}
{{% capture prerequisites %}}
To complete this tutorial, you should already have a basic familiarity with [Pods](/docs/concepts/workloads/pods/pod/), [Services](/docs/concepts/services-networking/service/), and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/). In addition, you should:
{{< include "task-tutorial-prereqs.md" >}}
* [Install and Configure](/docs/tasks/tools/install-kubectl/) the *kubectl* command-line tool
To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}.
* Download [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)
and [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)
* Have a supported Kubernetes cluster running
{{< note >}}
Please read the [setup](/docs/setup/) if you do not already have a cluster.
{{< /note >}}
### Additional Minikube Setup Instructions
### Additional Minikube setup instructions
{{< caution >}}
[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings:
[Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MiB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings:
```shell
minikube start --memory 5120 --cpus=4
```
{{< /caution >}}
{{% /capture %}}
{{% capture lessoncontent %}}
## Creating a Cassandra Headless Service
## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service}
A Kubernetes [Service](/docs/concepts/services-networking/service/) describes a set of [Pods](/docs/concepts/workloads/pods/pod/) that perform the same task.
In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task.
The following `Service` is used for DNS lookups between Cassandra Pods and clients within the Kubernetes cluster.
The following Service is used for DNS lookups between Cassandra Pods and clients within your cluster:
{{< codenew file="application/cassandra/cassandra-service.yaml" >}}
1. Launch a terminal window in the directory you downloaded the manifest files.
1. Create a Service to track all Cassandra StatefulSet nodes from the `cassandra-service.yaml` file:
Create a Service to track all Cassandra StatefulSet members from the `cassandra-service.yaml` file:
```shell
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
```
```shell
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
```
### Validating (optional)
### Validating (optional) {#validating}
Get the Cassandra Service.
@@ -94,9 +81,9 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cassandra ClusterIP None <none> 9042/TCP 45s
```
Service creation failed if anything else is returned. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for common issues.
If you don't see a Service named `cassandra`, that means creation failed. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for help troubleshooting common issues.
## Using a StatefulSet to Create a Cassandra Ring
## Using a StatefulSet to create a Cassandra ring
The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods.
@@ -106,14 +93,23 @@ This example uses the default provisioner for Minikube. Please update the follow
{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
1. Update the StatefulSet if necessary.
1. Create the Cassandra StatefulSet from the `cassandra-statefulset.yaml` file:
Create the Cassandra StatefulSet from the `cassandra-statefulset.yaml` file:
```shell
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
```
```shell
# Use this if you are able to apply cassandra-statefulset.yaml unmodified
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
```
## Validating The Cassandra StatefulSet
If you need to modify `cassandra-statefulset.yaml` to suit your cluster, download
https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml and then apply
that manifest, from the folder you saved the modified version into:
```shell
# Use this if you needed to modify cassandra-statefulset.yaml locally
kubectl apply -f cassandra-statefulset.yaml
```
## Validating the Cassandra StatefulSet
1. Get the Cassandra StatefulSet:
@@ -121,31 +117,32 @@ This example uses the default provisioner for Minikube. Please update the follow
kubectl get statefulset cassandra
```
The response should be:
The response should be similar to:
```
NAME DESIRED CURRENT AGE
cassandra 3 0 13s
```
The `StatefulSet` resource deploys Pods sequentially.
The `StatefulSet` resource deploys Pods sequentially.
1. Get the Pods to see the ordered creation status:
```shell
kubectl get pods -l="app=cassandra"
```
The response should be:
The response should be similar to:
```shell
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 1m
cassandra-1 0/1 ContainerCreating 0 8s
```
It can take several minutes for all three Pods to deploy. Once they are deployed, the same command returns:
It can take several minutes for all three Pods to deploy. Once they are deployed, the same command
returns output similar to:
```
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 10m
@@ -153,13 +150,14 @@ This example uses the default provisioner for Minikube. Please update the follow
cassandra-2 1/1 Running 0 8m
```
3. Run the Cassandra [nodetool](https://wiki.apache.org/cassandra/NodeTool) to display the status of the ring.
3. Run the Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool) inside the first Pod, to
display the status of the ring.
```shell
kubectl exec -it cassandra-0 -- nodetool status
```
The response should look something like this:
The response should look something like:
```
Datacenter: DC1-K8Demo
@@ -174,7 +172,7 @@ This example uses the default provisioner for Minikube. Please update the follow
## Modifying the Cassandra StatefulSet
Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
1. Run the following command:
@@ -182,14 +180,14 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
kubectl edit statefulset cassandra
```
This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the `StatefulSet` file:
This command opens an editor in your terminal. The line you need to change is the `replicas` field. The following sample is an excerpt of the StatefulSet file:
```yaml
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
apiVersion: apps/v1
kind: StatefulSet
metadata:
creationTimestamp: 2016-08-13T18:40:58Z
@@ -204,50 +202,66 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
replicas: 3
```
1. Change the number of replicas to 4, and then save the manifest.
1. Change the number of replicas to 4, and then save the manifest.
The `StatefulSet` now contains 4 Pods.
The StatefulSet now scales to run with 4 Pods.
1. Get the Cassandra StatefulSet to verify:
1. Get the Cassandra StatefulSet to verify your change:
```shell
kubectl get statefulset cassandra
```
The response should be
The response should be similar to:
```
NAME DESIRED CURRENT AGE
cassandra 4 4 36m
```
{{% /capture %}}
{{% capture cleanup %}}
Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
{{< warning >}}
Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
{{< /warning >}}
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra `StatefulSet`:
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra StatefulSet:
```shell
grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
&& kubectl delete statefulset -l app=cassandra \
&& echo "Sleeping $grace" \
&& echo "Sleeping ${grace} seconds" 1>&2 \
&& sleep $grace \
&& kubectl delete pvc -l app=cassandra
&& kubectl delete persistentvolumeclaim -l app=cassandra
```
1. Run the following command to delete the Cassandra Service.
1. Run the following command to delete the Service you set up for Cassandra:
```shell
kubectl delete service -l app=cassandra
```
{{% /capture %}}
## Cassandra container environment variables
The Pods in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)
and includes OpenJDK 8.
This image includes a standard Cassandra installation from the Apache Debian repo.
By using environment variables you can change values that are inserted into `cassandra.yaml`.
| Environment variable | Default value |
| ------------------------ |:---------------: |
| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` |
| `CASSANDRA_NUM_TOKENS` | `32` |
| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` |
{{% /capture %}}
{{% capture whatsnext %}}
* Learn how to [Scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
content/en/examples/admin/konnectivity/egress-selector-configuration.yaml
+21
View File
@@ -0,0 +1,21 @@
apiVersion: apiserver.k8s.io/v1beta1
kind: EgressSelectorConfiguration
egressSelections:
# Since we want to control the egress traffic to the cluster, we use the
# "cluster" as the name. Other supported values are "etcd", and "master".
- name: cluster
connection:
# This controls the protocol between the API Server and the Konnectivity
# server. Supported values are "GRPC" and "HTTPConnect". There is no
# end user visible difference between the two modes. You need to set the
# Konnectivity server to work in the same mode.
proxyProtocol: GRPC
transport:
# This controls what transport the API Server uses to communicate with the
# Konnectivity server. UDS is recommended if the Konnectivity server
# locates on the same machine as the API Server. You need to configure the
# Konnectivity server to listen on the same UDS socket.
# The other supported transport is "tcp". You will need to set up TLS
# config to secure the TCP transport.
uds:
udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket
content/en/examples/admin/konnectivity/konnectivity-agent.yaml
+53
View File
@@ -0,0 +1,53 @@
apiVersion: apps/v1
# Alternatively, you can deploy the agents as Deployments. It is not necessary
# to have an agent on each node.
kind: DaemonSet
metadata:
labels:
addonmanager.kubernetes.io/mode: Reconcile
k8s-app: konnectivity-agent
namespace: kube-system
name: konnectivity-agent
spec:
selector:
matchLabels:
k8s-app: konnectivity-agent
template:
metadata:
labels:
k8s-app: konnectivity-agent
spec:
priorityClassName: system-cluster-critical
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8
name: konnectivity-agent
command: ["/proxy-agent"]
args: [
"--logtostderr=true",
"--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
# Since the konnectivity server runs with hostNetwork=true,
# this is the IP address of the master machine.
"--proxy-server-host=35.225.206.7",
"--proxy-server-port=8132",
"--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
]
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: konnectivity-agent-token
livenessProbe:
httpGet:
port: 8093
path: /healthz
initialDelaySeconds: 15
timeoutSeconds: 15
serviceAccountName: konnectivity-agent
volumes:
- name: konnectivity-agent-token
projected:
sources:
- serviceAccountToken:
path: konnectivity-agent-token
audience: system:konnectivity-server
content/en/examples/admin/konnectivity/konnectivity-rbac.yaml
+24
View File
@@ -0,0 +1,24 @@
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:konnectivity-server
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: system:konnectivity-server
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: konnectivity-agent
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
content/en/examples/admin/konnectivity/konnectivity-server.yaml
+70
View File
@@ -0,0 +1,70 @@
apiVersion: v1
kind: Pod
metadata:
name: konnectivity-server
namespace: kube-system
spec:
priorityClassName: system-cluster-critical
hostNetwork: true
containers:
- name: konnectivity-server-container
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8
command: ["/proxy-server"]
args: [
"--log-file=/var/log/konnectivity-server.log",
"--logtostderr=false",
"--log-file-max-size=0",
# This needs to be consistent with the value set in egressSelectorConfiguration.
"--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket",
# The following two lines assume the Konnectivity server is
# deployed on the same machine as the apiserver, and the certs and
# key of the API Server are at the specified location.
"--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt",
"--cluster-key=/etc/srv/kubernetes/pki/apiserver.key",
# This needs to be consistent with the value set in egressSelectorConfiguration.
"--mode=grpc",
"--server-port=0",
"--agent-port=8132",
"--admin-port=8133",
"--agent-namespace=kube-system",
"--agent-service-account=konnectivity-agent",
"--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig",
"--authentication-audience=system:konnectivity-server"
]
livenessProbe:
httpGet:
scheme: HTTP
host: 127.0.0.1
port: 8133
path: /healthz
initialDelaySeconds: 30
timeoutSeconds: 60
ports:
- name: agentport
containerPort: 8132
hostPort: 8132
- name: adminport
containerPort: 8133
hostPort: 8133
volumeMounts:
- name: varlogkonnectivityserver
mountPath: /var/log/konnectivity-server.log
readOnly: false
- name: pki
mountPath: /etc/srv/kubernetes/pki
readOnly: true
- name: konnectivity-uds
mountPath: /etc/srv/kubernetes/konnectivity-server
readOnly: false
volumes:
- name: varlogkonnectivityserver
hostPath:
path: /var/log/konnectivity-server.log
type: FileOrCreate
- name: pki
hostPath:
path: /etc/srv/kubernetes/pki
- name: konnectivity-uds
hostPath:
path: /etc/srv/kubernetes/konnectivity-server
type: DirectoryOrCreate
content/en/examples/controllers/fluentd-daemonset-update.yaml
+48
View File
@@ -0,0 +1,48 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/en/examples/controllers/fluentd-daemonset.yaml
+42
View File
@@ -0,0 +1,42 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can't run pods
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/fr/docs/concepts/services-networking/endpoint-slices.md
+122
View File
@@ -0,0 +1,122 @@
---
reviewers:
title: EndpointSlices
feature:
title: EndpointSlices
description: >
Suivi évolutif des réseaux Endpoints dans un cluster Kubernetes.
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
_EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un réseau au sein d'un cluster de Kubernetes. Ils offrent une alternative plus évolutive et extensible aux Endpoints.
{{% /capture %}}
{{% capture body %}}
## Resource pour EndpointSlice {#endpointslice-resource}
Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de Endpoints.
Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspond aux selecteur de Service.
EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports.
Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
```yaml
apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
name: exemple-abc
labels:
kubernetes.io/service-name: exemple
addressType: IPv4
ports:
- name: http
protocol: TCP
port: 80
endpoints:
- addresses:
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
topology:
kubernetes.io/hostname: node-1
topology.kubernetes.io/zone: us-west2-a
```
Les EndpointSlices géré par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun.
En dessous de cette échelle, EndpointSlices devrait mapper 1:1 les Endpoints et les Service et devrait avoir une performance similaire.
EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne.
Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'Endpoints.
### Types d'addresses
Les EndpointSlices supportent 3 types d'addresses:
* IPv4
* IPv6
* FQDN (Fully Qualified Domain Name) - [serveur entièrement nommé]
### Topologie
Chaque Endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
Ceci est utilisé pour indiqué où se trouve un Endpoint, qui contient les informations sur le Node, zone et region correspondante. Lorsque les valeurs sont disponibles, les labels de Topologies suivantes seront définies par le contrôleur EndpointSlice:
* `kubernetes.io/hostname` - Nom du Node sur lequel l'Endpoint se situe.
* `topology.kubernetes.io/zone` - Zone dans laquelle l'Endpoint se situe.
* `topology.kubernetes.io/region` - Region dans laquelle l'Endpoint se situe.
Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour.
Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspond au sélecteur.
### Capacité d'EndpointSlices
Les EndpointSlices sont limités a une capacité de 100 Endpoints chacun, par défaut. Vous pouvez configurer ceci avec l'indicateur `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} jusqu'à un maximum de 1000.
### Distribution d'EndpointSlices
Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la resource.
Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents port cible pour le même port nommé, nécessitant différents EndpointSlices.
Le contrôleur essaie de remplir l'EndpointSlice aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changés.
2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire.
3. S'il reste encore des Endpoints neufs à ajouter, essayez de les mettre dans une slice qui n'a pas été changé et/ou en crée de nouveaux.
Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, si il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants.
C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlice.
Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster.
Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut causer plusieurs EndpointSlices non remplis.
En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice sera suffisamment petite pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aura probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer.
## Motivation
L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes.
Malheureusement, comme les clusters Kubernetes et Services sont devenus plus larges, les limitations de cette API sont devenues plus visibles.
Plus particulièrement, ceux-ci comprenaient des limitations liés au dimensionnement vers un plus grand nombre d'Endpoint d'un réseau.
Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes.
Cela a affecté les performances des composants Kubernetes (notamment le plan de contrôle) et a causé une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent.
Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
{{% /capture %}}
{{% capture whatsnext %}}
* [Activer EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
* Lire [Connecter des applications aux Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
content/ko/docs/reference/glossary/replication-controller.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: 레플리케이션 컨트롤러(Replication Controller)
title: 레플리케이션 컨트롤러(ReplicationController)
id: replication-controller
date: 2018-04-12
full_link:
content/pt/docs/templates/feature-state-alpha.txt
Vendored
+7
View File
@@ -0,0 +1,7 @@
Atualmente, esse recurso está no estado *alpha*, o que significa:
* Os nomes das versões contêm alfa (ex. v1alpha1).
* Pode estar com bugs. A ativação do recurso pode expor bugs. Desabilitado por padrão.
* O suporte ao recurso pode ser retirado a qualquer momento sem aviso prévio.
* A API pode mudar de maneiras incompatíveis em uma versão de software posterior sem aviso prévio.
* Recomendado para uso apenas em clusters de teste de curta duração, devido ao aumento do risco de erros e falta de suporte a longo prazo.
content/pt/docs/templates/feature-state-beta.txt
Vendored
+8
View File
@@ -0,0 +1,8 @@
Atualmente, esse recurso está no estado *beta*, o que significa:
* Os nomes das versões contêm beta (ex, v2beta3).
* O código está bem testado. A ativação do recurso é considerada segura. Ativado por padrão.
* O suporte para o recurso geral não será descartado, embora os detalhes possam mudar.
* O esquema e/ou semântica dos objetos podem mudar de maneiras incompatíveis em uma versão beta ou estável subsequente. Quando isso acontecer, forneceremos instruções para migrar para a próxima versão. Isso pode exigir a exclusão, edição e recriação de objetos da API. O processo de edição pode exigir alguma reflexão. Isso pode exigir tempo de inatividade para aplicativos que dependem do recurso.
* Recomendado apenas para usos não comerciais, devido ao potencial de alterações incompatíveis nas versões subsequentes. Se você tiver vários clusters que podem ser atualizados independentemente, poderá relaxar essa restrição.
* **Por favor, experimente nossos recursos beta e dê um feedback sobre eles! Depois que eles saem da versão beta, pode não ser prático para nós fazer mais alterações.**
content/pt/docs/templates/feature-state-deprecated.txt
Vendored
+1
View File
@@ -0,0 +1 @@
Este recurso está *obsoleto*. Para obter mais informações sobre esse estado, consulte a [Política de descontinuação do Kubernetes](/docs/reference/deprecation-policy/).
content/pt/docs/templates/feature-state-stable.txt
Vendored
+4
View File
@@ -0,0 +1,4 @@
Esse recurso é *estável*, o que significa:
* O nome da versão é vX, em que X é um número inteiro.
* Versões estáveis dos recursos aparecerão no software lançado para muitas versões subsequentes.
content/pt/docs/templates/index.md
Vendored
+13
View File
@@ -0,0 +1,13 @@
---
headless: true
resources:
- src: "*alpha*"
title: "alpha"
- src: "*beta*"
title: "beta"
- src: "*deprecated*"
title: "deprecated"
- src: "*stable*"
title: "stable"
---
content/uk/OWNERS
+13
View File
@@ -0,0 +1,13 @@
# See the OWNERS docs at https://go.k8s.io/owners
# This is the directory for Ukrainian source content.
# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
reviewers:
- sig-docs-uk-reviews
approvers:
- sig-docs-uk-owners
labels:
- language/uk
content/uk/_common-resources/index.md
+3
View File
@@ -0,0 +1,3 @@
---
headless: true
---
content/uk/_index.html
+85
View File
@@ -0,0 +1,85 @@
---
title: "Довершена система оркестрації контейнерів"
abstract: "Автоматичне розгортання, масштабування і управління контейнерами"
cid: home
---
{{< announcement >}}
{{< deprecationwarning >}}
{{< blocks/section id="oceanNodes" >}}
{{% blocks/feature image="flower" %}}
<!--
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.
-->
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) - це система з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками.
<!--It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
-->
Вона об'єднує контейнери, що утворюють застосунок, у логічні елементи для легкого управління і виявлення. В основі Kubernetes - [15 років досвіду запуску і виконання застосунків у продуктивних середовищах Google](http://queue.acm.org/detail.cfm?id=2898444), поєднані з найкращими ідеями і практиками від спільноти.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}
<!--#### Planet Scale
-->
#### Глобальне масштабування
<!--Designed on the same principles that allows Google to run billions of containers a week, Kubernetes can scale without increasing your ops team.
-->
Заснований на тих самих принципах, завдяки яким Google запускає мільярди контейнерів щотижня, Kubernetes масштабується без потреби збільшення вашого штату з експлуатації.
{{% /blocks/feature %}}
{{% blocks/feature image="blocks" %}}
<!--#### Never Outgrow
-->
#### Невичерпна функціональність
<!--Whether testing locally or running a global enterprise, Kubernetes flexibility grows with you to deliver your applications consistently and easily no matter how complex your need is.
-->
Запущений для локального тестування чи у глобальній корпорації, Kubernetes динамічно зростатиме з вами, забезпечуючи регулярну і легку доставку ваших застосунків незалежно від рівня складності ваших потреб.
{{% /blocks/feature %}}
{{% blocks/feature image="suitcase" %}}
<!--#### Run Anywhere
-->
#### Працює всюди
<!--Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
-->
Kubernetes - проект з відкритим вихідним кодом. Він дозволяє скористатися перевагами локальної, гібридної чи хмарної інфраструктури, щоб легко переміщати застосунки туди, куди вам потрібно.
{{% /blocks/feature %}}
{{< /blocks/section >}}
{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
<div class="light-text">
<!--<h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2>
-->
<h2>Проблеми міграції 150+ мікросервісів у Kubernetes</h2>
<!--<p>By Sarah Wells, Technical Director for Operations and Reliability, Financial Times</p>
-->
<p>Сара Уеллз, технічний директор з експлуатації і безпеки роботи, Financial Times</p>
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Переглянути відео</button>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Відвідати KubeCon в Амстердамі, 30.03-02.04 2020</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Відвідати KubeCon у Шанхаї, 28-30 липня 2020</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
<button id="closeButton"></button>
</div>
{{< /blocks/section >}}
{{< blocks/kubernetes-features >}}
{{< blocks/case-studies >}}
content/uk/case-studies/_index.html
+13
View File
@@ -0,0 +1,13 @@
---
#title: Case Studies
title: Приклади використання
#linkTitle: Case Studies
linkTitle: Приклади використання
#bigheader: Kubernetes User Case Studies
bigheader: Приклади використання Kubernetes від користувачів.
#abstract: A collection of users running Kubernetes in production.
abstract: Підбірка користувачів, що використовують Kubernetes для робочих навантажень.
layout: basic
class: gridPage
cid: caseStudies
---
content/uk/docs/_index.md
+3
View File
@@ -0,0 +1,3 @@
---
title: Документація
---
content/uk/docs/concepts/_index.md
+123
View File
@@ -0,0 +1,123 @@
---
title: Концепції
main_menu: true
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
<!--The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
-->
В розділі "Концепції" описані складові системи Kubernetes і абстракції, за допомогою яких Kubernetes реалізовує ваш {{< glossary_tooltip text="кластер" term_id="cluster" length="all" >}}. Цей розділ допоможе вам краще зрозуміти, як працює Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!--## Overview
-->
## Загальна інформація
<!--To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
-->
Для роботи з Kubernetes ви використовуєте *об'єкти API Kubernetes* для того, щоб описати *бажаний стан* вашого кластера: які застосунки або інші робочі навантаження ви плануєте запускати, які образи контейнерів вони використовують, кількість реплік, скільки ресурсів мережі та диску ви хочете виділити тощо. Ви задаєте бажаний стан, створюючи об'єкти в Kubernetes API, зазвичай через інтерфейс командного рядка `kubectl`. Ви також можете взаємодіяти із кластером, задавати або змінювати його бажаний стан безпосередньо через Kubernetes API.
<!--Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
-->
Після того, як ви задали бажаний стан, *площина управління Kubernetes* приводить поточний стан кластера до бажаного за допомогою Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). Для цього Kubernetes автоматично виконує ряд задач: запускає або перезапускає контейнери, масштабує кількість реплік у певному застосунку тощо. Площина управління Kubernetes складається із набору процесів, що виконуються у вашому кластері:
<!--* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
* Each individual non-master node in your cluster runs two processes:
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
-->
* **Kubernetes master** становить собою набір із трьох процесів, запущених на одному вузлі вашого кластера, що визначений як керівний (master). До цих процесів належать: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) і [kube-scheduler](/docs/admin/kube-scheduler/).
* На кожному не-мастер вузлі вашого кластера виконуються два процеси:
* **[kubelet](/docs/admin/kubelet/)**, що обмінюється даними з Kubernetes master.
* **[kube-proxy](/docs/admin/kube-proxy/)**, мережевий проксі, що відображає мережеві сервіси Kubernetes на кожному вузлі.
<!--## Kubernetes Objects
-->
## Об'єкти Kubernetes
<!--Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
-->
Kubernetes оперує певною кількістю абстракцій, що відображають стан вашої системи: розгорнуті у контейнерах застосунки та робочі навантаження, пов'язані з ними ресурси мережі та диску, інша інформація щодо функціонування вашого кластера. Ці абстракції представлені як об'єкти Kubernetes API. Для більш детальної інформації ознайомтесь з [Об'єктами Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects/).
<!--The basic Kubernetes objects include:
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
* [Service](/docs/concepts/services-networking/service/)
* [Volume](/docs/concepts/storage/volumes/)
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
-->
До базових об'єктів Kubernetes належать:
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
* [Service](/docs/concepts/services-networking/service/)
* [Volume](/docs/concepts/storage/volumes/)
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
<!--Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
-->
В Kubernetes є також абстракції вищого рівня, які надбудовуються над базовими об'єктами за допомогою [контролерів](/docs/concepts/architecture/controller/) і забезпечують додаткову функціональність і зручність. До них належать:
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
<!--## Kubernetes Control Plane
-->
## Площина управління Kubernetes (*Kubernetes Control Plane*) {#площина-управління-kubernetes}
<!--The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
-->
Різні частини площини управління Kubernetes, такі як Kubernetes Master і kubelet, регулюють, як Kubernetes спілкується з вашим кластером. Площина управління веде облік усіх об'єктів Kubernetes в системі та безперервно, в циклі перевіряє стан цих об'єктів. У будь-який момент часу контрольні цикли, запущені площиною управління, реагуватимуть на зміни у кластері і намагатимуться привести поточний стан об'єктів до бажаного, що заданий у конфігурації.
<!--For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
-->
Наприклад, коли за допомогою API Kubernetes ви створюєте Deployment, ви задаєте новий бажаний стан для системи. Площина управління Kubernetes фіксує створення цього об'єкта і виконує ваші інструкції шляхом запуску потрібних застосунків та їх розподілу між вузлами кластера. В такий спосіб досягається відповідність поточного стану бажаному.
<!--### Kubernetes Master
-->
### Kubernetes Master
<!--The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
-->
Kubernetes Master відповідає за підтримку бажаного стану вашого кластера. Щоразу, як ви взаємодієте з Kubernetes, наприклад при використанні інтерфейсу командного рядка `kubectl`, ви обмінюєтесь даними із Kubernetes master вашого кластера.
<!--The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
-->
Слово "master" стосується набору процесів, які управляють станом кластера. Переважно всі ці процеси виконуються на одному вузлі кластера, який також називається master. Master-вузол можна реплікувати для забезпечення високої доступності кластера.
<!--### Kubernetes Nodes
-->
### Вузли Kubernetes
<!--The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
-->
Вузлами кластера називають машини (ВМ, фізичні сервери тощо), на яких запущені ваші застосунки та хмарні робочі навантаження. Кожен вузол керується Kubernetes master; ви лише зрідка взаємодіятимете безпосередньо із вузлами.
{{% /capture %}}
{{% capture whatsnext %}}
<!--If you would like to write a concept page, see
[Using Page Templates](/docs/home/contribute/page-templates/)
for information about the concept page type and the concept template.
-->
Якщо ви хочете створити нову сторінку у розділі Концепції, у статті
[Використання шаблонів сторінок](/docs/home/contribute/page-templates/)
ви знайдете інформацію щодо типу і шаблона сторінки.
{{% /capture %}}
content/uk/docs/concepts/configuration/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
title: "Конфігурація"
weight: 80
---
content/uk/docs/concepts/overview/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Огляд"
weight: 20
---
content/uk/docs/concepts/overview/what-is-kubernetes.md
+182
View File
@@ -0,0 +1,182 @@
---
title: Що таке Kubernetes?
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
<!--
This page is an overview of Kubernetes.
-->
Ця сторінка являє собою узагальнений огляд Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!--
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
-->
Kubernetes - це платформа з відкритим вихідним кодом для управління контейнеризованими робочими навантаженнями та супутніми службами. Її основні характеристики - кросплатформенність, розширюваність, успішне використання декларативної конфігурації та автоматизації. Вона має гігантську, швидкопрогресуючу екосистему.
<!--
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a [decade and a half of experience that Google has with running production workloads at scale](https://ai.google/research/pubs/pub43438), combined with best-of-breed ideas and practices from the community.
-->
Назва Kubernetes походить з грецької та означає керманич або пілот. Google відкрив доступ до вихідного коду проекту Kubernetes у 2014 році. Kubernetes побудовано [на базі п'ятнадцятирічного досвіду, що Google отримав, оперуючи масштабними робочими навантаженнями](https://ai.google/research/pubs/pub43438) у купі з найкращими у своєму класі ідеями та практиками, які може запропонувати спільнота.
<!--
## Going back in time
-->
## Озираючись на першопричини
<!--
Let's take a look at why Kubernetes is so useful by going back in time.
-->
Давайте повернемось назад у часі та дізнаємось, завдяки чому Kubernetes став таким корисним.
![Еволюція розгортання](/images/docs/Container_Evolution.svg)
<!--
*Traditional deployment era:** Early on, organizations ran applications on physical servers. There was no way to define resource boundaries for applications in a physical server, and this caused resource allocation issues. For example, if multiple applications run on a physical server, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers.
-->
**Ера традиційного розгортання:** На початку організації запускали застосунки на фізичних серверах. Оскільки в такий спосіб не було можливості задати обмеження використання ресурсів, це спричиняло проблеми виділення та розподілення ресурсів на фізичних серверах. Наприклад: якщо багато застосунків було запущено на фізичному сервері, могли траплятись випадки, коли один застосунок забирав собі найбільше ресурсів, внаслідок чого інші програми просто не справлялись з обов'язками. Рішенням може бути запуск кожного застосунку на окремому фізичному сервері. Але такий підхід погано масштабується, оскільки ресурси не повністю використовуються; на додачу, це дорого, оскільки організаціям потрібно опікуватись багатьма фізичними серверами.
<!--
**Virtualized deployment era:** As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization allows applications to be isolated between VMs and provides a level of security as the information of one application cannot be freely accessed by another application.
-->
**Ера віртуалізованого розгортання:** Як рішення - була представлена віртуалізація. Вона дозволяє запускати численні віртуальні машини (Virtual Machines або VMs) на одному фізичному ЦПУ сервера. Віртуалізація дозволила застосункам бути ізольованими у межах віртуальних машин та забезпечувала безпеку, оскільки інформація застосунку на одній VM не була доступна застосунку на іншій VM.
<!--
Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more. With virtualization you can present a set of physical resources as a cluster of disposable virtual machines.
-->
Віртуалізація забезпечує краще використання ресурсів на фізичному сервері та кращу масштабованість, оскільки дозволяє легко додавати та оновлювати застосунки, зменшує витрати на фізичне обладнання тощо. З віртуалізацією ви можете представити ресурси у вигляді одноразових віртуальних машин.
<!--
Each VM is a full machine running all the components, including its own operating system, on top of the virtualized hardware.
-->
Кожна VM є повноцінною машиною з усіма компонентами, включно з власною операційною системою, що запущені поверх віртуалізованого апаратного забезпечення.
<!--
**Container deployment era:** Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
-->
**Ера розгортання контейнерів:** Контейнери схожі на VM, але мають спрощений варіант ізоляції і використовують спільну операційну систему для усіх застосунків. Саму тому контейнери вважаються легковісними. Подібно до VM, контейнер має власну файлову систему, ЦПУ, пам'ять, простір процесів тощо. Оскільки контейнери вивільнені від підпорядкованої інфраструктури, їх можна легко переміщати між хмарними провайдерами чи дистрибутивами операційних систем.
<!--
Containers have become popular because they provide extra benefits, such as:
-->
Контейнери стали популярними, бо надавали додаткові переваги, такі як:
<!--
* Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
* Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and easy rollbacks (due to image immutability).
* Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure.
* Observability not only surfaces OS-level information and metrics, but also application health and other signals.
* Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud.
* Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, and anywhere else.
* Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources.
* Loosely coupled, distributed, elastic, liberated micro-services: applications are broken into smaller, independent pieces and can be deployed and managed dynamically – not a monolithic stack running on one big single-purpose machine.
* Resource isolation: predictable application performance.
* Resource utilization: high efficiency and density.
-->
* Створення та розгортання застосунків за методологією Agile: спрощене та більш ефективне створення образів контейнерів у порівнянні до використання образів віртуальних машин.
* Безперервна розробка, інтеграція та розгортання: забезпечення надійних та безперервних збирань образів контейнерів, їх швидке розгортання та легкі відкатування (за рахунок незмінності образів).
* Розподіл відповідальності команд розробки та експлуатації: створення образів контейнерів застосунків під час збирання/релізу на противагу часу розгортання, і як наслідок, вивільнення застосунків із інфраструктури.
* Спостереження не лише за інформацією та метриками на рівні операційної системи, але й за станом застосунку та іншими сигналами.
* Однорідність середовища для розробки, тестування та робочого навантаження: запускається так само як на робочому комп'ютері, так і у хмарного провайдера.
* ОС та хмарна кросплатформність: запускається на Ubuntu, RHEL, CoreOS, у власному дата-центрі, у Google Kubernetes Engine і взагалі будь-де.
* Керування орієнтоване на застосунки: підвищення рівня абстракції від запуску операційної системи у віртуальному апаратному забезпеченні до запуску застосунку в операційній системі, використовуючи логічні ресурси.
* Нещільно зв'язані, розподілені, еластичні, вивільнені мікросервіси: застосунки розбиваються на менші, незалежні частини для динамічного розгортання та управління, на відміну від монолітної архітектури, що працює на одній великій виділеній машині.
* Ізоляція ресурсів: передбачувана продуктивність застосунку.
* Використання ресурсів: висока ефективність та щільність.
<!--
## Why you need Kubernetes and what can it do
-->
## Чому вам потрібен Kebernetes і що він може робити
<!--
Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system?
-->
Контейнери - це прекрасний спосіб упакувати та запустити ваші застосунки. У прод оточенні вам потрібно керувати контейнерами, в яких працюють застосунки, і стежити, щоб не було простою. Наприклад, якщо один контейнер припиняє роботу, інший має бути запущений йому на заміну. Чи не легше було б, якби цим керувала сама система?
<!--
That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system.
-->
Ось де Kubernetes приходить на допомогу! Kubernetes надає вам каркас для еластичного запуску розподілених систем. Він опікується масштабуванням та аварійним відновленням вашого застосунку, пропонує шаблони розгортань тощо. Наприклад, Kubernetes дозволяє легко створювати розгортання за стратегією canary у вашій системі.
<!--
Kubernetes provides you with:
-->
Kubernetes надає вам:
<!--
* **Service discovery and load balancing**
Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
* **Storage orchestration**
Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
* **Automated rollouts and rollbacks**
You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
* **Automatic bin packing**
You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources.
* **Self-healing**
Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
* **Secret and configuration management**
Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration.
-->
* **Виявлення сервісів та балансування навантаження**
Kubernetes може надавати доступ до контейнера, використовуючи DNS-ім'я або його власну IP-адресу. Якщо контейнер зазнає завеликого мережевого навантаження, Kubernetes здатний збалансувати та розподілити його таким чином, щоб якість обслуговування залишалась стабільною.
* **Оркестрація сховища інформації**
Kubernetes дозволяє вам автоматично монтувати системи збереження інформації на ваш вибір: локальні сховища, рішення від хмарних провайдерів тощо.
* **Автоматичне розгортання та відкатування**
За допомогою Kubernetes ви можете описати бажаний стан контейнерів, що розгортаються, і він регульовано простежить за виконанням цього стану. Наприклад, ви можете автоматизувати в Kubernetes процеси створення нових контейнерів для розгортання, видалення існуючих контейнерів і передачу їхніх ресурсів на новостворені контейнери.
* **Автоматичне розміщення задач**
Ви надаєте Kubernetes кластер для запуску контейнерізованих задач і вказуєте, скільки ресурсів ЦПУ та пам'яті (RAM) необхідно для роботи кожного контейнера. Kubernetes розподіляє контейнери по вузлах кластера для максимально ефективного використання ресурсів.
* **Самозцілення**
Kubernetes перезапускає контейнери, що відмовили; заміняє контейнери; зупиняє роботу контейнерів, що не відповідають на задану користувачем перевірку стану, і не повідомляє про них клієнтам, допоки ці контейнери не будуть у стані робочої готовності.
* **Управління секретами та конфігурацією**
Kubernetes дозволяє вам зберігати та керувати чутливою інформацією, такою як паролі, OAuth токени та SSH ключі. Ви можете розгортати та оновлювати секрети та конфігурацію без перезбирання образів ваших контейнерів, не розкриваючи секрети в конфігурацію стека.
<!--
## What Kubernetes is not
-->
## Чим не є Kubernetes
<!--
Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
-->
Kubernetes не є комплексною системою PaaS (Платформа як послуга) у традиційному розумінні. Оскільки Kubernetes оперує швидше на рівні контейнерів, аніж на рівні апаратного забезпечення, деяка загальнозастосована функціональність і справді є спільною з PaaS, як-от розгортання, масштабування, розподіл навантаження, логування і моніторинг. Водночас Kubernetes не є монолітним, а вищезазначені особливості підключаються і є опціональними. Kubernetes надає будівельні блоки для створення платформ для розробників, але залишає за користувачем право вибору у важливих питаннях.
Kubernetes:
<!--
* Does not limit the types of applications supported. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes.
* Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements.
* Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, MySQL), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes through portable mechanisms, such as the [Open Service Broker](https://openservicebrokerapi.org/).
* Does not dictate logging, monitoring, or alerting solutions. It provides some integrations as proof of concept, and mechanisms to collect and export metrics.
* Does not provide nor mandate a configuration language/system (for example, Jsonnet). It provides a declarative API that may be targeted by arbitrary forms of declarative specifications.
* Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
-->
* Не обмежує типи застосунків, що підтримуються. Kubernetes намагається підтримувати найрізноманітніші типи навантажень, включно із застосунками зі станом (stateful) та без стану (stateless), навантаження по обробці даних тощо. Якщо ваш застосунок можна контейнеризувати, він чудово запуститься під Kubernetes.
* Не розгортає застосунки з вихідного коду та не збирає ваші застосунки. Процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються на рівні організації, та в залежності від технічних вимог.
* Не надає сервіси на рівні застосунків як вбудовані: програмне забезпечення проміжного рівня (наприклад, шина передачі повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеш, некластерні системи збереження інформації (наприклад, Ceph). Ці компоненти можуть бути запущені у Kubernetes та/або бути доступними для застосунків за допомогою спеціальних механізмів, наприклад [Open Service Broker](https://openservicebrokerapi.org/).
* Не нав'язує використання інструментів для логування, моніторингу та сповіщень, натомість надає певні інтеграційні рішення як прототипи, та механізми зі збирання та експорту метрик.
* Не надає та не змушує використовувати якусь конфігураційну мову/систему (як наприклад `Jsonnet`), натомість надає можливість використовувати API, що може бути використаний довільними формами декларативних специфікацій.
* Не надає і не запроваджує жодних систем машинної конфігурації, підтримки, управління або самозцілення.
* На додачу, Kubernetes - не просто система оркестрації. Власне кажучи, вона усуває потребу оркестрації як такої. Технічне визначення оркестрації - це запуск визначених процесів: спочатку A, за ним B, потім C. На противагу, Kubernetes складається з певної множини незалежних, складних процесів контролерів, що безперервно опрацьовують стан у напрямку, що заданий бажаною конфігурацією. Неважливо, як ви дістанетесь з пункту A до пункту C. Централізоване управління також не є вимогою. Все це виливається в систему, яку легко використовувати, яка є потужною, надійною, стійкою та здатною до легкого розширення.
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
* Ready to [Get Started](/docs/setup/)?
-->
* Перегляньте [компоненти Kubernetes](/docs/concepts/overview/components/)
* Готові [розпочати роботу](/docs/setup/)?
{{% /capture %}}
content/uk/docs/concepts/services-networking/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Сервіси, балансування навантаження та мережа"
weight: 60
---
content/uk/docs/concepts/storage/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Сховища інформації"
weight: 70
---
content/uk/docs/concepts/workloads/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Робочі навантаження"
weight: 50
---
content/uk/docs/concepts/workloads/controllers/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "Контролери"
weight: 20
---
content/uk/docs/contribute/localization_uk.md
+122
View File
@@ -0,0 +1,122 @@
---
title: Рекомендації з перекладу на українську мову
content_template: templates/concept
anchors:
- anchor: "#правила-перекладу"
title: Правила перекладу
- anchor: "#словник"
title: Словник
---
{{% capture overview %}}
Дорогі друзі! Раді вітати вас у спільноті українських контриб'юторів проекту Kubernetes. Ця сторінка створена з метою полегшити вашу роботу при перекладі документації. Вона містить правила, якими ми керувалися під час перекладу, і базовий словник, який ми почали укладати. Перелічені у ньому терміни ви знайдете в українській версії документації Kubernetes. Будемо дуже вдячні, якщо ви допоможете нам доповнити цей словник і розширити правила перекладу.
Сподіваємось, наші рекомендації стануть вам у пригоді.
{{% /capture %}}
{{% capture body %}}
## Правила перекладу {#правила-перекладу}
* У випадку, якщо у перекладі термін набуває неоднозначності і розуміння тексту ускладнюється, надайте у дужках англійський варіант, наприклад: кінцеві точки (endpoints). Якщо при перекладі термін втрачає своє значення, краще не перекладати його, наприклад: характеристики affinity.
* Назви об'єктів Kubernetes залишаємо без перекладу і пишемо з великої літери: Service, Pod, Deployment, Volume, Namespace, за винятком терміна node (вузол). Назви об'єктів Kubernetes вважаємо за іменники ч.р. і відмінюємо за допомогою апострофа: Pod'ів, Deployment'ами.
Для слів, що закінчуються на приголосний, у родовому відмінку однини використовуємо закінчення -а: Pod'а, Deployment'а.
Слова, що закінчуються на голосний, не відмінюємо: доступ до Service, за допомогою Namespace. У множині використовуємо англійську форму: користуватися Services, спільні Volumes.
* Частовживані і усталені за межами Kubernetes слова перекладаємо українською і пишемо з малої літери (label -> мітка). У випадку, якщо термін для означення об'єкта Kubernetes вживається у своєму загальному значенні поза контекстом Kubernetes (service як службова програма, deployment як розгортання), перекладаємо його і пишемо з малої літери, наприклад: service discovery -> виявлення сервісу, continuous deployment -> безперервне розгортання.
* Складені слова вважаємо за власні назви і не перекладаємо (LabelSelector, kube-apiserver).
* Для перевірки закінчень слів у родовому відмінку однини (-а/-я, -у/-ю) використовуйте [онлайн словник](https://slovnyk.ua/). Якщо слова немає у словнику, визначте його відміну і далі відмінюйте за правилами. Докладніше [дивіться тут](https://pidruchniki.com/1948041951499/dokumentoznavstvo/vidminyuvannya_imennikiv).
## Словник {#словник}
English | Українська |
--- | --- |
addon | розширення |
application | застосунок |
backend | бекенд |
build | збирання (результат) |
build | збирати (процес) |
cache | кеш |
CLI | інтерфейс командного рядка |
cloud | хмара; хмарний провайдер |
containerized | контейнеризований |
continuous deployment | безперервне розгортання |
continuous development | безперервна розробка |
continuous integration | безперервна інтеграція |
contribute | робити внесок (до проекту), допомагати (проекту) |
contributor | контриб'ютор, учасник проекту |
control plane | площина управління |
controller | контролер |
CPU | ЦП |
dashboard | дашборд |
data plane | площина даних |
default (by) | за умовчанням |
default settings | типові налаштування |
Deployment | Deployment |
deprecated | застарілий |
desired state | бажаний стан |
downtime | недоступність, простій |
ecosystem | сімейство проектів (екосистема) |
endpoint | кінцева точка |
expose (a service) | відкрити доступ (до сервісу) |
fail | відмовити |
feature | компонент |
framework | фреймворк |
frontend | фронтенд |
image | образ |
Ingress | Ingress |
instance | інстанс |
issue | запит |
kube-proxy | kube-proxy |
kubelet | kubelet |
Kubernetes features | функціональні можливості Kubernetes |
label | мітка |
lifecycle | життєвий цикл |
logging | логування |
maintenance | обслуговування |
map | спроектувати, зіставити, встановити відповідність |
master | master |
monitor | моніторити |
monitoring | моніторинг |
Namespace | Namespace |
network policy | мережева політика |
node | вузол |
orchestrate | оркеструвати |
output | вивід |
patch | патч |
Pod | Pod |
production | прод |
pull request | pull request |
release | реліз |
replica | репліка |
rollback | відкатування |
rolling update | послідовне оновлення |
rollout (new updates) | викатка (оновлень) |
run | запускати |
scale | масштабувати |
schedule | розподіляти (Pod'и по вузлах) |
Scheduler | Scheduler |
Secret | Secret |
Selector | Селектор |
self-healing | самозцілення |
self-restoring | самовідновлення |
Service | Service (як об'єкт Kubernetes) |
service | сервіс (як службова програма) |
service discovery | виявлення сервісу |
source code | вихідний код |
stateful app | застосунок зі станом |
stateless app | застосунок без стану |
task | завдання |
terminated | зупинений |
traffic | трафік |
VM (virtual machine) | ВМ (віртуальна машина) |
Volume | Volume |
workload | робоче навантаження |
YAML | YAML |
{{% /capture %}}
content/uk/docs/home/_index.md
+56
View File
@@ -0,0 +1,56 @@
---
title: Документація Kubernetes
noedit: true
cid: docsHome
layout: docsportal_home
class: gridPage gridPageHome
linkTitle: "Головна"
main_menu: true
weight: 10
hide_feedback: true
menu:
main:
title: "Документація"
weight: 20
post: >
<p>Дізнайтеся про основи роботи з Kubernetes, використовуючи схеми, навчальну та довідкову документацію. Ви можете навіть <a href="/editdocs/" data-auto-burger-exclude>зробити свій внесок у документацію</a>!</p>
overview: >
Kubernetes - рушій оркестрації контейнерів з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками. Цей проект розробляється під егідою Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>).
cards:
- name: concepts
title: "Розуміння основ"
description: "Дізнайтеся про Kubernetes і його фундаментальні концепції."
button: "Дізнатися про концепції"
button_path: "/docs/concepts"
- name: tutorials
title: "Спробуйте Kubernetes"
description: "Дізнайтеся із навчальних матеріалів, як розгортати застосунки в Kubernetes."
button: "Переглянути навчальні матеріали"
button_path: "/docs/tutorials"
- name: setup
title: "Налаштування кластера"
description: "Розгорніть Kubernetes з урахуванням власних ресурсів і потреб."
button: "Налаштувати Kubernetes"
button_path: "/docs/setup"
- name: tasks
title: "Дізнайтеся, як користуватись Kubernetes"
description: "Ознайомтеся з типовими задачами і способами їх виконання за допомогою короткого алгоритму дій."
button: "Переглянути задачі"
button_path: "/docs/tasks"
- name: reference
title: Переглянути довідкову інформацію
description: Ознайомтеся з термінологією, синтаксисом командного рядка, типами ресурсів API і документацією з налаштування інструментів.
button: Переглянути довідкову інформацію
button_path: /docs/reference
- name: contribute
title: Зробити внесок у документацію
description: Будь-хто може зробити свій внесок, незалежно від того, чи ви нещодавно долучилися до проекту, чи працюєте над ним вже довгий час.
button: Зробити внесок у документацію
button_path: /docs/contribute
- name: download
title: Завантажити Kubernetes
description: Якщо ви встановлюєте Kubernetes чи оновлюєтесь до останньої версії, звіряйтеся з актуальною інформацією по релізу.
- name: about
title: Про документацію
description: Цей вебсайт містить документацію по актуальній і чотирьох попередніх версіях Kubernetes.
---
content/uk/docs/reference/glossary/applications.md
+16
View File
@@ -0,0 +1,16 @@
---
# title: Applications
title: Застосунки
id: applications
date: 2019-05-12
full_link:
# short_description: >
# The layer where various containerized applications run.
short_description: >
Шар, в якому запущено контейнерізовані застосунки.
aka:
tags:
- fundamental
---
<!-- The layer where various containerized applications run. -->
Шар, в якому запущено контейнерізовані застосунки.
content/uk/docs/reference/glossary/cluster-infrastructure.md
+17
View File
@@ -0,0 +1,17 @@
---
# title: Cluster Infrastructure
title: Інфраструктура кластера
id: cluster-infrastructure
date: 2019-05-12
full_link:
# short_description: >
# The infrastructure layer provides and maintains VMs, networking, security groups and others.
short_description: >
Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо.
aka:
tags:
- operations
---
<!-- The infrastructure layer provides and maintains VMs, networking, security groups and others. -->
Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо.
content/uk/docs/reference/glossary/cluster-operations.md
+16
View File
@@ -0,0 +1,16 @@
---
# title: Cluster Operations
title: Операції з кластером
id: cluster-operations
date: 2019-05-12
full_link:
# short_description: >
# Activities such as upgrading the clusters, implementing security, storage, ingress, networking, logging and monitoring, and other operations involved in managing a Kubernetes cluster.
short_description: >
Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером.
aka:
tags:
- operations
---
<!-- Activities such as upgrading the clusters, implementing security, storage, ingress, networking, logging and monitoring, and other operations involved in managing a Kubernetes cluster. -->
Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером.
content/uk/docs/reference/glossary/cluster.md
+22
View File
@@ -0,0 +1,22 @@
---
# title: Cluster
title: Кластер
id: cluster
date: 2019-06-15
full_link:
# short_description: >
# A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
short_description: >
Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол.
aka:
tags:
- fundamental
- operation
---
<!-- A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node. -->
Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол.
<!--more-->
<!-- The worker node(s) host the pods that are the components of the application. The Control Plane manages the worker nodes and the pods in the cluster. In production environments, the Control Plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability. -->
На робочих вузлах розміщуються Pod'и, які є складовими застосунку. Площина управління керує робочими вузлами і Pod'ами кластера. У прод оточеннях площина управління зазвичай розповсюджується на багато комп'ютерів, а кластер складається з багатьох вузлів для забезпечення відмовостійкості і високої доступності.
content/uk/docs/reference/glossary/control-plane.md
+17
View File
@@ -0,0 +1,17 @@
---
# title: Control Plane
title: Площина управління
id: control-plane
date: 2019-05-12
full_link:
# short_description: >
# The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.
short_description: >
Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів.
aka:
tags:
- fundamental
---
<!-- The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. -->
Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів.
content/uk/docs/reference/glossary/data-plane.md
+17
View File
@@ -0,0 +1,17 @@
---
# title: Data Plane
title: Площина даних
id: data-plane
date: 2019-05-12
full_link:
# short_description: >
# The layer that provides capacity such as CPU, memory, network, and storage so that the containers can run and connect to a network.
short_description: >
Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі.
aka:
tags:
- fundamental
---
<!-- The layer that provides capacity such as CPU, memory, network, and storage so that the containers can run and connect to a network. -->
Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі.
content/uk/docs/reference/glossary/deployment.md
+23
View File
@@ -0,0 +1,23 @@
---
title: Deployment
id: deployment
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/deployment/
# short_description: >
# An API object that manages a replicated application.
short_description: >
Об'єкт API, що керує реплікованим застосунком.
aka:
tags:
- fundamental
- core-object
- workload
---
<!-- An API object that manages a replicated application. -->
Об'єкт API, що керує реплікованим застосунком.
<!--more-->
<!-- Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the Pods are distributed among the nodes of a cluster. -->
Кожна репліка являє собою {{< glossary_tooltip term_id="pod" text="Pod" >}}; Pod'и розподіляються між вузлами кластера.
content/uk/docs/reference/glossary/index.md
+17
View File
@@ -0,0 +1,17 @@
---
approvers:
- maxymvlasov
- anastyakulyk
# title: Standardized Glossary
title: Глосарій
layout: glossary
noedit: true
default_active_tag: fundamental
weight: 5
card:
name: reference
weight: 10
# title: Glossary
title: Глосарій
---
content/uk/docs/reference/glossary/kube-apiserver.md
+29
View File
@@ -0,0 +1,29 @@
---
# title: API server
title: API-сервер
id: kube-apiserver
date: 2018-04-12
full_link: /docs/reference/generated/kube-apiserver/
# short_description: >
# Control plane component that serves the Kubernetes API.
short_description: >
Компонент площини управління, що надає доступ до API Kubernetes.
aka:
- kube-apiserver
tags:
- architecture
- fundamental
---
<!-- The API server is a component of the Kubernetes
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} that exposes the Kubernetes API.
The API server is the front end for the Kubernetes control plane.
-->
API-сервер є компонентом {{< glossary_tooltip text="площини управління" term_id="control-plane" >}} Kubernetes, через який можна отримати доступ до API Kubernetes. API-сервер є фронтендом площини управління Kubernetes.
<!--more-->
<!-- The main implementation of a Kubernetes API server is [kube-apiserver](/docs/reference/generated/kube-apiserver/). -->
<!-- kube-apiserver is designed to scale horizontally&mdash;that is, it scales by deploying more instances. -->
<!-- You can run several instances of kube-apiserver and balance traffic between those instances. -->
Основною реалізацією Kubernetes API-сервера є [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver підтримує горизонтальне масштабування, тобто масштабується за рахунок збільшення кількості інстансів. kube-apiserver можна запустити на декількох інстансах, збалансувавши між ними трафік.
content/uk/docs/reference/glossary/kube-controller-manager.md
+22
View File
@@ -0,0 +1,22 @@
---
title: kube-controller-manager
id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
# short_description: >
# Control Plane component that runs controller processes.
short_description: >
Компонент площини управління, який запускає процеси контролера.
aka:
tags:
- architecture
- fundamental
---
<!-- Control Plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes. -->
Компонент площини управління, який запускає процеси {{< glossary_tooltip text="контролера" term_id="controller" >}}.
<!--more-->
<!-- Logically, each {{< glossary_tooltip text="controller" term_id="controller" >}} is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process. -->
За логікою, кожен {{< glossary_tooltip text="контролер" term_id="controller" >}} є окремим процесом. Однак для спрощення їх збирають в один бінарний файл і запускають як єдиний процес.
content/uk/docs/reference/glossary/kube-proxy.md
+33
View File
@@ -0,0 +1,33 @@
---
title: kube-proxy
id: kube-proxy
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-proxy/
# short_description: >
# `kube-proxy` is a network proxy that runs on each node in the cluster.
short_description: >
`kube-proxy` - це мережеве проксі, що запущене на кожному вузлі кластера.
aka:
tags:
- fundamental
- networking
---
<!-- [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) is a
network proxy that runs on each node in your cluster, implementing part of
the Kubernetes {{< glossary_tooltip term_id="service">}} concept.
-->
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) є мережевим проксі, що запущене на кожному вузлі кластера і реалізує частину концепції Kubernetes {{< glossary_tooltip term_id="service" text="Service">}}.
<!--more-->
<!--kube-proxy maintains network rules on nodes. These network rules allow
network communication to your Pods from network sessions inside or outside
of your cluster.
-->
kube-proxy відповідає за мережеві правила на вузлах. Ці правила обумовлюють підключення по мережі до ваших Pod'ів всередині чи поза межами кластера.
<!--kube-proxy uses the operating system packet filtering layer if there is one
and it's available. Otherwise, kube-proxy forwards the traffic itself.
-->
kube-proxy використовує шар фільтрації пакетів операційної системи, за наявності такого. В іншому випадку kube-proxy скеровує трафік самостійно.
content/uk/docs/reference/glossary/kube-scheduler.md
+22
View File
@@ -0,0 +1,22 @@
---
title: kube-scheduler
id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
# short_description: >
# Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
short_description: >
Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.
aka:
tags:
- architecture
---
<!-- Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on. -->
Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.
<!--more-->
<!--Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines.
-->
При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity і anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.
content/uk/docs/reference/glossary/kubelet.md
+23
View File
@@ -0,0 +1,23 @@
---
title: Kubelet
id: kubelet
date: 2018-04-12
full_link: /docs/reference/generated/kubelet
# short_description: >
# An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
short_description: >
Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах.
aka:
tags:
- fundamental
- core-object
---
<!-- An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. -->
Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах.
<!--more-->
<!--The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.
-->
kubelet використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes.
content/uk/docs/reference/glossary/pod.md
+23
View File
@@ -0,0 +1,23 @@
---
# title: Pod
title: Pod
id: pod
date: 2018-04-12
full_link: /docs/concepts/workloads/pods/pod-overview/
# short_description: >
# The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster.
short_description: >
Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу контейнерів, що запущені у вашому кластері.
aka:
tags:
- core-object
- fundamental
---
<!-- The smallest and simplest Kubernetes object. A Pod represents a set of running {{< glossary_tooltip text="containers" term_id="container" >}} on your cluster. -->
Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу {{< glossary_tooltip text="контейнерів" term_id="container" >}}, що запущені у вашому кластері.
<!--more-->
<!-- A Pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a {{< glossary_tooltip term_id="deployment" >}}. -->
Як правило, в одному Pod'і запускається один контейнер. У Pod'і також можуть бути запущені допоміжні контейнери, що забезпечують додаткову функціональність, наприклад, логування. Управління Pod'ами зазвичай здійснює {{< glossary_tooltip term_id="deployment" >}}.
content/uk/docs/reference/glossary/selector.md
+22
View File
@@ -0,0 +1,22 @@
---
# title: Selector
title: Селектор
id: selector
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/labels/
# short_description: >
# Allows users to filter a list of resources based on labels.
short_description: >
Дозволяє користувачам фільтрувати ресурси за мітками.
aka:
tags:
- fundamental
---
<!-- Allows users to filter a list of resources based on labels. -->
Дозволяє користувачам фільтрувати ресурси за мітками.
<!--more-->
<!-- Selectors are applied when querying lists of resources to filter them by {{< glossary_tooltip text="Labels" term_id="label" >}}. -->
Селектори застосовуються при створенні запитів для фільтрації ресурсів за {{< glossary_tooltip text="мітками" term_id="label" >}}.
content/uk/docs/reference/glossary/service.md
Executable
+24
View File
@@ -0,0 +1,24 @@
---
title: Service
id: service
date: 2018-04-12
full_link: /docs/concepts/services-networking/service/
# A way to expose an application running on a set of Pods as a network service.
short_description: >
Спосіб відкрити доступ до застосунку, що запущений на декількох Pod'ах у вигляді мережевої служби.
aka:
tags:
- fundamental
- core-object
---
<!--
An abstract way to expose an application running on a set of as a network service.
-->
Це абстрактний спосіб відкрити доступ до застосунку, що працює як один (або декілька) {{< glossary_tooltip text="Pod'ів" term_id="pod" >}} у вигляді мережевої служби.
<!--more-->
<!--The set of Pods targeted by a Service is (usually) determined by a {{< glossary_tooltip text="selector" term_id="selector" >}}. If more Pods are added or removed, the set of Pods matching the selector will change. The Service makes sure that network traffic can be directed to the current set of Pods for the workload.
-->
Переважно група Pod'ів визначається як Service за допомогою {{< glossary_tooltip text="селектора" term_id="selector" >}}. Додання або вилучення Pod'ів змінить групу Pod'ів, визначених селектором. Service забезпечує надходження мережевого трафіка до актуальної групи Pod'ів для підтримки робочого навантаження.
content/uk/docs/setup/_index.md
+136
View File
@@ -0,0 +1,136 @@
---
reviewers:
- brendandburns
- erictune
- mikedanese
no_issue: true
title: Початок роботи
main_menu: true
weight: 20
content_template: templates/concept
card:
name: setup
weight: 20
anchors:
- anchor: "#навчальне-середовище"
title: Навчальне середовище
- anchor: "#прод-оточення"
title: Прод оточення
---
{{% capture overview %}}
<!--This section covers different options to set up and run Kubernetes.
-->
У цьому розділі розглянуто різні варіанти налаштування і запуску Kubernetes.
<!--Different Kubernetes solutions meet different requirements: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster.
-->
Різні рішення Kubernetes відповідають різним вимогам: легкість в експлуатації, безпека, система контролю, наявні ресурси та досвід, необхідний для управління кластером.
<!--You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter; or choose a managed Kubernetes cluster. You can also create custom solutions across a wide range of cloud providers, or bare metal environments.
-->
Ви можете розгорнути Kubernetes кластер на робочому комп'ютері, у хмарі чи в локальному дата-центрі, або обрати керований Kubernetes кластер. Також можна створити індивідуальні рішення на базі різних провайдерів хмарних сервісів або на звичайних серверах.
<!--More simply, you can create a Kubernetes cluster in learning and production environments.
-->
Простіше кажучи, ви можете створити Kubernetes кластер у навчальному і в прод оточеннях.
{{% /capture %}}
{{% capture body %}}
<!--## Learning environment
-->
## Навчальне оточення {#навчальне-оточення}
<!--If you're learning Kubernetes, use the Docker-based solutions: tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
-->
Для вивчення Kubernetes використовуйте рішення на базі Docker: інструменти, підтримувані спільнотою Kubernetes, або інші інструменти з сімейства проектів для налаштування Kubernetes кластера на локальному комп'ютері.
{{< table caption="Таблиця інструментів для локального розгортання Kubernetes, які підтримуються спільнотою або входять до сімейства проектів Kubernetes." >}}
|Спільнота |Сімейство проектів |
| ------------ | -------- |
| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
| | [Minishift](https://docs.okd.io/latest/minishift/)|
| | [MicroK8s](https://microk8s.io/)|
| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
| | [k3s](https://k3s.io)|
## Прод оточення {#прод-оточення}
<!--When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider.
-->
Обираючи рішення для проду, визначіться, якими з функціональних складових (або абстракцій) Kubernetes кластера ви хочете керувати самі, а управління якими - доручити провайдеру.
<!--Some possible abstractions of a Kubernetes cluster are {{< glossary_tooltip text="applications" term_id="applications" >}}, {{< glossary_tooltip text="data plane" term_id="data-plane" >}}, {{< glossary_tooltip text="control plane" term_id="control-plane" >}}, {{< glossary_tooltip text="cluster infrastructure" term_id="cluster-infrastructure" >}}, and {{< glossary_tooltip text="cluster operations" term_id="cluster-operations" >}}.
-->
У Kubernetes кластері можливі наступні абстракції: {{< glossary_tooltip text="застосунки" term_id="applications" >}}, {{< glossary_tooltip text="площина даних" term_id="data-plane" >}}, {{< glossary_tooltip text="площина управління" term_id="control-plane" >}}, {{< glossary_tooltip text="інфраструктура кластера" term_id="cluster-infrastructure" >}} та {{< glossary_tooltip text="операції з кластером" term_id="cluster-operations" >}}.
<!--The following diagram lists the possible abstractions of a Kubernetes cluster and whether an abstraction is self-managed or managed by a provider.
-->
На діаграмі нижче показані можливі абстракції Kubernetes кластера із зазначенням, які з них потребують самостійного управління, а які можуть бути керовані провайдером.
Рішення для прод оточення![Рішення для прод оточення](/images/docs/KubernetesSolutions.svg)
{{< table caption="Таблиця рішень для прод оточення містить перелік провайдерів і їх технологій." >}}
<!--The following production environment solutions table lists the providers and the solutions that they offer.
-->
Таблиця рішень для прод оточення містить перелік провайдерів і технологій, які вони пропонують.
|Провайдери | Керований сервіс | Хмара "під ключ" | Локальний дата-центр | Під замовлення (хмара) | Під замовлення (локальні ВМ)| Під замовлення (сервери без ОС) |
| --------- | ------ | ------ | ------ | ------ | ------ | ----- |
| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | &#x2714; | &#x2714; | | |
| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | &#x2714; | | | |
| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | |
| [AppsCode](https://appscode.com/products/pharmer/) | &#x2714; | | | | |
| [APPUiO](https://appuio.ch/)  | &#x2714; | &#x2714; | &#x2714; | | | |
| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | &#x2714; | | &#x2714; | &#x2714; | &#x2714; |
| [CenturyLink Cloud](https://www.ctl.io/) | | &#x2714; | | | |
| [Cisco Container Platform](https://cisco.com/go/containers) | | | &#x2714; | | |
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | &#x2714; |&#x2714; |
| [CloudStack](https://cloudstack.apache.org/) | | | | | &#x2714;|
| [Canonical](https://ubuntu.com/kubernetes) | &#x2714; | &#x2714; | &#x2714; | &#x2714; |&#x2714; | &#x2714;
| [Containership](https://containership.io) | &#x2714; |&#x2714; | | | |
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | &#x2714;
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | &#x2714; | | | | |
| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |&#x2714; | &#x2714; | | | &#x2714;
| [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
| [Giant Swarm](https://www.giantswarm.io/) | &#x2714; | &#x2714; | &#x2714; | |
| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | |
| [Hidora](https://hidora.com/) | &#x2714; | &#x2714;| &#x2714; | | | | | | | |
| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
| [Kontena Pharos](https://www.kontena.io/pharos/) | |&#x2714;| &#x2714; | | |
| [KubeOne](https://kubeone.io/) | | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; |
| [Kubermatic](https://kubermatic.io/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | |
| [KubeSail](https://kubesail.com/) | &#x2714; | | | | |
| [Kubespray](https://kubespray.io/#/) | | | |&#x2714; | &#x2714; | &#x2714; |
| [Kublr](https://kublr.com/) |&#x2714; | &#x2714; |&#x2714; |&#x2714; |&#x2714; |&#x2714; |
| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | |
| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | &#x2714; | | |
| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | &#x2714; | &#x2714; | &#x2714; | | |
| [Nirmata](https://www.nirmata.com/) | | &#x2714; | &#x2714; | | |
| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) |
| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | |
| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/)
| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | &#x2714; | &#x2714; | | | |
| [oVirt](https://www.ovirt.org/) | | | | | &#x2714; |
| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | |
| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | &#x2714; | &#x2714; | &#x2714;
| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/)
| [Supergiant](https://supergiant.io/) | |&#x2714; | | | |
| [SUSE](https://www.suse.com/) | | &#x2714; | | | |
| [SysEleven](https://www.syseleven.io/) | &#x2714; | | | | |
| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | &#x2714; | &#x2714; | | | &#x2714; |
| [VEXXHOST](https://vexxhost.com/) | &#x2714; | &#x2714; | | | |
| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
| [Z.A.R.V.I.S.](https://zarvis.ai/) | &#x2714; | | | | | |
{{% /capture %}}
content/uk/docs/setup/best-practices/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
#title: Best practices
title: Найкращі практики
weight: 40
---
content/uk/docs/setup/learning-environment/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: Learning environment
title: Навчальне оточення
weight: 20
---
content/uk/docs/setup/production-environment/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
#title: Production environment
title: Прод оточення
weight: 30
---
content/uk/docs/setup/production-environment/on-premises-vm/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: On-Premises VMs
title: Менеджери віртуалізації
weight: 40
---
content/uk/docs/setup/production-environment/tools/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: Installing Kubernetes with deployment tools
title: Встановлення Kubernetes за допомогою інструментів розгортання
weight: 30
---
content/uk/docs/setup/production-environment/tools/kubeadm/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: "Bootstrapping clusters with kubeadm"
title: "Запуск кластерів з kubeadm"
weight: 10
---
content/uk/docs/setup/production-environment/turnkey/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: Turnkey Cloud Solutions
title: Хмарні рішення під ключ
weight: 30
---
content/uk/docs/setup/production-environment/windows/_index.md
+5
View File
@@ -0,0 +1,5 @@
---
# title: "Windows in Kubernetes"
title: "Windows в Kubernetes"
weight: 50
---
content/uk/docs/setup/release/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
#title: "Release notes and version skew"
title: "Зміни в релізах нових версій"
weight: 10
---
content/uk/docs/templates/feature-state-alpha.txt
Vendored
+7
View File
@@ -0,0 +1,7 @@
Наразі цей компонент у статусі *alpha*, що означає:
* Назва версії містить слово alpha (напр. v1alpha1).
* Увімкнення цього компонента може призвести до помилок у системі. За умовчанням цей компонент вимкнутий.
* Підтримка цього компонентa може бути припинена у будь-який час без попередження.
* API може стати несумісним у наступних релізах без попередження.
* Рекомендований до використання лише у тестових кластерах через підвищений ризик виникнення помилок і відсутність довгострокової підтримки.
content/uk/docs/templates/feature-state-beta.txt
Vendored
+22
View File
@@ -0,0 +1,22 @@
<!--This feature is currently in a *beta* state, meaning:
-->
Наразі цей компонент у статусі *beta*, що означає:
<!--* The version names contain beta (e.g. v2beta3).
-->
* Назва версії містить слово beta (наприклад, v2beta3).
<!--* Code is well tested. Enabling the feature is considered safe. Enabled by default.
-->
* Код добре відтестований. Увімкнення цього компонента не загрожує роботі системи. Компонент увімкнутий за умовчанням.
<!--* Support for the overall feature will not be dropped, though details may change.
-->
* Загальна підтримка цього компонента триватиме, однак деталі можуть змінитися.
<!--* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
-->
* У наступній beta- чи стабільній версії схема та/або семантика об'єктів може змінитися і стати несумісною. У такому випадку ми надамо інструкції для міграції на наступну версію. Це може призвести до видалення, редагування і перестворення об'єктів API. У процесі редагування вам, можливо, знадобиться продумати зміни в об'єкті. Це може призвести до недоступності застосунків, для роботи яких цей компонент є істотно важливим.
<!--* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
-->
* Використання компонента рекомендоване лише у некритичних для безперебійної діяльності випадках через ризик несумісних змін у подальших релізах. Це обмеження може бути пом'якшене у випадку декількох кластерів, які можна оновлювати окремо.
<!--* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.**
-->
* **Будь ласка, спробуйте beta-версії наших компонентів і поділіться з нами своєю думкою! Після того, як компонент вийде зі статусу beta, нам буде важче змінити його.**
content/uk/docs/templates/feature-state-deprecated.txt
Vendored
+4
View File
@@ -0,0 +1,4 @@
<!--This feature is *deprecated*. For more information on this state, see the [Kubernetes Deprecation Policy](/docs/reference/deprecation-policy/).
-->
Цей компонент є *застарілим*. Дізнатися більше про цей статус ви можете зі статті [Політика Kubernetes щодо застарілих компонентів](/docs/reference/deprecation-policy/).
content/uk/docs/templates/feature-state-stable.txt
Vendored
+11
View File
@@ -0,0 +1,11 @@
<!--This feature is *stable*, meaning:
-->
Цей компонент є *стабільним*, що означає:
<!--* The version name is vX where X is an integer.
-->
* Назва версії становить vX, де X є цілим числом.
<!--* Stable versions of features will appear in released software for many subsequent versions.
-->
* Стабільні версії компонентів з'являтимуться у багатьох наступних версіях програмного забезпечення.
content/uk/docs/templates/index.md
Vendored
+15
View File
@@ -0,0 +1,15 @@
---
headless: true
resources:
- src: "*alpha*"
title: "alpha"
- src: "*beta*"
title: "beta"
- src: "*deprecated*"
# title: "deprecated"
title: "застарілий"
- src: "*stable*"
# title: "stable"
title: "стабільний"
---
content/uk/docs/tutorials/_index.md
+90
View File
@@ -0,0 +1,90 @@
---
#title: Tutorials
title: Навчальні матеріали
main_menu: true
weight: 60
content_template: templates/concept
---
{{% capture overview %}}
<!--This section of the Kubernetes documentation contains tutorials.
A tutorial shows how to accomplish a goal that is larger than a single
[task](/docs/tasks/). Typically a tutorial has several sections,
each of which has a sequence of steps.
Before walking through each tutorial, you may want to bookmark the
[Standardized Glossary](/docs/reference/glossary/) page for later references.
-->
У цьому розділі документації Kubernetes зібрані навчальні матеріали. Кожний матеріал показує, як досягти окремої мети, що більша за одне [завдання](/docs/tasks/). Зазвичай навчальний матеріал має декілька розділів, кожен з яких містить певну послідовність дій. До ознайомлення з навчальними матеріалами вам, можливо, знадобиться додати у закладки сторінку з [Глосарієм](/docs/reference/glossary/) для подальшого консультування.
{{% /capture %}}
{{% capture body %}}
<!--## Basics
-->
## Основи
<!--* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
-->
* [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) - детальний навчальний матеріал з інтерактивними уроками, що допоможе вам зрозуміти Kubernetes і спробувати його базову функціональність.
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Привіт Minikube](/docs/tutorials/hello-minikube/)
<!--## Configuration
-->
## Конфігурація
* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
## Застосунки без стану (Stateless Applications) {#застосунки-без-стану}
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом}
* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
## CI/CD Pipeline
* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
## Кластери
* [AppArmor](/docs/tutorials/clusters/apparmor/)
## Сервіси
* [Using Source IP](/docs/tutorials/services/source-ip/)
{{% /capture %}}
{{% capture whatsnext %}}
<!--If you would like to write a tutorial, see
[Using Page Templates](/docs/home/contribute/page-templates/)
for information about the tutorial page type and the tutorial template.
-->
Якщо ви хочете написати навчальний матеріал, у статті
[Використання шаблонів сторінок](/docs/home/contribute/page-templates/)
ви знайдете інформацію про тип навчальної сторінки і шаблон.
{{% /capture %}}
content/uk/docs/tutorials/hello-minikube.md
+394
View File
@@ -0,0 +1,394 @@
---
#title: Hello Minikube
title: Привіт Minikube
content_template: templates/tutorial
weight: 5
menu:
main:
#title: "Get Started"
title: "Початок роботи"
weight: 10
#post: >
#<p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
post: >
<p>Готові попрацювати? Створимо простий Kubernetes кластер для запуску Node.js застосунку "Hello World".</p>
card:
#name: tutorials
name: навчальні матеріали
weight: 10
---
{{% capture overview %}}
<!--This tutorial shows you how to run a simple Hello World Node.js app
on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
Katacoda provides a free, in-browser Kubernetes environment.
-->
З цього навчального матеріалу ви дізнаєтесь, як запустити у Kubernetes простий Hello World застосунок на Node.js за допомогою [Minikube](/docs/setup/learning-environment/minikube) і Katacoda. Katacoda надає безплатне Kubernetes середовище, що доступне у вашому браузері.
<!--{{< note >}}
You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
{{< /note >}}
-->
{{< note >}}
Також ви можете навчатись за цим матеріалом, якщо встановили [Minikube локально](/docs/tasks/tools/install-minikube/).
{{< /note >}}
{{% /capture %}}
{{% capture objectives %}}
<!--* Deploy a hello world application to Minikube.
-->
* Розгорнути Hello World застосунок у Minikube.
<!--* Run the app.
-->
* Запустити застосунок.
<!--* View application logs.
-->
* Переглянути логи застосунку.
{{% /capture %}}
{{% capture prerequisites %}}
<!--This tutorial provides a container image built from the following files:
-->
У цьому навчальному матеріалі ми використовуємо образ контейнера, зібраний із наступних файлів:
{{< codenew language="js" file="minikube/server.js" >}}
{{< codenew language="conf" file="minikube/Dockerfile" >}}
<!--For more information on the `docker build` command, read the [Docker documentation](https://docs.docker.com/engine/reference/commandline/build/).
-->
Більше інформації про команду `docker build` ви знайдете у [документації Docker](https://docs.docker.com/engine/reference/commandline/build/).
{{% /capture %}}
{{% capture lessoncontent %}}
<!--## Create a Minikube cluster
-->
## Створення Minikube кластера
<!--1. Click **Launch Terminal**
-->
1. Натисніть кнопку **Запуск термінала**
{{< kat-button >}}
<!--{{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}}
-->
{{< note >}}Якщо Minikube встановлений локально, виконайте команду `minikube start`.{{< /note >}}
<!--2. Open the Kubernetes dashboard in a browser:
-->
2. Відкрийте Kubernetes дашборд у браузері:
```shell
minikube dashboard
```
<!--3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
-->
3. Тільки для Katacoda: у верхній частині вікна термінала натисніть знак плюс, а потім -- **Select port to view on Host 1**.
<!--4. Katacoda environment only: Type `30000`, and then click **Display Port**.
-->
4. Тільки для Katacoda: введіть `30000`, а потім натисніть **Display Port**.
<!--## Create a Deployment
-->
## Створення Deployment
<!--A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
tied together for the purposes of administration and networking. The Pod in this
tutorial has only one Container. A Kubernetes
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
Pod and restarts the Pod's Container if it terminates. Deployments are the
recommended way to manage the creation and scaling of Pods.
-->
[*Pod*](/docs/concepts/workloads/pods/pod/) у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Pod має лише один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє стан Pod'а і перезапускає контейнер Pod'а, якщо контейнер перестає працювати. Створювати і масштабувати Pod'и рекомендується за допомогою Deployment'ів.
<!--1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
Pod runs a Container based on the provided Docker image.
-->
1. За допомогою команди `kubectl create` створіть Deployment, який керуватиме Pod'ом. Pod запускає контейнер на основі наданого Docker образу.
```shell
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
```
<!--2. View the Deployment:
-->
2. Перегляньте інформацію про запущений Deployment:
```shell
kubectl get deployments
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
```
<!--3. View the Pod:
-->
3. Перегляньте інформацію про запущені Pod'и:
```shell
kubectl get pods
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
```
<!--4. View cluster events:
-->
4. Перегляньте події кластера:
```shell
kubectl get events
```
<!--5. View the `kubectl` configuration:
-->
5. Перегляньте конфігурацію `kubectl`:
```shell
kubectl config view
```
<!--{{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
-->
{{< note >}}Більше про команди `kubectl` ви можете дізнатися зі статті [Загальна інформація про kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}}
<!--## Create a Service
-->
## Створення Service
<!--By default, the Pod is only accessible by its internal IP address within the
Kubernetes cluster. To make the `hello-node` Container accessible from outside the
Kubernetes virtual network, you have to expose the Pod as a
Kubernetes [*Service*](/docs/concepts/services-networking/service/).
-->
За умовчанням, Pod доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер `hello-node` став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Kubernetes [*Service*](/docs/concepts/services-networking/service/).
<!--1. Expose the Pod to the public internet using the `kubectl expose` command:
-->
1. Відкрийте Pod для публічного доступу з інтернету за допомогою команди `kubectl expose`:
```shell
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
```
<!--The `--type=LoadBalancer` flag indicates that you want to expose your Service
outside of the cluster.
-->
Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Service за межами кластера.
<!--2. View the Service you just created:
-->
2. Перегляньте інформацію про Service, який ви щойно створили:
```shell
kubectl get services
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
```
<!--On cloud providers that support load balancers,
an external IP address would be provisioned to access the Service. On Minikube,
the `LoadBalancer` type makes the Service accessible through the `minikube service`
command.
-->
Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Service надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Service доступним ззовні за допомогою команди `minikube service`.
<!--3. Run the following command:
-->
3. Виконайте наступну команду:
```shell
minikube service hello-node
```
<!--4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
-->
4. Тільки для Katacoda: натисніть знак плюс, а потім -- **Select port to view on Host 1**.
<!--5. Katacoda environment only: Note the 5 digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`.
-->
5. Тільки для Katacoda: запишіть п'ятизначний номер порту, що відображається напроти `8080` у виводі сервісу. Номер цього порту генерується довільно і тому може бути іншим у вашому випадку. Введіть номер порту у призначене для цього текстове поле і натисніть Display Port. У нашому прикладі номер порту `30369`.
<!--This opens up a browser window that serves your app and shows the "Hello World" message.
-->
Це відкриє вікно браузера, в якому запущений ваш застосунок, і покаже повідомлення "Hello World".
<!--## Enable addons
-->
## Увімкнення розширень
<!--Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addons" >}} that can be enabled, disabled and opened in the local Kubernetes environment.
-->
Minikube має ряд вбудованих {{< glossary_tooltip text="розширень" term_id="addons" >}}, які можна увімкнути, вимкнути і відкрити у локальному Kubernetes оточенні.
<!--1. List the currently supported addons:
-->
1. Перегляньте перелік підтримуваних розширень:
```shell
minikube addons list
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
```
<!--2. Enable an addon, for example, `metrics-server`:
-->
2. Увімкніть розширення, наприклад `metrics-server`:
```shell
minikube addons enable metrics-server
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
metrics-server was successfully enabled
```
<!--3. View the Pod and Service you just created:
-->
3. Перегляньте інформацію про Pod і Service, які ви щойно створили:
```shell
kubectl get pod,svc -n kube-system
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
<!--4. Disable `metrics-server`:
-->
4. Вимкніть `metrics-server`:
```shell
minikube addons disable metrics-server
```
<!--The output is similar to:
-->
У виводі ви побачите подібну інформацію:
```
metrics-server was successfully disabled
```
<!--## Clean up
-->
## Вивільнення ресурсів
<!--Now you can clean up the resources you created in your cluster:
-->
Тепер ви можете видалити ресурси, які створили у вашому кластері:
```shell
kubectl delete service hello-node
kubectl delete deployment hello-node
```
<!--Optionally, stop the Minikube virtual machine (VM):
-->
За бажанням, зупиніть віртуальну машину (ВМ) з Minikube:
```shell
minikube stop
```
<!--Optionally, delete the Minikube VM:
-->
За бажанням, видаліть ВМ з Minikube:
```shell
minikube delete
```
{{% /capture %}}
{{% capture whatsnext %}}
<!--* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
-->
* Дізнайтеся більше про [об'єкти Deployment](/docs/concepts/workloads/controllers/deployment/).
<!--* Learn more about [Deploying applications](/docs/user-guide/deploying-applications/).
-->
* Дізнайтеся більше про [розгортання застосунків](/docs/user-guide/deploying-applications/).
<!--* Learn more about [Service objects](/docs/concepts/services-networking/service/).
-->
* Дізнайтеся більше про [об'єкти Service](/docs/concepts/services-networking/service/).
{{% /capture %}}
content/uk/docs/tutorials/kubernetes-basics/_index.html
+138
View File
@@ -0,0 +1,138 @@
---
title: Дізнатися про основи Kubernetes
linkTitle: Основи Kubernetes
weight: 10
card:
name: навчальні матеріали
weight: 20
title: Знайомство з основами
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-9">
<!--<h2>Kubernetes Basics</h2>
-->
<h2>Основи Kubernetes</h2>
<!--<p>This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and includes an interactive online tutorial. These interactive tutorials let you manage a simple cluster and its containerized applications for yourself.</p>
-->
<p>Цей навчальний матеріал ознайомить вас з основами системи оркестрації Kubernetes кластера. Кожен модуль містить загальну інформацію щодо основної функціональності і концепцій Kubernetes, а також інтерактивний онлайн-урок. Завдяки цим інтерактивним урокам ви зможете самостійно керувати простим кластером і розгорнутими в ньому контейнеризованими застосунками.</p>
<!--<p>Using the interactive tutorials, you can learn to:</p>
-->
<p>З інтерактивних уроків ви дізнаєтесь:</p>
<ul>
<!--<li>Deploy a containerized application on a cluster.</li>
-->
<li>як розгорнути контейнеризований застосунок у кластері.</li>
<!--<li>Scale the deployment.</li>
-->
<li>як масштабувати Deployment.</li>
<!--<li>Update the containerized application with a new software version.</li>
-->
<li>як розгорнути нову версію контейнеризованого застосунку.</li>
<!--<li>Debug the containerized application.</li>
-->
<li>як відлагодити контейнеризований застосунок.</li>
</ul>
<!--<p>The tutorials use Katacoda to run a virtual terminal in your web browser that runs Minikube, a small-scale local deployment of Kubernetes that can run anywhere. There's no need to install any software or configure anything; each interactive tutorial runs directly out of your web browser itself.</p>
-->
<p>Навчальні матеріали використовують Katacoda для запуску у вашому браузері віртуального термінала, в якому запущено Minikube - невеликий локально розгорнутий Kubernetes, що може працювати будь-де. Вам не потрібно встановлювати або налаштовувати жодне програмне забезпечення: кожен інтерактивний урок запускається просто у вашому браузері.</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-9">
<!--<h2>What can Kubernetes do for you?</h2>
-->
<h2>Чим Kubernetes може бути корисний для вас?</h2>
<!--<p>With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containerization helps package software to serve these goals, enabling applications to be released and updated in an easy and fast way without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.</p>
-->
<p>Від сучасних вебсервісів користувачі очікують доступності 24/7, а розробники - можливості розгортати нові версії цих застосунків по кілька разів на день. Контейнеризація, що допомагає упакувати програмне забезпечення, якнайкраще сприяє цим цілям. Вона дозволяє випускати і оновлювати застосунки легко, швидко та без простою. Із Kubernetes ви можете бути певні, що ваші контейнеризовані застосунки запущені там і тоді, де ви цього хочете, а також забезпечені усіма необхідними для роботи ресурсами та інструментами. Kubernetes - це висококласна платформа з відкритим вихідним кодом, в основі якої - накопичений досвід оркестрації контейнерів від Google, поєднаний із найкращими ідеями і практиками від спільноти.</p>
</div>
</div>
<br>
<div id="basics-modules" class="content__modules">
<!--<h2>Kubernetes Basics Modules</h2>
-->
<h2>Навчальні модулі "Основи Kubernetes"</h2>
<div class="row">
<div class="col-md-12">
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_01.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/"><h5>1. Створення Kubernetes кластера</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_02.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/"><h5>2. Розгортання застосунку</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_03.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/explore/explore-intro/"><h5>3. Вивчення застосунку</h5></a>
</div>
</div>
</div>
</div>
</div>
<div class="col-md-12">
<div class="row">
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_04.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/expose/expose-intro/"><h5>4. Відкриття доступу до застосунку за межами кластера</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_05.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/scale/scale-intro/"><h5>5. Масштабування застосунку</h5></a>
</div>
</div>
</div>
<div class="col-md-4">
<div class="thumbnail">
<a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><img src="/docs/tutorials/kubernetes-basics/public/images/module_06.svg?v=1469803628347" alt=""></a>
<div class="caption">
<a href="/docs/tutorials/kubernetes-basics/update/update-intro/"><h5>6. Оновлення застосунку</h5></a>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</main>
</div>
</body>
</html>
content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Створення кластера
weight: 10
---
content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+37
View File
@@ -0,0 +1,37 @@
---
title: Інтерактивний урок - Створення кластера
weight: 20
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
Для роботи з терміналом використовуйте комп'ютер або планшет
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Перейти до модуля 2<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+152
View File
@@ -0,0 +1,152 @@
---
title: Використання Minikube для створення кластера
weight: 10
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<div class="layout" id="top">
<main class="content">
<div class="row">
<div class="col-md-8">
<!--<h3>Objectives</h3>
-->
<h3>Цілі</h3>
<ul>
<!--<li>Learn what a Kubernetes cluster is.</li>
-->
<li>Зрозуміти, що таке Kubernetes кластер.</li>
<!--<li>Learn what Minikube is.</li>
-->
<li>Зрозуміти, що таке Minikube.</li>
<!--<li>Start a Kubernetes cluster using an online terminal.</li>
-->
<li>Запустити Kubernetes кластер за допомогою онлайн-термінала.</li>
</ul>
</div>
<div class="col-md-8">
<!--<h3>Kubernetes Clusters</h3>
-->
<h3>Kubernetes кластери</h3>
<!--<p>
<b>Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit.</b> The abstractions in Kubernetes allow you to deploy containerized applications to a cluster without tying them specifically to individual machines. To make use of this new model of deployment, applications need to be packaged in a way that decouples them from individual hosts: they need to be containerized. Containerized applications are more flexible and available than in past deployment models, where applications were installed directly onto specific machines as packages deeply integrated into the host. <b>Kubernetes automates the distribution and scheduling of application containers across a cluster in a more efficient way.</b> Kubernetes is an open-source platform and is production-ready.
</p>
-->
<p>
<b>Kubernetes координує високодоступний кластер комп'ютерів, з'єднаних таким чином, щоб працювати як одне ціле.</b> Абстракції Kubernetes дозволяють вам розгортати контейнеризовані застосунки в кластері без конкретної прив'язки до окремих машин. Для того, щоб скористатися цією новою моделлю розгортання, застосунки потрібно упакувати таким чином, щоб звільнити їх від прив'язки до окремих хостів, тобто контейнеризувати. Контейнеризовані застосунки більш гнучкі і доступні, ніж попередні моделі розгортання, що передбачали встановлення застосунків безпосередньо на призначені для цього машини у вигляді програмного забезпечення, яке глибоко інтегрувалося із хостом. <b>Kubernetes дозволяє автоматизувати розподіл і запуск контейнерів застосунку у кластері, а це набагато ефективніше.</b> Kubernetes - це платформа з відкритим вихідним кодом, готова для використання у проді.
</p>
<!--<p>A Kubernetes cluster consists of two types of resources:
<ul>
<li>The <b>Master</b> coordinates the cluster</li>
<li><b>Nodes</b> are the workers that run applications</li>
</ul>
</p>
-->
<p>Kubernetes кластер складається з двох типів ресурсів:
<ul>
<li> <b>master</b>, що координує роботу кластера</li>
<li><b>вузли (nodes)</b> - робочі машини, на яких запущені застосунки</li>
</ul>
</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<!--<h3>Summary:</h3>
-->
<h3>Зміст:</h3>
<ul>
<!--<li>Kubernetes cluster</li>
-->
<li>Kubernetes кластер</li>
<!--<li>Minikube</li>
-->
<li>Minikube</li>
</ul>
</div>
<div class="content__box content__box_fill">
<!--<p><i>
Kubernetes is a production-grade, open-source platform that orchestrates the placement (scheduling) and execution of application containers within and across computer clusters.
</i></p>
-->
<p><i>
Kubernetes - це довершена платформа з відкритим вихідним кодом, що оркеструє розміщення і запуск контейнерів застосунку всередині та між комп'ютерними кластерами.
</i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Схема кластера</h2>
</div>
</div>
<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<!--<p><b>The Master is responsible for managing the cluster.</b> The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p>
-->
<p><b>Master відповідає за керування кластером.</b> Master координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків і викатка оновлень.</p>
<!--<p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
-->
<p><b>Вузол (node) - це ВМ або фізичний комп'ютер, що виступає у ролі робочої машини в Kubernetes кластері.</b> Кожен вузол має kubelet - агент для управління вузлом і обміну даними з Kubernetes master. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як Docker або rkt. Kubernetes кластер у проді повинен складатися як мінімум із трьох вузлів.</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<!--<p><i>Masters manage the cluster and the nodes are used to host the running applications.</i></p>
-->
<p><i>Master'и керують кластером, а вузли використовуються для запуску застосунків.</i></p>
</div>
</div>
</div>
<div class="row">
<div class="col-md-8">
<!--<p>When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. <b>The nodes communicate with the master using the <a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a></b>, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.</p>
-->
<p>Коли ви розгортаєте застосунки у Kubernetes, ви кажете master-вузлу запустити контейнери застосунку. Master розподіляє контейнери для запуску на вузлах кластера. <b>Для обміну даними з master вузли використовують <a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a></b>, який надається master-вузлом. Кінцеві користувачі також можуть взаємодіяти із кластером безпосередньо через Kubernetes API.</p>
<!--<p>A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, macOS, and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this tutorial, however, you'll use a provided online terminal with Minikube pre-installed.</p>
-->
<p>Kubernetes кластер можна розгорнути як на фізичних, так і на віртуальних серверах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube - спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному комп'ютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status і delete. Однак у цьому уроці ви використовуватимете онлайн термінал із вже встановленим Minikube.</p>
<!--<p>Now that you know what Kubernetes is, let's go to the online tutorial and start our first cluster!</p>
-->
<p>Тепер ви знаєте, що таке Kubernetes. Тож давайте перейдемо до інтерактивного уроку і створимо ваш перший кластер!</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/" role="button">Почати інтерактивний урок <span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
content/uk/docs/tutorials/kubernetes-basics/deploy-app/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Розгортання застосунку
weight: 20
---
content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+41
View File
@@ -0,0 +1,41 @@
---
title: Інтерактивний урок - Розгортання застосунку
weight: 20
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<br>
<div class="katacoda">
<div class="katacoda__alert">
Для роботи з терміналом використовуйте комп'ютер або планшет
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Перейти до модуля 3<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>

Some files were not shown because too many files have changed in this diff Show More