diff --git a/_data/canonical-tags.yml b/_data/canonical-tags.yml deleted file mode 100644 index d5c4bcfdec49f..0000000000000 --- a/_data/canonical-tags.yml +++ /dev/null @@ -1,12 +0,0 @@ -- Fundamental -- API Object -- Metadata -- Configuration -- Security -- Networking -- Storage -- Operation -- Workload -- Component -- API -- Extension diff --git a/_data/canonical-tags/architecture.yaml b/_data/canonical-tags/architecture.yaml new file mode 100644 index 0000000000000..369aa36cc027b --- /dev/null +++ b/_data/canonical-tags/architecture.yaml @@ -0,0 +1,3 @@ +id: architecture +name: Architecture +description: The inner components of Kubernetes. diff --git a/_data/canonical-tags/community.yaml b/_data/canonical-tags/community.yaml new file mode 100644 index 0000000000000..34a60b5df26b5 --- /dev/null +++ b/_data/canonical-tags/community.yaml @@ -0,0 +1,3 @@ +id: community +name: Community +description: Related to Kubernetes open-source development. diff --git a/_data/canonical-tags/core-object.yaml b/_data/canonical-tags/core-object.yaml new file mode 100644 index 0000000000000..c816013899921 --- /dev/null +++ b/_data/canonical-tags/core-object.yaml @@ -0,0 +1,3 @@ +id: core-object +name: Core Object +description: A resource type that Kubernetes supports by default. diff --git a/_data/canonical-tags/extension.yaml b/_data/canonical-tags/extension.yaml new file mode 100644 index 0000000000000..6aacd8dac9e73 --- /dev/null +++ b/_data/canonical-tags/extension.yaml @@ -0,0 +1,3 @@ +id: extension +name: Extension +description: Supported customizations of Kubernetes. diff --git a/_data/canonical-tags/fundamental.yaml b/_data/canonical-tags/fundamental.yaml new file mode 100644 index 0000000000000..f9dc8f2398a22 --- /dev/null +++ b/_data/canonical-tags/fundamental.yaml @@ -0,0 +1,3 @@ +id: fundamental +name: Fundamental +description: Relevant for a first-time user of Kubernetes. diff --git a/_data/canonical-tags/networking.yaml b/_data/canonical-tags/networking.yaml new file mode 100644 index 0000000000000..481c02c50a733 --- /dev/null +++ b/_data/canonical-tags/networking.yaml @@ -0,0 +1,3 @@ +id: networking +name: Networking +description: How Kubernetes components talk to each other (and to programs outside the cluster). diff --git a/_data/canonical-tags/operation.yaml b/_data/canonical-tags/operation.yaml new file mode 100644 index 0000000000000..140be06e0cd31 --- /dev/null +++ b/_data/canonical-tags/operation.yaml @@ -0,0 +1,3 @@ +id: operation +name: Operation +description: Starting and maintaining Kubernetes. diff --git a/_data/canonical-tags/security.yaml b/_data/canonical-tags/security.yaml new file mode 100644 index 0000000000000..4bb7191a6f06c --- /dev/null +++ b/_data/canonical-tags/security.yaml @@ -0,0 +1,3 @@ +id: security +name: Security +description: Keeping Kubernetes applications safe and secure. diff --git a/_data/canonical-tags/storage.yaml b/_data/canonical-tags/storage.yaml new file mode 100644 index 0000000000000..e98d797b6e9f4 --- /dev/null +++ b/_data/canonical-tags/storage.yaml @@ -0,0 +1,3 @@ +id: storage +name: Storage +description: How Kubernetes applications handle persistent data. diff --git a/_data/canonical-tags/tool.yaml b/_data/canonical-tags/tool.yaml new file mode 100644 index 0000000000000..943d1ba4b0ca0 --- /dev/null +++ b/_data/canonical-tags/tool.yaml @@ -0,0 +1,3 @@ +id: tool +name: Tool +description: Software that makes Kubernetes easier or better to use. diff --git a/_data/canonical-tags/user-type.yaml b/_data/canonical-tags/user-type.yaml new file mode 100644 index 0000000000000..8f38725720684 --- /dev/null +++ b/_data/canonical-tags/user-type.yaml @@ -0,0 +1,3 @@ +id: user-type +name: User Type +description: Represents a common type of Kubernetes user. diff --git a/_data/canonical-tags/workload.yaml b/_data/canonical-tags/workload.yaml new file mode 100644 index 0000000000000..4b18a3644308e --- /dev/null +++ b/_data/canonical-tags/workload.yaml @@ -0,0 +1,3 @@ +id: workload +name: Workload +description: Applications running on Kubernetes. diff --git a/_data/glossary/_example.yml b/_data/glossary/_example.yml index d939c91f3c28c..34268a07c3853 100644 --- a/_data/glossary/_example.yml +++ b/_data/glossary/_example.yml @@ -1,13 +1,13 @@ id: _example name: Example K8s Term -formerly: +aka: - Slang K8s Term - Misnomer - Formerly Known as Prince related: -- Less Fancy K8s Term -- Tangential Term -- Commonly Used With +- id-of-less-fancy-k8s-term +- id-of-tangential-term +- id-of-commonly-used-with-term tags: - Some Tag short-description: | diff --git a/_data/glossary/application-architect.yaml b/_data/glossary/application-architect.yaml new file mode 100644 index 0000000000000..ad14229720410 --- /dev/null +++ b/_data/glossary/application-architect.yaml @@ -0,0 +1,11 @@ +id: application-architect +name: Application Architect +related: + - application-developer +tags: + - user-type +short-description: | + A person responsible for the high-level design of an application. +long-description: > + An architect ensures that an app's implementation allows it to interact with its surrounding components in a scalable, maintainable way. + Surrounding components include databases, logging infrastructure, and other microservices. diff --git a/_data/glossary/application-developer.yaml b/_data/glossary/application-developer.yaml new file mode 100644 index 0000000000000..5fc2fa9f80a3f --- /dev/null +++ b/_data/glossary/application-developer.yaml @@ -0,0 +1,11 @@ +id: application-developer +name: Application Developer +related: + - application-architect +tags: + - user-type +short-description: | + A person who writes an application that runs in a Kubernetes cluster. +long-description: > + An application developer focuses on one part of an application. + The scale of their focus may vary significantly in size. diff --git a/_data/glossary/approver.yaml b/_data/glossary/approver.yaml new file mode 100644 index 0000000000000..5047a782833cc --- /dev/null +++ b/_data/glossary/approver.yaml @@ -0,0 +1,10 @@ +id: approver +name: Approver +tags: +- community +short-description: | + A person who can review and approve Kubernetes code contributions. +long-description: > + While code review is focused on code quality and correctness, approval is focused on the holistic acceptance of a contribution. + Holistic acceptance includes backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, and others. + Approver status is scoped to a part of the codebase. diff --git a/_data/glossary/cla.yaml b/_data/glossary/cla.yaml new file mode 100644 index 0000000000000..75dd5408d31d9 --- /dev/null +++ b/_data/glossary/cla.yaml @@ -0,0 +1,8 @@ +id: cla +name: CLA (Contributor License Agreement) +tags: +- community +short-description: | + Terms under which a [contributor](#term-contributor) grants a license to an open source project for their contributions. +long-description: | + CLAs help resolve legal disputes involving contributed material and intellectual property (IP). diff --git a/_data/glossary/cluster-architect.yaml b/_data/glossary/cluster-architect.yaml new file mode 100644 index 0000000000000..9cec933e9389e --- /dev/null +++ b/_data/glossary/cluster-architect.yaml @@ -0,0 +1,12 @@ +id: cluster-architect +name: Cluster Architect +related: + - cluster + - cluster-operator +tags: + - user-type +short-description: | + A person who designs infrastructure that involves one or more Kubernetes clusters. + +long-description: | + Cluster architects are concerned with best practices for distributed systems, for example: high availability and security. diff --git a/_data/glossary/cluster-operator.yaml b/_data/glossary/cluster-operator.yaml new file mode 100644 index 0000000000000..82245178812ab --- /dev/null +++ b/_data/glossary/cluster-operator.yaml @@ -0,0 +1,16 @@ +id: cluster-operator +name: Cluster Operator +aka: + - Cluster Administrator +related: + - cluster + - cluster-architect +tags: + - user-type +short-description: | + A person who configures, controls, and monitors clusters. + +long-description: | + Their primary responsibility is keeping a cluster up and running, which may involve periodic maintenance activities or upgrades.
+ + **NOTE:** Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API. diff --git a/_data/glossary/cluster.yaml b/_data/glossary/cluster.yaml new file mode 100644 index 0000000000000..a85ce8d2f643e --- /dev/null +++ b/_data/glossary/cluster.yaml @@ -0,0 +1,9 @@ +id: cluster +name: Cluster +tags: +- fundamental +- operation +short-description: | + A set of machines, called nodes, that run containerized applications managed by Kubernetes. +long-description: | + A cluster has several worker nodes and at least one master node. diff --git a/_data/glossary/code-contributor.yaml b/_data/glossary/code-contributor.yaml new file mode 100644 index 0000000000000..acc98788631a7 --- /dev/null +++ b/_data/glossary/code-contributor.yaml @@ -0,0 +1,11 @@ +id: code-contributor +name: Code Contributor +aka: + - Community Developer +tags: +- community +- user-type +short-description: | + A person who develops and contributes code to the Kubernetes open source codebase. +long-description: | + They are also an active [community member](#term-community-member) who participates in one or more [Special Interest Groups (SIGs)](#term-sig). diff --git a/_data/glossary/container.yaml b/_data/glossary/container.yaml new file mode 100644 index 0000000000000..4cc786f7b3c4f --- /dev/null +++ b/_data/glossary/container.yaml @@ -0,0 +1,9 @@ +id: container +name: Container +tags: +- fundamental +- workload +short-description: | + A lightweight and portable executable image that contains software and all of its dependencies. +long-description: | + Containers decouple applications from underlying host infrastructure to make deployment easier in different cloud or OS environments, and for easier scaling. diff --git a/_data/glossary/contributor.yaml b/_data/glossary/contributor.yaml new file mode 100644 index 0000000000000..333244466db7b --- /dev/null +++ b/_data/glossary/contributor.yaml @@ -0,0 +1,8 @@ +id: contributor +name: Contributor +tags: +- community +short-description: | + Someone who donates code, documentation, or their time to help the Kubernetes project or community. +long-description: | + Contributions include pull requests (PRs), issues, feedback, [special interest group (SIG)](#term-sig) participation, or organizing community events. diff --git a/_data/glossary/cronjob.yaml b/_data/glossary/cronjob.yaml new file mode 100644 index 0000000000000..c220a38f751c8 --- /dev/null +++ b/_data/glossary/cronjob.yaml @@ -0,0 +1,9 @@ +id: cronjob +name: CronJob +tags: +- core-object +- workload +short-description: | + Manages a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) that runs on a periodic schedule. +long-description: | + Similar to a line in a *crontab* file, a [CronJob](/docs/concepts/workloads/controllers/cron-jobs/#writing-a-cron-job-spec) object specifies a schedule using the [Cron](https://en.wikipedia.org/wiki/Cron) format. diff --git a/_data/glossary/deployment.yaml b/_data/glossary/deployment.yaml new file mode 100644 index 0000000000000..773f2c1518c3f --- /dev/null +++ b/_data/glossary/deployment.yaml @@ -0,0 +1,10 @@ +id: deployment +name: Deployment +tags: +- fundamental +- core-object +- workload +short-description: | + An API object that manages a replicated application. +long-description: | + Each replica is represented by a [Pod](#term-pod), and the Pods are distributed among the nodes of a cluster. diff --git a/_data/glossary/developer.yaml b/_data/glossary/developer.yaml new file mode 100644 index 0000000000000..eb1a68526c8ac --- /dev/null +++ b/_data/glossary/developer.yaml @@ -0,0 +1,15 @@ +id: developer +name: Developer (disambiguation) +aka: + - Kubernetes Developer +tags: +- community +- user-type +short-description: | + May refer to: [*Application Developer*](#term-application-developer), [*Code Contributor*](#term-code-contributor), or [*Platform Developer*](#term-platform-developer). +long-description: | + This overloaded term may have different meanings depending on the context. It could mean: + + * [**Application Developer**](#term-application-developer): A person who writes an application that runs in a Kubernetes cluster. + * [**Code Contributor**](#term-code-contributor): A person who develops and contributes code to the Kubernetes open source codebase. + * [**Platform Developer**](#term-platform-developer): A person who customizes the Kubernetes platform to fit the needs of their project—for example, by extending the API. diff --git a/_data/glossary/downstream.yaml b/_data/glossary/downstream.yaml new file mode 100644 index 0000000000000..2abdd79fbcbf5 --- /dev/null +++ b/_data/glossary/downstream.yaml @@ -0,0 +1,11 @@ +id: downstream +name: Downstream (disambiguation) +related: +- upstream +tags: +- community +short-description: | + May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo. +long-description: | + * In the **Kubernetes Community**: Conversations often use *downstream* to mean the ecosystem, code, or third-party tools that rely on the core Kubernetes codebase. For example, a new feature in Kubernetes may be adopted by applications *downstream* to improve their functionality. + * In **GitHub** or **git**: The convention is to refer to a forked repo as *downstream*, whereas the source repo is considered *upstream*. diff --git a/_data/glossary/helm-chart.yaml b/_data/glossary/helm-chart.yaml new file mode 100644 index 0000000000000..9688a6f7160b2 --- /dev/null +++ b/_data/glossary/helm-chart.yaml @@ -0,0 +1,9 @@ +id: helm-chart +name: Helm Chart +tags: +- tool +short-description: | + A package of pre-configured Kubernetes resources that can be managed with the Helm tool. +long-description: | + Charts provide a reproducible way of creating and sharing Kubernetes applications. + A single chart can be used to deploy something simple, like a memcached Pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on. diff --git a/_data/glossary/ingress.yaml b/_data/glossary/ingress.yaml new file mode 100644 index 0000000000000..06864f8bcb598 --- /dev/null +++ b/_data/glossary/ingress.yaml @@ -0,0 +1,10 @@ +id: ingress +name: Ingress +tags: +- networking +- architecture +- extension +short-description: | + An API object that manages external access to the services in a cluster, typically HTTP. +long-description: | + Ingress can provide load balancing, SSL termination and name-based virtual hosting. diff --git a/_data/glossary/istio.yaml b/_data/glossary/istio.yaml new file mode 100644 index 0000000000000..81056cfac47b6 --- /dev/null +++ b/_data/glossary/istio.yaml @@ -0,0 +1,12 @@ +id: istio +name: Istio +tags: +- networking +- architecture +- extension +short-description: | + An open platform (not Kubernetes-specific) that provides a uniform way to integrate microservices, manage traffic flow, enforce policies, and aggregate telemetry data. +long-description: > + Adding Istio does not require changing application code. + It is a layer of infrastructure between a service and the network, which when combined with service deployments, is commonly referred to as a service mesh. + Istio's control plane abstracts away the underlying cluster management platform, which may be Kubernetes, Mesosphere, etc. diff --git a/_data/glossary/kops.yaml b/_data/glossary/kops.yaml new file mode 100644 index 0000000000000..b431e4061619d --- /dev/null +++ b/_data/glossary/kops.yaml @@ -0,0 +1,18 @@ +id: kops +name: Kops +tags: +- tool +- operation +short-description: | + A CLI tool that helps you create, destroy, upgrade and maintain production-grade, highly available, Kubernetes clusters. *NOTE: Officially supports AWS only, with GCE and VMware vSphere in alpha*. +long-description: | + `kops` provisions your cluster with: + + * Fully automated installation + * DNS-based cluster identification + * Self-healing: everything runs in Auto-Scaling Groups + * Limited OS support (Debian preferred, Ubuntu 16.04 supported, early support for CentOS & RHEL) + * High availability (HA) support + * The ability to directly provision, or generate terraform manifests + + You can also build your own cluster using [`kubeadm`](#term-kubeadm) as a building block. `kops` builds on the kubeadm work. diff --git a/_data/glossary/kubeadm.yaml b/_data/glossary/kubeadm.yaml new file mode 100644 index 0000000000000..ce2a6524d5007 --- /dev/null +++ b/_data/glossary/kubeadm.yaml @@ -0,0 +1,9 @@ +id: kubeadm +name: Kubeadm +tags: +- tool +- operation +short-description: | + A tool for quickly installing Kubernetes and setting up a secure cluster. +long-description: | + You can use kubeadm to install both the control plane and the worker node components. diff --git a/_data/glossary/kubectl.yaml b/_data/glossary/kubectl.yaml new file mode 100644 index 0000000000000..05711e8013280 --- /dev/null +++ b/_data/glossary/kubectl.yaml @@ -0,0 +1,9 @@ +id: kubectl +name: Kubectl +tags: +- tool +- fundamental +short-description: | + A command line tool for communicating with a [Kubernetes API](#term-kubernetes-api) server. +long-description: | + You can use kubectl to create, inspect, update, and delete Kubernetes objects. diff --git a/_data/glossary/kubernetes-api.yaml b/_data/glossary/kubernetes-api.yaml new file mode 100644 index 0000000000000..74169970bf4b7 --- /dev/null +++ b/_data/glossary/kubernetes-api.yaml @@ -0,0 +1,12 @@ +id: kubernetes-api +name: Kubernetes API +tags: +- fundamental +- architecture +short-description: | + The application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster. +long-description: > + Kubernetes resources and "records of intent" are all stored as API objects, and modified via RESTful calls to the API. + The API allows configuration to be managed in a declarative way. + Users can interact with the Kubernetes API directly, or via tools like `kubectl`. + The core Kubernetes API is flexible and can also be extended to support custom resources. diff --git a/_data/glossary/maintainer.yaml b/_data/glossary/maintainer.yaml new file mode 100644 index 0000000000000..fabfb6551c771 --- /dev/null +++ b/_data/glossary/maintainer.yaml @@ -0,0 +1,8 @@ +id: maintainer +name: Maintainer +tags: +- community +short-description: | + A highly experienced [contributor](#term-contributor), active in multiple areas of Kubernetes, who has cross-area ownership and write access to a project's GitHub repository. +long-description: | + Maintainers work holistically across the project to maintain its health and success and have made substantial contributions, both through code development and broader organizational efforts. diff --git a/_data/glossary/member.yaml b/_data/glossary/member.yaml new file mode 100644 index 0000000000000..3e4866625fa75 --- /dev/null +++ b/_data/glossary/member.yaml @@ -0,0 +1,10 @@ +id: member +name: Member +tags: +- community +short-description: | + A continuously active [contributor](#term-contributor) in the K8s community. +long-description: > + Members can have issues and PRs assigned to them and participate in [special interest groups (SIGs)](#term-sig) through GitHub teams. + Pre-submit tests are automatically run for members' PRs. + A member is expected to remain an active contributor to the community. diff --git a/_data/glossary/minikube.yaml b/_data/glossary/minikube.yaml new file mode 100644 index 0000000000000..eccbabadd9cb5 --- /dev/null +++ b/_data/glossary/minikube.yaml @@ -0,0 +1,9 @@ +id: minikube +name: Minikube +tags: +- fundamental +- tool +short-description: | + A tool for running Kubernetes locally. +long-description: | + Minikube runs a single-node cluster inside a VM on your computer. diff --git a/_data/glossary/platform-developer.yaml b/_data/glossary/platform-developer.yaml new file mode 100644 index 0000000000000..ef4352c98e76c --- /dev/null +++ b/_data/glossary/platform-developer.yaml @@ -0,0 +1,10 @@ +id: platform-developer +name: Platform Developer +aka: + - Kubernetes Developer +tags: + - user-type +short-description: | + A person who customizes the Kubernetes platform to fit the needs of their project. +long-description: > + A platform developer may, for example, use [Custom Resources](/docs/concepts/api-extension/custom-resources/) or [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) to add functionality to their instance of Kubernetes, specifically for their application. diff --git a/_data/glossary/pod.yaml b/_data/glossary/pod.yaml new file mode 100644 index 0000000000000..2a22384697fdf --- /dev/null +++ b/_data/glossary/pod.yaml @@ -0,0 +1,16 @@ +id: pod +name: Pod +related: +- container +- sidecar +- deployment +- statefulset +tags: +- core-object +- fundamental +short-description: | + The smallest and simplest Kubernetes object. A Pod represents a set of running [containers](#term-container) on your cluster. +long-description: > + 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 [Deployment](#term-deployment). diff --git a/_data/glossary/rbac.yaml b/_data/glossary/rbac.yaml new file mode 100644 index 0000000000000..af158dc54eaa7 --- /dev/null +++ b/_data/glossary/rbac.yaml @@ -0,0 +1,9 @@ +id: rbac +name: RBAC (Role-Based Access Control) +tags: +- security +- fundamental +short-description: | + Manages authorization decisions, allowing admins to dynamically configure access policies through the [Kubernetes API](#term-kubernetes-api). +long-description: | + RBAC utilizes *roles*, which contain permission rules, and *role bindings*, which grant the permissions defined in a role to a set of users. diff --git a/_data/glossary/reviewer.yaml b/_data/glossary/reviewer.yaml new file mode 100644 index 0000000000000..50b189d11788e --- /dev/null +++ b/_data/glossary/reviewer.yaml @@ -0,0 +1,8 @@ +id: reviewer +name: Reviewer +tags: +- community +short-description: | + A person who reviews code for quality and correctness on some part of the project. +long-description: | + Reviewers are knowledgeable about both the codebase and software engineering principles. Reviewer status is scoped to a part of the codebase. diff --git a/_data/glossary/service.yaml b/_data/glossary/service.yaml new file mode 100644 index 0000000000000..82f3998f6b690 --- /dev/null +++ b/_data/glossary/service.yaml @@ -0,0 +1,9 @@ +id: service +name: Service +tags: +- fundamental +- core-object +short-description: | + An API object that describes how to access applications, such as a set of [Pods](#term-pod), and can describe ports and load-balancers. +long-description: | + The access point can be internal or external to the cluster. diff --git a/_data/glossary/sig.yaml b/_data/glossary/sig.yaml new file mode 100644 index 0000000000000..bc365e677ff25 --- /dev/null +++ b/_data/glossary/sig.yaml @@ -0,0 +1,11 @@ +id: sig +name: SIG (special interest group) +tags: +- community +short-description: | + [Members](#term-member) who collectively manage an ongoing piece or aspect of the larger Kubernetes open source project. +long-description: > + Members within a SIG have a shared interest in advancing a specific area, such as architecture, API machinery, or documentation. + SIGs must follow the [SIG Governance](https://github.com/kubernetes/community/blob/master/sig-governance.md) guidelines but can have their own contribution policy and channels of communication. + + For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and Working Groups](https://github.com/kubernetes/community/blob/master/sig-list.md). diff --git a/_data/glossary/statefulset.yml b/_data/glossary/statefulset.yml index 3f052000120b1..c6bc43cb71665 100644 --- a/_data/glossary/statefulset.yml +++ b/_data/glossary/statefulset.yml @@ -1,18 +1,18 @@ id: statefulset name: StatefulSet -formerly: +aka: - PetSet related: -- Deployment -- Pod +- deployment +- pod tags: -- Storage -- Workload -- API Object +- core-object +- workload +- storage short-description: | - Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods. + Manages the deployment and scaling of a set of [Pods](#term-pod), *and provides guarantees about the ordering and uniqueness* of these Pods. long-description: | - Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling. + Like a [Deployment](#term-deployment), a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling. - StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state. + A StatefulSet operates under the same pattern as any other Controller. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to get there from the current state. diff --git a/_data/glossary/upstream.yaml b/_data/glossary/upstream.yaml new file mode 100644 index 0000000000000..70b3e4cef48a4 --- /dev/null +++ b/_data/glossary/upstream.yaml @@ -0,0 +1,11 @@ +id: upstream +name: Upstream (disambiguation) +related: +- downstream +tags: +- community +short-description: | + May refer to: core Kubernetes or the source repo from which a repo was forked. +long-description: | + * In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools relies upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool. + * In **GitHub** or **git**: The convention is to refer to a source repo as *upstream*, whereas the forked repo is considered *downstream*. diff --git a/_data/glossary/wg.yaml b/_data/glossary/wg.yaml new file mode 100644 index 0000000000000..5d7e5ee28e003 --- /dev/null +++ b/_data/glossary/wg.yaml @@ -0,0 +1,10 @@ +id: wg +name: WG (working group) +tags: +- community +short-description: | + Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, [SIG](#term-sig), or cross-SIG effort. +long-description: | + Working groups are a way of organizing people to accomplish a discrete task, and are relatively easy to create and deprecate when inactive. + + For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and working groups](https://github.com/kubernetes/community/blob/master/sig-list.md). diff --git a/_data/reference.yml b/_data/reference.yml index 28e2d81f0383f..48abc0b2d68f0 100644 --- a/_data/reference.yml +++ b/_data/reference.yml @@ -2,6 +2,7 @@ bigheader: "Reference Documentation" abstract: "Design docs, concept definitions, and references for APIs and CLIs." toc: - docs/reference/index.md +- docs/reference/glossary.md - title: Using the API section: @@ -108,5 +109,3 @@ toc: - title: Kubernetes Issue Tracker on GitHub path: https://github.com/kubernetes/kubernetes/issues/ - docs/reference/security.md - - diff --git a/_data/tasks.yml b/_data/tasks.yml index fdd2a2901fa75..4820d91855278 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -148,6 +148,7 @@ toc: - docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md - docs/tasks/administer-cluster/declare-network-policy.md - docs/tasks/administer-cluster/reconfigure-kubelet.md + - docs/tasks/administer-cluster/kubelet-config-file.md - title: Install Network Policy Provider section: - docs/tasks/administer-cluster/calico-network-policy.md diff --git a/_includes/templates/glossary/README.md b/_includes/templates/glossary/README.md index 9d3d49d48eaf7..453c23fdc70a1 100644 --- a/_includes/templates/glossary/README.md +++ b/_includes/templates/glossary/README.md @@ -2,17 +2,19 @@ To write a glossary snippet, start with a copy of the template, [`/_data/glossary/_example.yml`](/_data/glossary/_example.yml). Make sure to provide (or omit) values for the following fields: -* (Required) `id`. +* (Required) `id` * This field must match the name of the glossary file itself (without the `*.yml` extension). It is *not* intended to be displayed to users, and is only used programmatically. -* (Required) `name`. +* (Required) `name` * The name of the term. -* (Required) `tags`. +* (Required) `tags` * Must be one of the tags listed in kubernetes.github.io/_data/canonical-terms-tags.yml. -* (Required) `short description`. +* (Required) `short description` * Make sure to replace the instructional text in the template with your content. -* (Optional) `formerly` and `related`. - * If you do not provide these values, remove the fields. -* (Optional) `long description`. +* (Optional) `aka` + * These synonyms do not need to be glossary terms themselves (if they are deprecated), and can include spaces. +* (Optional) `related` + * These should be the `id`s (not the `names`) of related glossary terms. +* (Optional) `long description` * If you do not provide a long description, remove the field -- that is, the complete key-value pair. The `_example.yml` template also contains basic information about how to write your snippet. For additional guidance, continue reading this readme. diff --git a/_layouts/docwithnav.html b/_layouts/docwithnav.html index b57af76f749c8..f10f958bece6b 100755 --- a/_layouts/docwithnav.html +++ b/_layouts/docwithnav.html @@ -67,7 +67,9 @@

{{ page.title }}

Create an Issue - Edit this Page + {% unless page.noedit %} + Edit this Page + {% endunless %} {% endif %} diff --git a/_sass/_base.sass b/_sass/_base.sass index f4bf45b15b27a..f28cda57fc410 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -379,12 +379,12 @@ ul.global-nav width: 100% background-color: transparentize(white, 0.9) content: '' - + &.no-sub - + h5 display: none - + h1 margin-bottom: 20px @@ -478,12 +478,12 @@ footer display: block height: 0 overflow: hidden - + &.button background-image: none width: auto height: auto - + &:hover color: $blue @@ -572,7 +572,7 @@ section height: 44px line-height: 44px position: relative - + &:before position: absolute width: 15px @@ -829,7 +829,7 @@ dd h1,h2 border-bottom: 1px solid #cccccc - + h1 font-size: 32px padding-right: 60px @@ -1009,7 +1009,7 @@ dd a.button border-radius: 2px text-decoration: none - + &:visited color: white @@ -1128,7 +1128,7 @@ $feature-box-div-margin-bottom: 40px #video width: 100% position: relative - background-image: url(/images/kub_video_banner.jpg) + background-image: url(/images/kub_video_banner_box.jpg) background-position: center center background-size: cover @@ -1153,6 +1153,14 @@ $feature-box-div-margin-bottom: 40px p margin-bottom: 20px + #desktopKCButton + position: relative + font-size: 18px + background-color: $dark-grey + border-radius: 8px + color: $white + padding: 10px 20px 10px 20px + #desktopShowVideoButton position: relative font-size: 24px @@ -1335,7 +1343,7 @@ $feature-box-div-margin-bottom: 40px height: 30vw max-width: 1200px max-height: 450px - margin: 20px auto + margin: 20px auto iframe position: absolute @@ -1417,7 +1425,7 @@ $feature-box-div-margin-bottom: 40px h1,h2 border-bottom: 1px solid #cccccc - + h1 font-size: 32px padding-right: 60px @@ -1597,7 +1605,7 @@ $feature-box-div-margin-bottom: 40px a.button border-radius: 2px text-decoration: none - + &:visited color: white @@ -1699,7 +1707,7 @@ $feature-box-div-margin-bottom: 40px #talkToUs main padding: 30px 0 - + h5 font-size: 20px @@ -1708,7 +1716,7 @@ $feature-box-div-margin-bottom: 40px position: relative text-align: center margin-bottom: 30px - + div position: relative display: inline-block @@ -1731,10 +1739,10 @@ $feature-box-div-margin-bottom: 40px div:nth-child(4) background-image: url(/images/community_logos/wikimedia_foundation_logo.png) - + p font-size: 20px - + a position: absolute bottom: 0 @@ -1743,16 +1751,16 @@ $feature-box-div-margin-bottom: 40px color: $blue font-weight: 400 - + //#bigSocial // text-align: center - // + // // div // display: inline-block // float: none // padding-top: 125px // width: calc(90%) - // + // // a // margin-top: 15px // font-size: 18px diff --git a/_sass/_desktop.sass b/_sass/_desktop.sass index d565191d0283e..48a83596e366a 100644 --- a/_sass/_desktop.sass +++ b/_sass/_desktop.sass @@ -97,7 +97,7 @@ $video-section-height: 550px section, header, footer main max-width: $main-max-width - + header, #vendorStrip, #encyclopedia, #hero h1, #hero h5, #docs #hero h1, #docs #hero h5, #community #hero h1, .gridPage #hero h1, #community #hero h5, .gridPage #hero h5 padding-left: 100px @@ -138,7 +138,7 @@ $video-section-height: 550px #video height: $video-section-height position: relative - background-image: url(../images/kub_video_banner.jpg) + background-image: url(../images/kub_video_banner_box.jpg) background-position: center center background-size: cover @@ -299,7 +299,7 @@ $video-section-height: 550px width: auto background-color: $blue padding: 0 20px - + diff --git a/cn/docs/admin/service-accounts-admin.md b/cn/docs/admin/service-accounts-admin.md index c118edf9d4672..bf3e0783f908b 100644 --- a/cn/docs/admin/service-accounts-admin.md +++ b/cn/docs/admin/service-accounts-admin.md @@ -9,7 +9,7 @@ title: 管理Service Accounts *这是一篇针对service accounts（服务账户）的集群管理员指南。 它呈现了 [User Guide to Service Accounts](/docs/user-guide/service-accounts)中的信息。* -*对授权和用户账户的支持是计划实现的，但当前并不完备，为了更好地描述service accounts，有时这些不完善的特性也会被提及。* +*对授权和用户账户的支持已在规划中，当前并不完备，为了更好地描述service accounts，有时这些不完善的特性也会被提及。* ## 用户账户与服务账户 diff --git a/community/index.html b/community/index.html index 3e35fb7f84fa1..6ade8ae9ddfdc 100644 --- a/community/index.html +++ b/community/index.html @@ -7,7 +7,7 @@

Community

- +KubeConNA
@@ -20,7 +20,7 @@

Ensuring Kubernetes works well everywhere and for everyone.

You can also join Kubernetes all around the world through our Kubernetes Meetup Community and the Kubernetes Cloud Native Meetup Community.

-
+

Special Interest Groups (SIGs)

Have a special interest in how Kubernetes works with another technology? See our ever growing diff --git a/css/glossary.css b/css/glossary.css new file mode 100644 index 0000000000000..67d536ccf9fb6 --- /dev/null +++ b/css/glossary.css @@ -0,0 +1,64 @@ +.preview-text p { + display: inline; +} + +.no-underline { + text-decoration: none !important; +} + +.hide { + display: none !important; +} + +.permalink { + background-image: url(../images/link.png); + background-repeat: no-repeat; + display: inline-block; + color: transparent; + width: 20px; + margin-left: 10px; +} + +.term-anchor { + display: block; + position: relative; + top: -90px; + visibility: hidden; +} + +.tag-option { + padding: 5px; + margin: 10px; + float:left; +} + +.canonical-tag { + color: white; + background-color: #b7c8e8; +} + +.canonical-tag a { + color: inherit; + text-decoration: none !important; +} + +.active-tag { + background-color: #3371e3; +} + +.invisible { + visibility: hidden; +} + +#tag-container { + float: left; + border-top: 1px solid #8c8c8c; + border-bottom: 1px solid #8c8c8c; + padding: 7px 0px; + margin: 25px 0px; +} + +.tag-description { + text-align: center; + margin: 5px 0px; +} diff --git a/docs/concepts/configuration/overview.md b/docs/concepts/configuration/overview.md index 59c86d358fdcf..67eb2d45e5efd 100644 --- a/docs/concepts/configuration/overview.md +++ b/docs/concepts/configuration/overview.md @@ -62,9 +62,9 @@ This is a living document. If you think of something that is not on this list bu A service can be made to span multiple deployments, such as is done across [rolling updates](/docs/tasks/run-application/rolling-update-replication-controller/), by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully. -- To facilitate rolling updates, include version info in replication controller names, for example as a suffix to the name. It is useful to set a 'version' label as well. The rolling update creates a new controller as opposed to modifying the existing controller. So, there will be issues with version-agnostic controller names. See the [documentation](/docs/tasks/run-application/rolling-update-replication-controller/) on the rolling-update command for more detail. +- To facilitate rolling updates, include version info in replication controller names, for example as a suffix to the name. It is useful to set a `version` label as well. The rolling update creates a new controller as opposed to modifying the existing controller. So, there will be issues with version-agnostic controller names. See the [documentation](/docs/tasks/run-application/rolling-update-replication-controller/) on the rolling-update command for more detail. - Note that the [Deployment](/docs/concepts/workloads/controllers/deployment/) object obviates the need to manage replication controller 'version names'. A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. (Deployment objects are currently part of the [`extensions` API Group](/docs/concepts/overview/kubernetes-api/#api-groups).) + Note that the [Deployment](/docs/concepts/workloads/controllers/deployment/) object obviates the need to manage replication controller `version names`. A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. (Deployment objects are currently part of the [`extensions` API Group](/docs/concepts/overview/kubernetes-api/#api-groups).) - You can manipulate labels for debugging. Because Kubernetes replication controllers and services match to pods using labels, this allows you to remove a pod from being considered by a controller, or served traffic by a service, by removing the relevant selector labels. If you remove the labels of an existing pod, its controller will create a new pod to take its place. This is a useful way to debug a previously "live" pod in a quarantine environment. See the [`kubectl label`](/docs/concepts/overview/working-with-objects/labels/) command. diff --git a/docs/concepts/configuration/secret.md b/docs/concepts/configuration/secret.md index e0eb74301a151..9059b2d74f3b3 100644 --- a/docs/concepts/configuration/secret.md +++ b/docs/concepts/configuration/secret.md @@ -343,7 +343,7 @@ projected to the pod can be as long as kubelet sync period + ttl of secrets cach To use a secret in an environment variable in a pod: 1. Create a secret or use an existing one. Multiple pods can reference the same secret. -1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[x].valueFrom.secretKeyRef`. +1. Modify your Pod definition in each container that you wish to consume the value of a secret key to add an environment variable for each secret key you wish to consume. The environment variable that consumes the secret key should populate the secret's name and key in `env[].valueFrom.secretKeyRef`. 1. Modify your image and/or command line so that the program looks for values in the specified environment variables This is an example of a pod that uses secrets from environment variables: diff --git a/docs/concepts/configuration/taint-and-toleration.md b/docs/concepts/configuration/taint-and-toleration.md index f5bd4d1b3dec7..463ab28b3366c 100644 --- a/docs/concepts/configuration/taint-and-toleration.md +++ b/docs/concepts/configuration/taint-and-toleration.md @@ -259,7 +259,8 @@ which matches the behavior when this feature is disabled. ## Taint Nodes by Condition Version 1.8 introduces an alpha feature that causes the node controller to create taints corresponding to -Node conditions. When this feature is enabled, the scheduler does not check conditions; instead the scheduler checks taints. This assures that conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as conditions) by adding appropriate Pod tolerations. +Node conditions. When this feature is enabled (you can do this by including `TaintNodesByCondition=true` in the `--feature-gates` command line flag to the scheduler, such as +`--feature-gates=FooBar=true,TaintNodesByCondition=true`), the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations. To make sure that turning on this feature doesn't break DaemonSets, starting in version 1.8, the DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons: diff --git a/docs/concepts/services-networking/dns-pod-service.md b/docs/concepts/services-networking/dns-pod-service.md index 42e38447c1e53..92e942292e88e 100644 --- a/docs/concepts/services-networking/dns-pod-service.md +++ b/docs/concepts/services-networking/dns-pod-service.md @@ -343,6 +343,7 @@ kubectl get ep kube-dns --namespace=kube-system ``` You should see something like: + ``` NAME ENDPOINTS AGE kube-dns 10.180.3.17:53,10.180.3.17:53 1h diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md index 257f14180403a..ab45e0c5cbac8 100644 --- a/docs/concepts/storage/persistent-volumes.md +++ b/docs/concepts/storage/persistent-volumes.md @@ -139,7 +139,7 @@ allowVolumeExpansion: true Once both feature gate and aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim` by simply editing the claim and requesting bigger size. This in turn will trigger expansion of volume that is backing underlying `PersistentVolume`. -Under no circustances a new `PersistentVolume` gets created to satisfy the claim. Kubernetes will attempt to resize existing volume to satisfy the claim. +Under no circumstances a new `PersistentVolume` gets created to satisfy the claim. Kubernetes will attempt to resize existing volume to satisfy the claim. ## Types of Persistent Volumes diff --git a/docs/concepts/workloads/controllers/daemonset.md b/docs/concepts/workloads/controllers/daemonset.md index ee4cf4d4097e1..04310af23cb2f 100644 --- a/docs/concepts/workloads/controllers/daemonset.md +++ b/docs/concepts/workloads/controllers/daemonset.md @@ -110,7 +110,7 @@ when the Pod is created, so it is ignored by the scheduler). Therefore: - The DaemonSet controller can make Pods even when the scheduler has not been started, which can help cluster bootstrap. -Daemon Pods do respect [taints and tolerations](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature), +Daemon Pods do respect [taints and tolerations](/docs/concepts/configuration/taint-and-toleration), but they are created with `NoExecute` tolerations for the following taints with no `tolerationSeconds`: - `node.kubernetes.io/not-ready` diff --git a/docs/getting-started-guides/kubespray.md b/docs/getting-started-guides/kubespray.md index ef4b9d7175604..b1860e939c323 100644 --- a/docs/getting-started-guides/kubespray.md +++ b/docs/getting-started-guides/kubespray.md @@ -84,7 +84,7 @@ Kubespray provides additional playbooks to manage your cluster: _scale_ and _upg ### Scale your cluster -You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#Adding-nodes)". +You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#adding-nodes)". ### Upgrade your cluster diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md index f40c41ad707e2..08d92cbeb0579 100644 --- a/docs/getting-started-guides/mesos/index.md +++ b/docs/getting-started-guides/mesos/index.md @@ -304,6 +304,7 @@ Address 1: 10.10.10.10 Name: kubernetes Address 1: 10.10.10.1 ``` + ## Support Level diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md new file mode 100644 index 0000000000000..ceb1dc4dd35bc --- /dev/null +++ b/docs/reference/glossary.md @@ -0,0 +1,66 @@ +--- +approvers: +- chenopis +- abiogenesis-now +title: Standardized Glossary +noedit: true +default_active_tag: fundamental +--- + + + +

This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to K8s, as well as more general terms that provide useful context.

+ +
+

Filter terms according to their tags:

+ +{% for tag in site.data.canonical-tags %} +{% assign tag_info = tag[1] %} +
+{{ tag_info.description }} +
+{% endfor %} + +{% assign sorted_tags = site.data.canonical-tags | where_exp: "tag", "true" | sort: 'name' %} +{% for tag_info in sorted_tags %} + +{% assign tag_state_class = "" %} + +{% assign fullTagName = tag_info.id | prepend: "tag-" %} + +{{ tag_info.name }} + +{% endfor %} +Select all +Deselect all +
+ +

Click on the [+] indicators below to get a longer explanation for any particular term.

+ +{% assign glossary_terms = site.data.glossary | where_exp: "term", "term.id != '_example'" | sort: 'name' %} + +
    +{% for term in glossary_terms %} + +{% assign tag_classes = term.tags | join: " tag-" | prepend: "tag-" %} + +{% assign term_visibility_class = "hide" %} +{% assign show_count = 0 %} +{% assign term_identifier = term.id | prepend: 'term-' %} + +
  • +
    +
    +
    {{ term.name }}
    +{% if term.aka %} +Also known as: {{ term.aka | join: ", " }} +
    +{% endif %} +{{ term.short-description | markdownify }} [+] +
    +{{ term.long-description | markdownify }} +
    +
    +
    • +{% endfor %} +
diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index 7ead869bdec80..8a67b6603b698 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -229,7 +229,7 @@ The official Calico guide is [here](http://docs.projectcalico.org/latest/getting - Calico works on `amd64` only. ```shell -kubectl apply -f http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml +kubectl apply -f https://docs.projectcalico.org/v2.6/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml ``` {% endcapture %} diff --git a/docs/tasks/administer-cluster/kubelet-config-file.md b/docs/tasks/administer-cluster/kubelet-config-file.md new file mode 100644 index 0000000000000..5deadb631506c --- /dev/null +++ b/docs/tasks/administer-cluster/kubelet-config-file.md @@ -0,0 +1,70 @@ +--- +approvers: +- mtaufen +- dawnchen +title: Set Kubelet parameters via a config file +--- + +{% capture overview %} +{% include feature-state-alpha.md %} + +As of Kubernetes 1.8, a subset of the Kubelet's configuration parameters may be +set via an on-disk config file, as a substitute for command-line flags. In the +future, most of the existing command-line flags will be deprecated in favor of +providing parameters via a config file, which simplifies node deployment. + +{% endcapture %} + +{% capture prerequisites %} + +- A v1.8 or higher Kubelet binary must be installed. + +{% endcapture %} + +{% capture steps %} + +## Create the config file + +The subset of the Kubelet's configuration that can be configured via a file +is defined by the `KubeletConfiguration` struct +[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go). +The configuration file must be a JSON or YAML representation of the parameters +in this struct. Note that this structure, and thus the config file API, +is still considered alpha and is not subject to stability gurarantees. + +Create a file named `kubelet` in its own directory and make sure the directory +and file are both readable by the Kubelet. You should write your intended +Kubelet configuration in this `kubelet` file. + +For a trick to generate a configuration file from a live node, see +[Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet). + +## Start a Kubelet process configured via the config file + +Start the Kubelet with the `KubeletConfigFile` feature gate enabled and the +Kubelet's `--init-config-dir` flag set to the location of the directory +containing the `kubelet` file. The Kubelet will then load the parameters defined +by `KubeletConfiguration` from the `kubelet` file, rather than from their +associated command-line flags. + +{% endcapture %} + +{% capture discussion %} + +## Relationship to Dynamic Kubelet Config + +If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-cluster/reconfigure-kubelet) +feature, the configuration provided via `--init-config-dir` will be considered +the "last known good" configuration by the automatic rollback mechanism. + +Note that the layout of the files in the `--init-config-dir` mirrors the layout +of data in the ConfigMaps used for Dynamic Kubelet Config; the file names are +the same as the keys of the ConfigMap, and the file contents are JSON or YAML +representations of the same structures. Today, the only pair is +`kubelet:KubeletConfiguration`, though more may emerge in the future. +See [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet) +for more information. + +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/reconfigure-kubelet.md b/docs/tasks/administer-cluster/reconfigure-kubelet.md index 550898f7d523f..f47ff8813425b 100644 --- a/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -89,12 +89,13 @@ and debug issues. The compromise, however, is that you must start with knowledge of the existing configuration to ensure that you only change the fields you intend to change. -In the future, the Kubelet will be bootstrapped from a file on disk, and you -will simply edit a copy of this file (which, as a best practice, should live in -version control) while creating the first Kubelet ConfigMap. Today, however, the -Kubelet is still bootstrapped with command-line flags. Fortunately, there is a -dirty trick you can use to generate a config file containing a Node's current -configuration. The trick involves hitting the Kubelet server's `configz` +In the future, the Kubelet will be bootstrapped from a file on disk +(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)), +and you will simply edit a copy of this file (which, as a best practice, should +live in version control) while creating the first Kubelet ConfigMap. Today, +however, the Kubelet is still bootstrapped with command-line flags. Fortunately, +there is a dirty trick you can use to generate a config file containing a Node's +current configuration. The trick involves hitting the Kubelet server's `configz` endpoint via the kubectl proxy. This endpoint, in its current implementation, is intended to be used only as a debugging aid, which is part of why this is a dirty trick. There is ongoing work to improve the endpoint, and in the future diff --git a/docs/tasks/administer-cluster/static-pod.md b/docs/tasks/administer-cluster/static-pod.md index 208ddad2c8ba2..8d91fc800757e 100644 --- a/docs/tasks/administer-cluster/static-pod.md +++ b/docs/tasks/administer-cluster/static-pod.md @@ -64,7 +64,7 @@ For example, this is how to start a simple web server as a static pod: [root@my-node1 ~] $ systemctl restart kubelet ``` -## Pods created via HTTP +### Pods created via HTTP Kubelet periodically downloads a file specified by `--manifest-url=` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below). diff --git a/docs/tasks/job/fine-parallel-processing-work-queue/index.md b/docs/tasks/job/fine-parallel-processing-work-queue/index.md index 9d19895039b58..8384b7e337471 100644 --- a/docs/tasks/job/fine-parallel-processing-work-queue/index.md +++ b/docs/tasks/job/fine-parallel-processing-work-queue/index.md @@ -5,14 +5,14 @@ title: Fine Parallel Processing Using a Work Queue * TOC {:toc} -# Example: Job with Work Queue with Pod Per Work Item +# Example: Job with Work Queue with Multiple Work Items Per Pod In this example, we will run a Kubernetes Job with multiple parallel worker processes. You may want to be familiar with the basic, non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) first. In this example, as each pod is created, it picks up one unit of work -from a task queue, completes it, deletes it from the queue, and exits. +from a task queue, processes it, and repeats until the end of the queue is reached. Here is an overview of the steps in this example: diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md index bacf7344ae466..03e391dd49c8c 100644 --- a/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/docs/tasks/run-application/rolling-update-replication-controller.md @@ -16,7 +16,7 @@ which in turn uses a For more information, see [Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). -To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/{{page.version}}/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information. +To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information. Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers, consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 6a0789ee8c911..cc95dc5dc1d4a 100644 --- a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -12,6 +12,9 @@ A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece **Warning:** This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. {: .warning} +**Note:** The files provided in this tutorial are using beta Deployment APIs and are specific to kubernetes version 1.8. If you wish to use this tutorial with an earlier version of Kubernetes, please update the beta API appropriately, or reference earlier versions of this tutorial. +{: .note} + {% endcapture %} {% capture objectives %} diff --git a/docs/tutorials/stateless-application/guestbook.md b/docs/tutorials/stateless-application/guestbook.md index ec394ecb72b95..81f5b48fb7018 100644 --- a/docs/tutorials/stateless-application/guestbook.md +++ b/docs/tutorials/stateless-application/guestbook.md @@ -292,7 +292,7 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels {% capture whatsnext %} * Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials -* Use Kubernetes to create a blog using [Persistant Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) +* Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) * Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/) * Read more about [Managing Resources](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) {% endcapture %} diff --git a/docs/user-guide/kubectl-conventions.md b/docs/user-guide/kubectl-conventions.md index e8b9a7ba3884d..faed88a078056 100644 --- a/docs/user-guide/kubectl-conventions.md +++ b/docs/user-guide/kubectl-conventions.md @@ -45,7 +45,7 @@ Additionally, if you didn't specify a generator flag, other flags will suggest u a specific generator. Below table shows which flags force using specific generators, depending on your cluster version: -| Generated Resource | Cluster v1.4 and later | Cluster v1.3 | Cluster v1.2 | Cluster v1.1 and eariler | +| Generated Resource | Cluster v1.4 and later | Cluster v1.3 | Cluster v1.2 | Cluster v1.1 and earlier | |:----------------------:|------------------------|-----------------------|--------------------------------------------|--------------------------------------------| | Pod | `--restart=Never` | `--restart=Never` | `--generator=run-pod/v1` | `--restart=OnFailure` OR `--restart=Never` | | Replication Controller | `--generator=run/v1` | `--generator=run/v1` | `--generator=run/v1` | `--restart=Always` | diff --git a/images/KubeCon_NA_Community.png b/images/KubeCon_NA_Community.png new file mode 100644 index 0000000000000..31f1667c00c0b Binary files /dev/null and b/images/KubeCon_NA_Community.png differ diff --git a/images/kub_video_banner_box.jpg b/images/kub_video_banner_box.jpg new file mode 100644 index 0000000000000..bdc024a1e3f62 Binary files /dev/null and b/images/kub_video_banner_box.jpg differ diff --git a/images/link.png b/images/link.png new file mode 100644 index 0000000000000..048e2dd88dab9 Binary files /dev/null and b/images/link.png differ diff --git a/index.html b/index.html index 12c614aec5c04..bdf7912590948 100644 --- a/index.html +++ b/index.html @@ -60,8 +60,11 @@

Run Anywhere

Kubernetes: Finally… A True Cloud Platform

-

Sam Ghods, Co-Founder and Services Architect at Box, gives a passionate talk showing that with Kubernetes, we have for first time a universal interface that one can build real deployment tooling against.

+

Sam Ghods, Co-Founder and Services Architect at Box, gives a passionate talk last year at KubeCon Seattle showing that with Kubernetes, we have for first time a universal interface that one can build real deployment tooling against.

+
+
+ Attend KubeCon This Year
diff --git a/js/glossary.js b/js/glossary.js new file mode 100644 index 0000000000000..b6e8a73221c30 --- /dev/null +++ b/js/glossary.js @@ -0,0 +1,181 @@ +// TODO (long-term): Would be easier to manage all this state with React + +$( document ).ready(function() { + var expandText = "[+]"; + var closeText = "[-]"; + var selectAllKey = "all"; + var deselectAllKey = "none"; + + var defaultActiveTag = "fundamental"; + var activeTags = {}; + + var paramSize = function(paramHash) { + return Object.keys(paramHash).length; + } + + // "Lib" for acquiring parameters from the URL + var urlParamLib = function() { + function initParams() { + var sPageURL = decodeURIComponent(window.location.search.substring(1)), + sURLVariables = sPageURL.split('&'), + sParameterName, + i; + + var paramHash = {}; + for (i = 0; i < sURLVariables.length; i++) { + sParameterName = sURLVariables[i].split('='); + if (sParameterName[0] != "") + paramHash[sParameterName[0]] = sParameterName[1]; + } + + if (paramSize(paramHash) == 0) { + paramHash[defaultActiveTag] = true; + } + + return paramHash; + } + + function updateParams(paramHash) { + var urlWithoutQuery = window.location.href.split('?')[0]; + var urlHash = window.location.hash; + window.history.pushState(null,null, urlWithoutQuery + "?" + $.param(paramHash) + window.location.hash); + } + + return { + initParams: initParams, + updateParams: updateParams, + }; + }(); + + var initClickFunctions = function() { + + var deactivateTagTerms = function(elt) { + var targetTag = elt.data("target"); + var targetClass = "." + targetTag; + var tagName = targetTag.split('tag-')[1]; + + elt.removeClass("active-tag"); + $(targetClass).each(function(){ + var showCount = $(this).data("show-count"); + var newShowCount = showCount - 1; + $(this).data("show-count", newShowCount); + if (newShowCount < 1) { + $(this).addClass("hide"); + } + }); + delete activeTags[tagName]; + }; + + var activateTagTerms = function(elt) { + var targetTag = elt.data("target"); + var targetClass = "." + targetTag; + var tagName = targetTag.split('tag-')[1]; + + elt.addClass("active-tag"); + $(targetClass).each(function(){ + var showCount = $(this).data("show-count"); + var newShowCount = showCount + 1; + $(this).data("show-count", newShowCount); + if (newShowCount > 0) { + $(this).removeClass("hide"); + } + }); + activeTags[tagName] = true; + if (activeTags[deselectAllKey]) { + delete activeTags[deselectAllKey]; + } + }; + + // Shows/hides glossary terms when their relevant tags are clicked + $(".canonical-tag").each(function(){ + var placeholder = $("#placeholder"); + var targetTag = $(this).data("target"); + $(this).mouseenter(function(){ + var tagDescription = $("#" + targetTag + "-description").html(); + placeholder.html(tagDescription); + placeholder.removeClass('invisible'); + }).mouseleave(function(){ + placeholder.addClass('invisible'); + }); + + $(this).click(function(){ + var shouldHide = $(this).hasClass("active-tag"); + if (shouldHide) { + deactivateTagTerms($(this)); + } else { + activateTagTerms($(this)); + } + urlParamLib.updateParams(activeTags); + }); + }); + + // Adds functionality to "select all tags" link + $("#select-all-tags").click(function(){ + $(".canonical-tag").each(function(){ + var shouldActivate = !$(this).hasClass("active-tag"); + if (shouldActivate) { + activateTagTerms($(this)); + } + }); + queryParams = {} + queryParams[selectAllKey] = true; + urlParamLib.updateParams(queryParams); + }); + + // Adds functionality to "deselect all tags" link + $("#deselect-all-tags").click(function(){ + $(".canonical-tag").each(function(){ + var shouldHide = $(this).hasClass("active-tag"); + if (shouldHide) { + deactivateTagTerms($(this)); + } + }); + queryParams = {} + queryParams[deselectAllKey] = true; + urlParamLib.updateParams(queryParams); + }); + + // Expands/hides glossary term definitions when [+] button is clicked + $(".click-controller").each(function(){ + $(this).click(function() { + var targetId = $(this).data("target"); + var shouldExpand = $(this).html() == expandText; + + if (shouldExpand) { + $("#" + targetId).removeClass('hide'); + $(this).html(closeText); + } else { + $("#" + targetId).addClass('hide'); + $(this).html(expandText); + } + }); + }); + + // Shows permalink when term name is hovered over + $(".term-name").each(function() { + var permalink = $($(this).parent().find(".permalink")[0]); + $(this).mouseenter(function(){ + permalink.removeClass("hide"); + }).mouseleave(function(){ + permalink.addClass("hide"); + });; + }); + }; + + function initActiveTags() { + if (activeTags[selectAllKey]) { + $("#select-all-tags").click(); + } else if (activeTags[deselectAllKey]) { + $("#deselect-all-tags").click(); + } else { + for (var tagId in activeTags) { + $("#tag-" + tagId).find("a")[0].click(); + } + } + } + + initClickFunctions(); + activeTags = urlParamLib.initParams(); + initActiveTags(); + +}); diff --git a/test/glossary_test.go b/test/glossary_test.go index df51025278ed6..dc8984a295394 100644 --- a/test/glossary_test.go +++ b/test/glossary_test.go @@ -29,41 +29,53 @@ import ( type GlossaryTerm struct { Id string `yaml: "id"` Name string `yaml: "name"` - Formerly []string `yaml: "formerly"` + Aka []string `yaml: "aka"` Related []string `yaml: "related"` Tags []string `yaml: "tags"` } +// Not unmarshaling other fields (for simplicity) +type CanonicalTag struct { + Id string `yaml: "id"` +} + // Checks that all glossary files (../_data/glossary/*) contain valid tags // that are present in the canonical set. func TestCanonicalTags(t *testing.T) { - canonicalTagsFile := "../_data/canonical-tags.yml" - data, err := ioutil.ReadFile(canonicalTagsFile) + canonicalTagsDir := "../_data/canonical-tags" + files, err := ioutil.ReadDir(canonicalTagsDir) if err != nil { - t.Errorf("Unable to read file %s: %v", canonicalTagsFile, err) - return - } - var tagList []string - err = yaml.Unmarshal(data, &tagList) - if err != nil { - t.Errorf("Unable to unmarshal file %s: %v", tagList, err) + t.Errorf("Unable to read directory %s: %v", canonicalTagsDir, err) return } canonicalTagsSet := make(map[string]bool) - for _, tag := range tagList { - canonicalTagsSet[tag] = true + var tag CanonicalTag + for _, f := range files { + filePath := path.Join(canonicalTagsDir, f.Name()) + data, err := ioutil.ReadFile(filePath) + if err != nil { + t.Errorf("Unable to read file %s: %v", filePath, err) + continue + } + err = yaml.Unmarshal(data, &tag) + if err != nil { + t.Errorf("Unable to unmarshal file %s: %v", filePath, err) + continue + } + + canonicalTagsSet[tag.Id] = true } glossaryDir := "../_data/glossary" - files, err := ioutil.ReadDir(glossaryDir) + files, err = ioutil.ReadDir(glossaryDir) if err != nil { t.Errorf("Unable to read directory %s: %v", glossaryDir, err) return } - var term GlossaryTerm for _, f := range files { + var term GlossaryTerm // skip validation of example files if (strings.HasPrefix(f.Name(), "_")) { continue @@ -81,9 +93,12 @@ func TestCanonicalTags(t *testing.T) { continue } + if (len(term.Tags) == 0) { + t.Errorf("Glossary term \"%s\" requires at least one tag. See %s for the list of valid tags.", term.Name, canonicalTagsDir) + } for _, tag := range term.Tags { if _, present := canonicalTagsSet[tag]; !present { - t.Errorf("Glossary term \"%s\" has invalid tag \"%s\". See %s for the list of valid tags.", term.Name, tag, canonicalTagsFile) + t.Errorf("Glossary term \"%s\" has invalid tag \"%s\". See %s for the list of valid tags.", term.Name, tag, canonicalTagsDir) continue } }