diff --git a/README.md b/README.md index dbac6f22b9..280a4ceb40 100644 --- a/README.md +++ b/README.md @@ -9,6 +9,7 @@ For more information about contributing to the Kubernetes documentation, see: * [Contributing to the Kubernetes Documentation](http://kubernetes.io/editdocs/) * [Creating a Documentation Pull Request](http://kubernetes.io/docs/home/contribute/create-pull-request/) * [Writing a New Topic](http://kubernetes.io/docs/home/contribute/write-new-topic/) +* [Review Issues](http://kubernetes.io/docs/home/contribute/review-issues/) * [Staging Your Documentation Changes](http://kubernetes.io/docs/home/contribute/stage-documentation-changes/) * [Using Page Templates](http://kubernetes.io/docs/home/contribute/page-templates/) * [Documentation Style Guide](http://kubernetes.io/docs/home/contribute/style-guide/) diff --git a/_data/setup.yml b/_data/setup.yml index 576fe257c0..86d591f46d 100644 --- a/_data/setup.yml +++ b/_data/setup.yml @@ -94,7 +94,6 @@ toc: - docs/getting-started-guides/ubuntu/glossary.md - docs/getting-started-guides/ubuntu/local.md - docs/getting-started-guides/ubuntu/logging.md - - docs/getting-started-guides/ubuntu/manual.md - docs/getting-started-guides/windows/index.md diff --git a/_includes/partner-script.js b/_includes/partner-script.js index cb991e19d1..c77537e522 100644 --- a/_includes/partner-script.js +++ b/_includes/partner-script.js @@ -1,21 +1,14 @@ ;(function () { var partners = [ { - type: 0, + type: 2, name: 'CoreOS', logo: 'core_os', link: 'https://tectonic.com/', blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.' }, { - type: 0, - name: 'Deis', - logo: 'deis', - link: 'https://deis.com', - blurb: 'Deis the creators of Helm, Workflow, and Steward, helps developers and operators build, deploy, manage and scale their applications on top of Kubernetes.' - }, - { - type: 0, + type: 2, name: 'StackPointCloud', logo: 'stackpoint', link: 'https://stackpoint.io', @@ -49,13 +42,6 @@ link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/', blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.' }, - { - type: 0, - name: 'Skippbox', - logo: 'skippbox', - link: 'http://www.skippbox.com/tag/products/', - blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox’s solutions distill all the power of k8s in simple easy to use interfaces.' - }, { type: 0, name: 'Weave Works', @@ -134,7 +120,7 @@ blurb: 'Deep, automated security for your containers running on Kubernetes.' }, { - type: 0, + type: 2, name: 'Canonical', logo: 'canonical', link: 'https://jujucharms.com/canonical-kubernetes/', @@ -183,14 +169,14 @@ blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.' }, { - type: 0, + type: 2, name: 'Giant Swarm', logo: 'giant_swarm', link: 'https://giantswarm.io', blurb: 'Giant Swarm provides fully-managed Kubernetes Clusters in your location of choice, so you can focus on your product.' }, { - type: 0, + type: 2, name: 'Mirantis', logo: 'mirantis', link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html', @@ -218,42 +204,28 @@ blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.' }, { - type: 1, + type: 2, name: 'Livewyer', logo: 'livewyer', link: 'https://livewyer.io/services/kubernetes-experts/', blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.' }, { - type: 1, - name: 'Deis', - logo: 'deis', - link: 'https://deis.com/services/', - blurb: 'Deis provides professional services and 24x7 operational support for any Kubernetes cluster managed by our global cluster operations team.' - }, - { - type: 1, - name: 'StackPointCloud', - logo: 'stackpoint', - link: 'https://stackpoint.io', - blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.' - }, - { - type: 1, + type: 2, name: 'Samsung SDS', logo: 'samsung_sds', link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' }, { - type: 1, + type: 2, name: 'Container Solutions', logo: 'container_solutions', link: 'http://container-solutions.com/resources/kubernetes/', blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' }, { - type: 1, + type: 2, name: 'Jetstack', logo: 'jetstack', link: 'https://www.jetstack.io/', @@ -288,7 +260,7 @@ blurb: 'Spotinst uses a prediction algorithm in the Amazon EC2 Spot allowing k8s clusters to increase performance and lower the infrastructure costs' }, { - type: 1, + type: 2, name: 'inwinSTACK', logo: 'inwinstack', link: 'http://www.inwinstack.com/index.php/en/solutions-en/', @@ -330,7 +302,7 @@ blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.' }, { - type: 1, + type: 2, name: 'RX-M', logo: 'rxm', link: 'http://rx-m.com/training/kubernetes-training/', @@ -372,7 +344,7 @@ blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.' }, { - type: 0, + type: 2, name: 'Supergiant.io', logo: 'supergiant', link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money', @@ -418,7 +390,7 @@ name: 'Cobe', logo: 'cobe', link: 'https://cobe.io/product-page/', - blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.' + blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.' }, { type: 0, @@ -463,7 +435,7 @@ blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. ' }, { - type: 0, + type: 2, name: 'Bitnami', logo: 'bitnami', link: 'http://bitnami.com/kubernetes', @@ -491,7 +463,7 @@ blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.' }, { - type: 0, + type: 2, name: 'Huawei Technologies Co., Ltd.', logo: 'huawei', link: 'http://developer.huawei.com/ict/en/site-paas', @@ -533,14 +505,7 @@ blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.' }, { - type: 0, - name: 'IBM', - logo: 'IBM', - link: 'https://www.ibm.com/cloud-computing/bluemix/containers', - blurb: 'IBM Container Service is a managed k8s environment with built-in cluster security and isolation while leveraging services including Watson, IoT, Weather, etc.' - }, - { - type: 1, + type: 2, name: 'IBM', logo: 'IBM', link: 'https://www.ibm.com/cloud-computing/bluemix/containers', @@ -566,9 +531,80 @@ logo: 'endocode', link: 'https://endocode.com/kubernetes/', blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.' - } + }, + { + type: 2, + name: 'Accenture', + logo: 'accenture', + link: 'https://www.accenture.com/us-en/service-application-containers', + blurb: 'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.' + }, + { + type: 1, + name: 'Biarca', + logo: 'biarca', + link: 'http://biarca.io/', + blurb: 'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.' + }, + { + type: 2, + name: 'Claranet', + logo: 'claranet', + link: 'http://www.claranet.co.uk/hosting/google-cloud-platform-consulting-managed-services', + blurb: 'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.' + }, + { + type: 1, + name: 'CloudKite', + logo: 'cloudkite', + link: 'https://cloudkite.io/', + blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.' + }, + { + type: 1, + name: 'CloudOps', + logo: 'CloudOps', + link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/', + blurb: 'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.' + }, + { + type: 2, + name: 'Ghostcloud', + logo: 'ghostcloud', + link: 'https://www.ghostcloud.cn/ecos-kubernetes', + blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.' + }, + { + type: 2, + name: 'Contino', + logo: 'contino', + link: 'https://www.contino.io/', + blurb: 'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.' + }, + { + type: 2, + name: 'Heptio', + logo: 'heptio', + link: 'http://heptio.com', + blurb: 'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.' + }, + { + type: 2, + name: 'Booz Allen Hamilton', + logo: 'boozallenhamilton', + link: 'https://www.boozallen.com/', + blurb: 'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.' + }, + { + type: 0, + name: 'Applatix', + logo: 'applatix', + link: 'https://applatix.com/applatix-product/', + blurb: 'Applatix helps build and run containerized apps on public cloud using Docker and Kubernetes.' + } ] + var kcspContainer = document.getElementById('kcspContainer') var isvContainer = document.getElementById('isvContainer') var servContainer = document.getElementById('servContainer') @@ -601,7 +637,15 @@ box.appendChild(img) box.appendChild(div) - var container = obj.type ? servContainer : isvContainer + var container; + if (obj.type === 0) { + container = isvContainer; + } else if (obj.type === 1) { + container = servContainer; + } else if (obj.type === 2) { + container = kcspContainer; + } + container.appendChild(box) }) })(); diff --git a/_includes/partner-style.css b/_includes/partner-style.css index a8cc125992..191d6b340b 100644 --- a/_includes/partner-style.css +++ b/_includes/partner-style.css @@ -1,5 +1,65 @@ +/* SECTIONS */ +.section { + clear: both; + padding: 0px; + margin-bottom: 2em; +} + +/* COLUMN SETUP */ +.col { + display: block; + float:left; + margin: 1% 0 1% 1.6%; + background-color: #f9f9f9; +} +.col:first-child { margin-left: 0; } + + +/* GROUPING */ +.group:before, +.group:after { + content:""; + display:table; +} +.group:after { + clear:both; +} +.group { + zoom:1; /* For IE 6/7 */ +} + +/* GRID OF THREE */ +.span_3_of_3 { + width: 32.2%; + background-color: #f9f9f9; + padding: 20px; +} +.span_2_of_3 { + width: 32.2%; + background-color: #f9f9f9; + padding: 20px; +} +.span_1_of_3 { + width: 32.2%; + background-color: #f9f9f9; + padding: 20px; +} + +/* GO FULL WIDTH AT LESS THAN 480 PIXELS */ + +@media only screen and (max-width: 480px) { + .col { margin: 1% 0 1% 0%;} + .span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; } +} + +.button{ + max-width: 100%; + line-height: 14px; + padding: 15px; + } + h5 { - font-size: 18px; + font-size: 16px; line-height: 1.5em; margin-bottom: 2em; } @@ -9,7 +69,7 @@ h5 { background-color: #f9f9f9; } -#isvContainer, #servContainer { +#kcspContainer, #isvContainer, #servContainer { position: relative; width: 100%; display: flex; @@ -21,6 +81,10 @@ h5 { margin-bottom: 80px; } +#kcspContainer { + margin-bottom: 80px; +} + .partner-box { position: relative; width: 47%; @@ -58,7 +122,7 @@ h5 { } @media screen and (max-width: 568px) { - #isvContainer, #servContainer { + #kcspContainer, #isvContainer, #servContainer { justify-content: center; } @@ -76,7 +140,7 @@ h5 { } @media screen and (max-width: 568px) { - #isvContainer, #servContainer { + #kcspContainer, #isvContainer, #servContainer { justify-content: center; } diff --git a/case-studies/box.html b/case-studies/box.html index 468a7b2e4a..6b816631bf 100644 --- a/case-studies/box.html +++ b/case-studies/box.html @@ -55,7 +55,7 @@ css: /css/style_box.css A platform that allows its more than 50 million users (including governments and big businesses like General Electric) to manage and share content in the cloud, Box was originally a PHP monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."

Box’s cloud native journey accelerated that June, when Ghods attended DockerCon. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.

At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of Borg veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."

- Another plus: Ghods liked that Kubernetes has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like OpenShift or Deis that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."

+ Another plus: Ghods liked that Kubernetes has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like OpenShift or Deis that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."

Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods’s team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn’t fail synchronous incoming requests from customers." diff --git a/cn/docs/admin/ovs-networking.md b/cn/docs/admin/ovs-networking.md new file mode 100644 index 0000000000..7153f2a7b1 --- /dev/null +++ b/cn/docs/admin/ovs-networking.md @@ -0,0 +1,22 @@ +--- +assignees: +- thockin +title: Kubernetes OpenVSwitch GRE/VxLAN 网络 +--- + +本文档介绍了如何使用OpenVSwitch，在跨nodes的pods之间设置网络。 +隧道类型可以是GRE或者是VxLAN。如需在网络内执行大规模隔离时，最好使用VxLAN。 + +![OVS Networking](/images/docs/ovs-networking.png) + +Kubernetes中Vagrant的设置如下： + +docker网桥被brctl生成的Linux网桥(kbr0)所代替，kbr0是具有256个地址空间的子网。总的来说，node会得到10.244.x.0/24的子网，docker上配置使用的网桥会代替默认docker0的网桥。 + +另外，OVS网桥创建(obr0)，并将其作为端口添加到kbr0的网桥中。所有OVS网桥通过GRE隧道连接所有的nodes。因此，每个node都有一个到其他nodes的出站GRE隧道。这个隧道没有必要是一个完整的网状物，但是越像网状结构越好。在网桥上开启STP(生成树)模式以防止环路的发生。 + +路由规则允许任何10.244.0.0/16通过与隧道相连的OVS网桥到达目标。 + + + + diff --git a/cn/docs/concepts/architecture/master-node-communication.md b/cn/docs/concepts/architecture/master-node-communication.md new file mode 100644 index 0000000000..e090ed3197 --- /dev/null +++ b/cn/docs/concepts/architecture/master-node-communication.md @@ -0,0 +1,71 @@ +--- +approvers: +- dchen1107 +- roberthbailey +- liggitt + +title: Master 节点通信 +--- + +* TOC +{:toc} + + +## 概览 + + +本文对 Master 节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。目的是为了让用户能够自定义他们的安装，对网络配置进行加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公共的 IP 上）运行。 + + +## Cluster -> Master + + +所有从集群到 master 的通信路径都终止于 apiserver（其它 master 组件没有被设计为可暴露远程服务）。在一个典型的部署中，apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用一种或多种形式的客户端[身份认证](/docs/admin/authentication/)机制。一种或多种客户端[身份认证](/docs/admin/authentication/)机制应该被启用，特别是在允许使用 [匿名请求](/docs/admin/authentication/#anonymous-requests) 或 [service account tokens](/docs/admin/authentication/#service-account-tokens) 的时候。 + + +应该使用集群的公共根证书开通节点，如此它们就能够基于有效的客户端凭据安全的连接 apiserver。例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。请查看 [kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 获取如何自动提供 kubelet 客户端证书。 + + +想要连接到 apiserver 的 Pods 可以使用一个 service account 安全的进行连接。这种情况下，当 Pods 被实例化时 Kubernetes 将自动的把公共根证书和一个有效的不记名令牌注入到 pod 里。`kubernetes` service （所有 namespaces 中）都配置了一个虚拟 IP 地址，用于转发（通过 kube-proxy）请求到 apiserver 的 HTTPS endpoint。 + + +Master 组件通过非安全（没有加密或认证）端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露，这样，所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。一段时间以后，master 组件将变为使用带身份认证和权限验证的安全端口（查看[#13598](https://github.com/kubernetes/kubernetes/issues/13598)）。 + + +这样的结果使得从集群（在节点上运行的 nodes 和 pods）到 master 的缺省连接操作模式默认被保护，能够在不可信或公网中运行。 + + +## Master -> Cluster + + +从 master（apiserver）到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。 + + +### apiserver -> kubelet + + +从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubele 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。 + + +默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。 + + +为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。 + + +如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)。 + + +最后，应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 + + +### apiserver -> nodes, pods, and services + + +从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。 + + +### SSH 隧道 + + +[Google Container Engine](https://cloud.google.com/container-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。 diff --git a/cn/docs/concepts/architecture/nodes.md b/cn/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000..1e611c896a --- /dev/null +++ b/cn/docs/concepts/architecture/nodes.md @@ -0,0 +1,234 @@ +--- +assignees: +- caesarxuchao +- dchen1107 + +title: Nodes +redirect_from: +- "/docs/admin/node/" +- "/docs/admin/node.html" +- "/docs/concepts/nodes/node/" +- "/docs/concepts/nodes/node.html" +--- + +* TOC +{:toc} + + +## Node 是什么？ + + +`Node` 是 Kubernetes 的工作节点，以前叫做 `minion`。取决于你的集群，Node 可以是一个虚拟机或者物理机器。每个 node 都有用于运行 [pods](/docs/user-guide/pods) 的必要服务，并由 master 组件管理。Node 上的服务包括 Docker、kubelet 和 kube-proxy。请查阅架构设计文档中 [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture.md#the-kubernetes-node) 一节获取更多细节。 + + +## Node 状态 + + + 一个 node 的状态包含以下信息: + +* [地址](#地址) +* ~~[阶段](#阶段)~~ **已废弃** +* [条件](#条件) +* [容量](#容量) +* [信息](#信息) + + +下面对每个章节进行详细描述。 + + +### 地址 + + +这些字段组合的用法取决于你的云服务商或者裸金属配置。 + +* HostName：HostName 和 node 内核报告的相同。可以通过 kubelet 的 `--hostname-override` 参数覆盖。 +* ExternalIP：通常是可以外部路由的 node IP 地址（从集群外可访问）。 +* InternalIP：通常是仅可在集群内部路由的 node IP 地址。 + + +### 阶段 + + +一废弃：node 阶段已经不再使用。 + + +### 条件 + + +`conditions` 字段描述了所有 `Running` nodes 的状态。 + + +| Node 条件 | 描述 | +| ---------------- | ---------------------------------------- | +| `OutOfDisk` | `True` 表示 node 的空闲空间不足以用于添加新 pods, 否则为 `False` | +| `Ready` | `True` 表示 node 是健康的并已经准备好接受 pods；`False` 表示 node 不健康而且不能接受 pods；`Unknown` 表示 node 控制器在最近 40 秒内没有收到 node 的消息 | +| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低, 否则为 `False` | +| `DiskPressure` | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低, 否则为 `False` | + + +Node 条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的 node。 + +```json +"conditions": [ + { + "kind": "Ready", + "status": "True" + } +] +``` + + +如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数)，node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5分钟**。某些情况下，当 node 不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区 node 上运行。 + + +在 1.5 版本之前的 Kubernetes 里，node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群，集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。 + + +### 容量 + + +描述 node 上的可用资源：CPU、内存和可以调度到 node 上的 pods 的最大数量。 + + +### 信息 + + +关于 node 的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本 （如果使用了）和 OS 名。这些信息由 Kubelet 从 node 搜集而来。 + + +## 管理 + + +与 [pods](/docs/user-guide/pods) 和 [services](/docs/user-guide/services) 不同，node 并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个 node 时，它其实仅仅创建了一个对象来代表这个 node。创建以后，Kubernetes 将检查这个 node 是否可用。例如，如果你尝试使用如下内容创建一个 node： + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + + +Kubernetes 会在内部创一个 node 对象（象征 node），并基于 `metadata.name` 字段（我们假设 `metadata.name` 能够被解析）通过健康检查来验证 node。如果 node 可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略指导变为可用。请注意，Kubernetes 将保存不可用 node 的对象，除非它被客户端显式的删除。Kubernetes 将持续检查 node 是否变的可用。 + + +当前，有3个组件同 Kubernetes node 接口交互：node 控制器、kubelet 和 kubectl。 + + +### Node 控制器 + + +Node 控制器是一个 Kubernetes master 组件，管理 nodes 的方方面面。 + + +Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当 node 注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。 + + +第二个是使用云服务商提供了可用节点列表保持 node 控制器内部的 nodes 列表更新。如果在云环境下运行，任何时候当一个 node 不健康时 node 控制器将询问云服务 node 的虚拟机是否可用。如果不可用，node 控制器会将这个 node 从它的 nodes 列表删除。 + + +第三个是监控 nodes 的健康情况。Node 控制器负责在 node 不能访问时（也即是 node 控制器因为某些原因没有收到心跳，例如 node 宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果 node 持续不可访问，Node 控制器将删除 node 上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）Node 控制器每隔 `--node-monitor-period` 秒检查每个 node 的状态。 + + +在 Kubernetes 1.4 中我们更新了 node 控制器逻辑以更好的处理大批量 nodes 访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，node 控制器在决定删除 pod 之前会检查集群中所有 nodes 的状态。 + + +大部分情况下， node 控制器把删除频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它在 10 秒钟内不会从超过一个 node 上删除 pods。 + + +当一个 availability zone 中的 node 变为不健康时，它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），删除速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为50），删除将会停止，否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones，那就只有一个 availability zone（整个集群）。 + + +在多个 availability zones 分布你的 nodes 的一个关键原因是当整个 zone 故障时，工作负载可以转移到健康的 zones。因此，如果一个 zone 中的所有 nodes 都不健康时，node 控制器会以正常的速率 `--node-eviction-rate` 删除。在所有的 zones 都不健康（也即集群中没有健康 node）的极端情况下，node 控制器将假设 master 的连接出了某些问题，它将停止所有删除动作直到一些连接恢复。 + + +从 Kubernetes 1.6 开始，NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods，如果这些 pods 没有 tolerate 这些 taints。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据 node 故障（例如 node 不可访问或没有 ready）添加 taints。请查看 [这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。 + + +### Nodes 自注册 + + +当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。 + + + 对于自注册模式，kubelet 使用下列参数启动： + + - `--api-servers` - apiservers 地址。 + - `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。 + - `--cloud-provider` - 如何从云服务商读取关于自己的元数据。 + - `--register-node` - 自动向 API 服务注册。 + - `--register-with-taints` - 使用 taints 列表（逗号分隔的 `=:`）注册 node。当 `register-node` 为 false 时无效。 + - `--node-ip` - node IP 地址。 + - `--node-labels` - 向集群注册时给 node 添加的 labels。 + - `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。 + + +目前，任何 kubelet 都被授权可以创建/修改任意 node 资源，但通常只对自己的进行创建/修改。（未来我们计划只允许一个 kubelet 修改它自己 node 的资源。） + + +#### 手动 Node 管理 + + +集群管理员可以创建及修改 node 对象。 + + +如果管理员希望手动创建 node 对象，请设置 kubelet 标记 `--register-node=false`。 + + +管理员可以修改 node 资源（忽略 `--register-node` 设置）。修改包括在 node 上设置 labels及标记它为不可调度。 + + +Nodes 上的 labels 可以和 pods 的 node selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的 nodes 子集上运行。 + + +标记一个 node 为不可调度的将防止新建 pods 调度到那个 node 之上，但不会影响任何已经在它之上的 pods。这是重启 node 等操作之前的一个有用的准备步骤。例如，标记一个 node 为不可调度的，执行以下命令： + +```shell +kubectl cordon $NODENAME +``` + + +请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照 node 上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。 + + +### Node 容量 + + +Node 的容量（cpu 数量和内存容量）是 node 对象的一部分。通常情况下，在创建 node 对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动 node 管理](#manual-node-administration)，那么你需要在添加 node 时手动设置 node 容量。 + + +Kubernetes 调度器保证一个 node 上有足够的资源供其上的所有 pods 使用。它会检查 node 上所有容器要求的总和不会超过 node 的容量。这包括所有 kubelet 启动的容器，但不包含 Docker 启动的容器和不在容器中的进程。 + + +如果希望显式的为非 pod 进程预留资源，你可以创建一个占位 pod。使用如下模板： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: resource-reserver +spec: + containers: + - name: sleep-forever + image: gcr.io/google_containers/pause:0.8.0 + resources: + requests: + cpu: 100m + memory: 100Mi +``` + + +设置 `cpu` 和 `memory` 值为你希望预留的资源量。将文件放在清单文件夹中（kubelet 的 `--config=DIR` 标志）。当你希望预留资源时，在每个 kubelet 上都这样执行。 + + +## API 对象 + + +Node 是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到： [Node API +object](/docs/api-reference/{{page.version}}/#node-v1-core).`` diff --git a/cn/docs/concepts/cluster-administration/addons.md b/cn/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..1ddac950f1 --- /dev/null +++ b/cn/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,45 @@ +--- + +title: 安装扩展（Addons） +--- + + +## 概览 + + +Add-ons 扩展了 Kubernetes 的功能。 + + +本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。 + + +每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。 + + +## 网络和网络策略 + + +* [Calico](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/) 是一个安全的 L3 网络和网络策略提供者。 +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) 结合 Flannel 和 Calico， 提供网络和网络策略。 +* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件， 能够透明的实施 HTTP/API/L7 策略。 同时支持路由（routing）和叠加/封装（ overlay/encapsulation）模式。 +* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。 +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。 +* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。 +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。 + + +## 可视化管理 + + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services等。 请和一个 [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。 + + +## 遗留 Add-ons + + +还有一些其它 add-ons 归档在已废弃的 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。 + + +维护完善的 add-ons 应该被链接到这里。欢迎提出 PRs！ diff --git a/cn/docs/concepts/cluster-administration/cluster-administration-overview.md b/cn/docs/concepts/cluster-administration/cluster-administration-overview.md new file mode 100644 index 0000000000..9f6fbf0f9e --- /dev/null +++ b/cn/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -0,0 +1,86 @@ +--- +approvers: +- davidopp +- lavalamp + +title: 集群管理概述 +--- + +{% capture overview %} + +集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。 +{% endcapture %} + +{% capture body %} + +## 规划集群 + + +查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。 + + +在选择一个指南前，有一些因素需要考虑： + + - 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 + - **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。 + - 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 + - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/)，它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。 + - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）**上运行？ + - 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 + - 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。 + + +请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。 + + +如果你正在使用和 Salt 有关的指南，请查阅 [使用 Salt 配置 Kubernetes](/docs/admin/salt)。 + + +## 管理集群 + + +[管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。 + + +## 保护集群 + + +* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 + + +* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可. + + +* [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能，包括许多认证选项。 + + +* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。 + + +* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 + + +* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 + + +* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 + + +### 保护 kubelet + + * [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/) + * [TLS 引导](/docs/admin/kubelet-tls-bootstrapping/) + * [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/) + + +## 可选集群服务 + + +* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。 + + +* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。 + +{% endcapture %} + +{% include templates/concept.md %} diff --git a/cn/docs/tasks/administer-cluster/access-cluster-services.md b/cn/docs/tasks/administer-cluster/access-cluster-services.md new file mode 100644 index 0000000000..00e06266ab --- /dev/null +++ b/cn/docs/tasks/administer-cluster/access-cluster-services.md @@ -0,0 +1,110 @@ +--- + +title: 访问集群上运行的服务 +redirect_from: +- "/docs/user-guide/accessing-the-cluster/" +- "/docs/user-guide/accessing-the-cluster.html" +--- + +{% capture overview %} + +本文展示了如何连接 Kubernetes 集群上运行的服务。 +{% endcapture %} + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} +{% endcapture %} + +{% capture steps %} + +## 访问集群上运行的服务 + + +在 Kubernetes 里， [nodes](/docs/admin/node)、[pods](/docs/user-guide/pods) 和 [services](/docs/user-guide/services) 都有它们自己的 IP。许多情况下，集群上的 node IP、pod IP 和某些 service IP 路由不可达，所以不能从一个集群之外的节点访问它们，例如从你自己的台式机。 + + +### 连接方式 + + +你有多种从集群外连接 nodes、pods 和 services 的选项： + + + - 通过公共 IP 访问 services。 + - 使用具有 `NodePort` 或 `LoadBalancer` 类型的 service，可以从外部访问它们。请查阅 [services](/docs/user-guide/services) 和 [kubectl expose](/docs/user-guide/kubectl/v1.6/#expose) 文档。 + - 取决于你的集群环境，你可以仅把 service 暴露在你的企业网络环境中，也可以将其暴露在因特网上。需要考虑暴露的 service 是否安全，它是否有自己的用户认证？ + - 将 pods 放置于 services 背后。如果要访问一个副本集合中特定的 pod，例如用于调试目的时，请给 pod 指定一个独特的标签并创建一个新 service 选择这个标签。 + - 大部分情况下，都不需要应用开发者通过节点 IP 直接访问 nodes。 + - 通过 Proxy Verb 访问 services、nodes 或者 pods。 + - 在访问 Apiserver 远程服务之前是否经过认证和授权？如果你的服务暴露到因特网中不够安全，或者需要获取 node IP 之上的端口，又或者处于调试目的时，请使用这个特性。 + - Proxies 可能给某些应用带来麻烦。 + - 仅适用于 HTTP/HTTPS。 + - 在[这里](#manually-constructing-apiserver-proxy-urls)描述 + - 从集群中的 node 或者 pod 访问。 + - 运行一个 pod，然后使用 [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec) 连接到它的一个shell。从那个 shell 连接其他的 nodes、pods 和 services。 + - 某些集群可能允许你 ssh 到集群中的节点。你可能可以从那儿访问集群服务。这是一个非标准的方式，可能在一些集群上能工作，但在另一些上却不能。浏览器和其他工具可能安装或可能不会安装。集群 DNS 可能不会正常工作。 + + +### 发现内置服务 + + +典型情况下，kube-system 会启动集群中的几个服务。使用 `kubectl cluster-info` 命令获取它们的列表： + +```shell +$ kubectl cluster-info + + Kubernetes master is running at https://104.197.5.247 + elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy + kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy + kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy + grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy + heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +``` + +这显示了用于访问每个服务的 proxy-verb URL。例如，这个集群启用了（使用 Elasticsearch）集群层面的日志，如果提供合适的凭据可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 访问，或通过一个 kubectl 代理地址访问，如：`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`。（请查看 [上文](#accessing-the-cluster-api) 关于如何传递凭据或者使用 kubectl 代理的说明。） + + +#### 手动构建 apiserver 代理 URLs + + +如同上面所提到的，你可以使用 `kubectl cluster-info` 命令取得 service 的代理 URL。为了创建包含 service endpoints、suffixes 和 parameters 的代理 URLs，你可以简单的在 service 的代理 URL中 添加： +`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` + + +如果还没有为你的端口指定名称，你可以不用在 URL 中指定 *port_name*。 + + +##### 示例 + + + * 你可以通过 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy` 访问 Elasticsearch service endpoint `_search?q=user:kimchy`。 + * 你可以通过 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true` 访问 Elasticsearch 集群健康信息 endpoint `_cluster/health?pretty=true`。 + +```json + { + "cluster_name" : "kubernetes_logging", + "status" : "yellow", + "timed_out" : false, + "number_of_nodes" : 1, + "number_of_data_nodes" : 1, + "active_primary_shards" : 5, + "active_shards" : 5, + "relocating_shards" : 0, + "initializing_shards" : 0, + "unassigned_shards" : 5 + } +``` + + +#### 通过 web 浏览器访问集群中运行的服务 + + +你或许能够将 apiserver 代理的 url 放入浏览器的地址栏，然而： + + + - Web 服务器不总是能够传递令牌，所以你可能需要使用基本（密码）认证。 Apiserver 可以配置为接受基本认证，但你的集群可能并没有这样配置。 + - 某些 web 应用可能不能工作，特别是那些使用客户端侧 javascript 的应用，它们构造 url 的方式可能不能理解代理路径前缀。 + +{% endcapture %} + +{% include templates/task.md %} diff --git a/cn/docs/tasks/administer-cluster/apply-resource-quota-limit.md b/cn/docs/tasks/administer-cluster/apply-resource-quota-limit.md new file mode 100644 index 0000000000..5ffd280425 --- /dev/null +++ b/cn/docs/tasks/administer-cluster/apply-resource-quota-limit.md @@ -0,0 +1,411 @@ +--- +assignees: +- derekwaynecarr +- janetkuo + +title: 应用资源配额和限额 +redirect_from: +- "/docs/admin/resourcequota/walkthrough/" +- "/docs/admin/resourcequota/walkthrough.html" +- "/docs/tasks/configure-pod-container/apply-resource-quota-limit/" +- "/docs/tasks/configure-pod-container/apply-resource-quota-limit.html" +--- + +{% capture overview %} + + +本示例展示了在一个 namespace 中控制资源用量的典型设置。 + + +本文展示了以下资源的使用： [Namespace](/docs/admin/namespaces), [ResourceQuota](/docs/concepts/policy/resource-quotas/) 和 [LimitRange](/docs/tasks/configure-pod-container/limit-range/)。 + +{% endcapture %} + +{% capture prerequisites %} + +* {% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + +## 场景 + + +集群管理员正在操作一个代表用户群体的集群，他希望控制一个特定 namespace 中可以被使用的资源总量，以达到促进对集群的公平共享及控制成本的目的。 + + +集群管理员有以下目标： + + +* 限制运行中 pods 使用的计算资源数量 +* 限制 persistent volume claims 数量以控制对存储的访问 +* 限制 load balancers 数量以控制成本 +* 防止使用 node ports 以保留稀缺资源 +* 提供默认计算资源请求以实现更好的调度决策 + + +## 创建 namespace + + +本示例将在一个自定义的 namespace 中运行，以展示相关概念。 + + +让我们创建一个叫做 quota-example 的新 namespace： + +```shell +$ kubectl create namespace quota-example +namespace "quota-example" created +$ kubectl get namespaces +NAME STATUS AGE +default Active 2m +kube-system Active 2m +quota-example Active 39s +``` + + +## 应用 object-count 配额到 namespace + + +集群管理员想要控制下列资源： + +* persistent volume claims +* load balancers +* node ports + + +我们来创建一个简单的配额，用于控制这个 namespace 中那些资源类型的对象数量。 + +```shell +$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-object-counts.yaml --namespace=quota-example +resourcequota "object-counts" created +``` + + +配额系统将察觉到有一个配额被创建，并且会计算 namespace 中的资源消耗量作为响应。这应该会很快发生。 + + +让我们显示一下配额来观察这个 namespace 中当前被消耗的资源： + +```shell +$ kubectl describe quota object-counts --namespace=quota-example +Name: object-counts +Namespace: quota-example +Resource Used Hard +-------- ---- ---- +persistentvolumeclaims 0 2 +services.loadbalancers 0 2 +services.nodeports 0 0 +``` + + +配额系统现在将阻止用户创建比各个资源指定数量更多的资源。 + + + +## 应用计算资源配额到 namespace + + +为了限制这个 namespace 可以被使用的计算资源数量，让我们创建一个跟踪计算资源的配额。 + +```shell +$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-compute-resources.yaml --namespace=quota-example +resourcequota "compute-resources" created +``` + + +让我们显示一下配额来观察这个 namespace 中当前被消耗的资源： + +```shell +$ kubectl describe quota compute-resources --namespace=quota-example +Name: compute-resources +Namespace: quota-example +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +pods 0 4 +requests.cpu 0 1 +requests.memory 0 1Gi +``` + + +配额系统现在会防止 namespace 拥有超过 4 个没有终止的 pods。此外它还将强制 pod 中的每个容器配置一个 `request` 并为 `cpu` 和 `memory` 定义 `limit`。 + + +## 应用默认资源请求和限制 + + +Pod 的作者很少为它们的 pods 指定资源请求和限制。 + + +既然我们对项目应用了配额，我们来看一下当终端用户通过创建一个没有 cpu 和 内存限制的 pod 时会发生什么。这通过在 pod 里创建一个 nginx 容器实现。 + + +作为演示，让我们来创建一个运行 nginx 的 deployment： + +```shell +$ kubectl run nginx --image=nginx --replicas=1 --namespace=quota-example +deployment "nginx" created +``` + + +现在我们来看一下创建的 pods。 + +```shell +$ kubectl get pods --namespace=quota-example +``` + + +发生了什么？我一个 pods 都没有！让我们 describe 这个 deployment 来看看发生了什么。 + +```shell +$ kubectl describe deployment nginx --namespace=quota-example +Name: nginx +Namespace: quota-example +CreationTimestamp: Mon, 06 Jun 2016 16:11:37 -0400 +Labels: run=nginx +Selector: run=nginx +Replicas: 0 updated | 1 total | 0 available | 1 unavailable +StrategyType: RollingUpdate +MinReadySeconds: 0 +RollingUpdateStrategy: 1 max unavailable, 1 max surge +OldReplicaSets: +NewReplicaSet: nginx-3137573019 (0/1 replicas created) +... +``` + + +Deployment 创建了一个对应的 replica set 并尝试按照大小来创建一个 pod。 + + +让我们看看 replica set 的更多细节。 + +```shell +$ kubectl describe rs nginx-3137573019 --namespace=quota-example +Name: nginx-3137573019 +Namespace: quota-example +Image(s): nginx +Selector: pod-template-hash=3137573019,run=nginx +Labels: pod-template-hash=3137573019 + run=nginx +Replicas: 0 current / 1 desired +Pods Status: 0 Running / 0 Waiting / 0 Succeeded / 0 Failed +No volumes. +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 4m 7s 11 {replicaset-controller } Warning FailedCreate Error creating: pods "nginx-3137573019-" is forbidden: Failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory +``` + + +Kubernetes API server 拒绝了 replica set 创建一个 pod 的请求，因为我们的 pods 没有为 `cpu` 和 `memory` 指定 `requests` 或 `limits`。 + + +因此，我们来为 pod 指定它可以使用的 `cpu` 和 `memory` 默认数量。 + +```shell +$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-limits.yaml --namespace=quota-example +limitrange "limits" created +$ kubectl describe limits limits --namespace=quota-example +Name: limits +Namespace: quota-example +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Container memory - - 256Mi 512Mi - +Container cpu - - 100m 200m - +``` + + +如果 Kubernetes API server 发现一个 namespace 中有一个创建 pod 的请求，并且 pod 中的容器没有设置任何计算资源请求时，作为准入控制的一部分，一个默认的 request 和 limit 将会被应用。 + + +在本例中，创建的每个 pod 都将拥有如下的计算资源限制： + +```shell +$ kubectl run nginx \ + --image=nginx \ + --replicas=1 \ + --requests=cpu=100m,memory=256Mi \ + --limits=cpu=200m,memory=512Mi \ + --namespace=quota-example +``` + + +由于已经为我们的 namespace 申请了默认的计算资源，我们的 replica set 应该能够创建它的 pods 了。 + +```shell +$ kubectl get pods --namespace=quota-example +NAME READY STATUS RESTARTS AGE +nginx-3137573019-fvrig 1/1 Running 0 6m +``` + + +而且如果打印出我们在这个 namespace 中的配额使用情况： + +```shell +$ kubectl describe quota --namespace=quota-example +Name: compute-resources +Namespace: quota-example +Resource Used Hard +-------- ---- ---- +limits.cpu 200m 2 +limits.memory 512Mi 2Gi +pods 1 4 +requests.cpu 100m 1 +requests.memory 256Mi 1Gi + + +Name: object-counts +Namespace: quota-example +Resource Used Hard +-------- ---- ---- +persistentvolumeclaims 0 2 +services.loadbalancers 0 2 +services.nodeports 0 0 +``` + + +就像你看到的，创建的 pod 消耗了明确的计算资源量，并且正被 Kubernetes 正确的追踪着。 + + +## 高级配额 scopes + + +让我们想象一下如果你不希望为你的 namespace 指定默认计算资源使用量。 + + +作为替换，你希望用户在它们的 namespace 中运行指定数量的 `BestEffort` pods，以从宽松的计算资源中获得好处。然后要求用户为需要更高质量服务的 pods 配置一个显式的资源请求。 + + +让我们新建一个拥有两个配额的 namespace 来演示这种行为： + +```shell +$ kubectl create namespace quota-scopes +namespace "quota-scopes" created +$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-best-effort.yaml --namespace=quota-scopes +resourcequota "best-effort" created +$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-not-best-effort.yaml --namespace=quota-scopes +resourcequota "not-best-effort" created +$ kubectl describe quota --namespace=quota-scopes +Name: best-effort +Namespace: quota-scopes +Scopes: BestEffort + * Matches all pods that have best effort quality of service. +Resource Used Hard +-------- ---- ---- +pods 0 10 + + +Name: not-best-effort +Namespace: quota-scopes +Scopes: NotBestEffort + * Matches all pods that do not have best effort quality of service. +Resource Used Hard +-------- ---- ---- +limits.cpu 0 2 +limits.memory 0 2Gi +pods 0 4 +requests.cpu 0 1 +requests.memory 0 1Gi +``` + + +在这种场景下，一个没有配置计算资源请求的 pod 将会被 `best-effort` 配额跟踪。 + + +而配置了计算资源请求的则会被 `not-best-effort` 配额追踪。 + + +让我们创建两个 deployments 作为演示： + +```shell +$ kubectl run best-effort-nginx --image=nginx --replicas=8 --namespace=quota-scopes +deployment "best-effort-nginx" created +$ kubectl run not-best-effort-nginx \ + --image=nginx \ + --replicas=2 \ + --requests=cpu=100m,memory=256Mi \ + --limits=cpu=200m,memory=512Mi \ + --namespace=quota-scopes +deployment "not-best-effort-nginx" created +``` + + +虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。 + + +让我们列出 namespace 中的 pods： + +```shell +$ kubectl get pods --namespace=quota-scopes +NAME READY STATUS RESTARTS AGE +best-effort-nginx-3488455095-2qb41 1/1 Running 0 51s +best-effort-nginx-3488455095-3go7n 1/1 Running 0 51s +best-effort-nginx-3488455095-9o2xg 1/1 Running 0 51s +best-effort-nginx-3488455095-eyg40 1/1 Running 0 51s +best-effort-nginx-3488455095-gcs3v 1/1 Running 0 51s +best-effort-nginx-3488455095-rq8p1 1/1 Running 0 51s +best-effort-nginx-3488455095-udhhd 1/1 Running 0 51s +best-effort-nginx-3488455095-zmk12 1/1 Running 0 51s +not-best-effort-nginx-2204666826-7sl61 1/1 Running 0 23s +not-best-effort-nginx-2204666826-ke746 1/1 Running 0 23s +``` + + +如你看到的，所有 10 个 pods 都已经被准许创建。 + + +让我们 describe 这个 namespace 当前的配额使用情况： + +```shell +$ kubectl describe quota --namespace=quota-scopes +Name: best-effort +Namespace: quota-scopes +Scopes: BestEffort + * Matches all pods that have best effort quality of service. +Resource Used Hard +-------- ---- ---- +pods 8 10 + + +Name: not-best-effort +Namespace: quota-scopes +Scopes: NotBestEffort + * Matches all pods that do not have best effort quality of service. +Resource Used Hard +-------- ---- ---- +limits.cpu 400m 2 +limits.memory 1Gi 2Gi +pods 2 4 +requests.cpu 200m 1 +requests.memory 512Mi 1Gi +``` + + +如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。 + + +Scopes 提供了一种来对任何配额文档追踪的资源集合进行细分的机制，给操作人员部署和追踪资源消耗带来更大的灵活性。 + + +除 `BestEffort` 和 `NotBestEffort` scopes 之外，还有用于限制长时间运行和有时限 pods 的scopes。`Terminating` scope 将匹配任何 `spec.activeDeadlineSeconds` 不为 `nil` 的 pod。`NotTerminating` scope 将匹配任何 `spec.activeDeadlineSeconds` 为 `nil` 的 pod。这些 scopes 允许你基于 pods 在你集群中 node 上的预期持久程度来为它们指定配额。 + +{% endcapture %} + +{% capture discussion %} + +## 总结 + + +消耗节点 cpu 和 memory 资源的动作受到 namespace 配额定义的硬性配额限制的管制。 + + +任意消耗那些资源的动作能够被调整，或者获得一个 namespace 级别的默认值以符合你最终的目标。 + + +可以基于服务质量或者在你集群中节点上的预期持久程度来分配配额。 + +{% endcapture %} + +{% include templates/task.md %} diff --git a/cn/docs/tasks/administer-cluster/change-default-storage-class.md b/cn/docs/tasks/administer-cluster/change-default-storage-class.md new file mode 100644 index 0000000000..b1ba51a064 --- /dev/null +++ b/cn/docs/tasks/administer-cluster/change-default-storage-class.md @@ -0,0 +1,94 @@ +--- + +title: 改变默认 StorageClass +--- + +{% capture overview %} + +本文展示了如何改变默认的 Storage Class，它用于为没有特殊需求的 PersistentVolumeClaims 配置 volumes。 + +{% endcapture %} + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + + +## 为什么要改变默认 storage class？ + + +取决于安装模式，您的 Kubernetes 集群可能和一个被标记为默认的已有 StorageClass 一起部署。这个默认的 StorageClass 以后将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储。更多细节请查看 [PersistentVolumeClaim 文档](/docs/user-guide/persistent-volumes/#class-1)。 + + +预先安装的默认 StorageClass 可能不能很好的适应您期望的工作负载；例如，它配置的存储可能太过昂贵。如果是这样的话，您可以改变默认 StorageClass，或者完全禁用它以防止动态配置存储。 + + +简单的删除默认 StorageClass 可能行不通，因为它可能会被您集群中的扩展管理器自动重建。请查阅您的安装文档中关于扩展管理器的细节，以及如何禁用单个扩展。 + + +## 改变默认 StorageClass + + +1. 列出您集群中的 StorageClasses： + + kubectl get storageclass + + + 输出类似这样： + + NAME TYPE + standard (default) kubernetes.io/gce-pd + gold kubernetes.io/gce-pd + + + 默认 StorageClass 以 `(default)` 标记。 + + +2. 标记默认 StorageClass 非默认： + + + 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。 + + + 要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`： + + kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' + + + 这里的 `` 是您选择的 StorageClass 的名字。 + + +3. 标记一个 StorageClass 为默认的： + + + 和前面的步骤类似，您需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。 + + kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + + + 请注意，最多只能有一个 StorageClass 能够被标记为默认。如果它们中有两个或多个被标记为默认，Kubernetes 将忽略这个注解，也就是它将表现为没有默认 StorageClass。 + + +4. 验证您选用的 StorageClass 为默认的： + + kubectl get storageclass + + + 输出类似这样： + + NAME TYPE + standard kubernetes.io/gce-pd + gold (default) kubernetes.io/gce-pd + +{% endcapture %} + +{% capture whatsnext %} + +* 了解更多关于 [StorageClasses](/docs/concepts/storage/persistent-volumes/)。 + {% endcapture %} + +{% include templates/task.md %} diff --git a/cn/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/cn/docs/tasks/administer-cluster/change-pv-reclaim-policy.md new file mode 100644 index 0000000000..14844d903e --- /dev/null +++ b/cn/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -0,0 +1,80 @@ +--- +title: 更改 PersistentVolume 的回收策略 +--- + + +{% capture overview %} + +本文展示了如何更改 Kubernetes PersistentVolume 的回收策略。 +{% endcapture %} + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + + +## 为什么要更改 PersistentVolume 的回收策略 + + +`PersistentVolumes` 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 `PersistentVolumes` 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 `PeristentVolumeClaim` 时，动态配置的 volume 将被自动删除。如果 volume 包含重要数据时，这种自动行为可能是不合适的。那种情况下，更适合使用 "Retain" 策略。使用 "Retain" 时，如果用户删除 `PersistentVolumeClaim`，对应的 `PersistentVolume` 不会被删除。相反，它将变为 `Released` 状态，表示所有的数据可以被手动恢复。 + + +## 更改 PersistentVolume 的回收策略 + + +1. 列出你集群中的 PersistentVolumes + + kubectl get pv + + 输出类似于这样： + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 10s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 6s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 3s + + + 这个列表同样包含了绑定到每个 volume 的 claims 名称，以便更容易的识别动态配置的 volumes。 + + +2. 选择你的 PersistentVolumes 中的一个并更改它的回收策略： + + kubectl patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' + + 这里的 `` 是你选择的 PersistentVolume 的名字。 + +3. 验证你选择的 PersistentVolume 拥有正确的策略： + + kubectl get pv + + 输出类似于这样： + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 40s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 36s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 33s + + + 在前面的输出中，你可以看到绑定到 claim `default/claim3` 的 volume 拥有的回收策略为 `Retain`。当用户删除 claim `default/claim3` 时，它不会被自动删除。 + +{% endcapture %} + +{% capture whatsnext %} + +* 了解更多关于 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)的信息。 +* 了解更多关于 [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 的信息。 + + +### 参考 + +* [PersistentVolume](/docs/api-reference/{{page.version}}/#persistentvolume-v1-core) +* [PersistentVolumeClaim](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core) + +* 查阅 [PersistentVolumeSpec](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core) 的 `persistentVolumeReclaimPolicy` 字段。 +{% endcapture %} + +{% include templates/task.md %} diff --git a/cn/docs/tasks/administer-cluster/cluster-management.md b/cn/docs/tasks/administer-cluster/cluster-management.md new file mode 100644 index 0000000000..f492a2314d --- /dev/null +++ b/cn/docs/tasks/administer-cluster/cluster-management.md @@ -0,0 +1,227 @@ +--- +approvers: +- lavalamp +- thockin +title: 集群管理 +--- + + +* TOC +{:toc} + + +本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的 master 和 worker 节点、执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。 + + +## 创建和配置集群 + + +要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/) + + +## 升级集群 + + +集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。推荐管理员在升级他们的集群前，同时查阅 [发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。 + + +* [升级到 1.6](/docs/admin/upgrade-1-6) + + +### 升级 Google Compute Engine 集群 + + +Google Compute Engine Open Source (GCE-OSS) 通过删除和重建 master 来支持 master 升级。通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。 + + +GCE 的 Node 升级采用 [管理实例组](https://cloud.google.com/compute/docs/instance-groups/)，每个节点将被顺序的删除，然后使用新软件重建。任何运行在那个节点上的 Pod 需要用 Replication Controller 控制，或者在扩容之后手动重建。 + + +开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。 + + +运行 `cluster/gce/upgrade.sh -h` 获取使用说明。 + + +例如，只将 master 升级到一个指定的版本 (v1.0.2): + +```shell +cluster/gce/upgrade.sh -M v1.0.2 +``` + + +或者，将整个集群升级到最新的稳定版本： + +```shell +cluster/gce/upgrade.sh release/stable +``` + + +### 升级 Google Container Engine (GKE) 集群 + + +Google Container Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。 + + +节点升级过程由用户初始化，[GKE 文档](https://cloud.google.com/container-engine/docs/clusters/upgrade) 里有相关描述。 + + +### 在其他平台上升级集群 + + +不同的供应商和工具管理升级的过程各不相同。建议您查阅它们有关升级的主要文档。 + +* [kops](https://github.com/kubernetes/kops) +* [kubespray](https://github.com/kubernetes-incubator/kubespray) +* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html) +* ... + + +## 调整集群大小 + + +如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在[节点自注册模式](/docs/admin/node/#self-registration-of-nodes)下的话。如果正在使用的是 GCE 或者 GKE，这将通过调整管理节点的实例组的大小完成。在 [Google Cloud Console page](https://console.developers.google.com) 的 `Compute > Compute Engine > Instance groups > your group > Edit group` 下修改实例数量或使用 gcloud CLI 都可以完成这个任务。 + +```shell +gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE +``` + + +实例组将负责在新机器上放置恰当的镜像并启动它们。Kubelet 将向 API server 注册它的节点以使其可以用于调度。如果您对 instance group 进行缩容，系统将会随机选取节点来终止。 + + +在其他环境上，您可能需要手动配置机器并告诉 Kubelet API server 在哪台机器上运行。 + + +### 集群自动伸缩 + + +如果正在使用 GCE 或者 GKE，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。 + + +如 [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/) 所述，用户可以控制预留多少 CPU 和内存来分配给 pod。这个信息被 Kubernetes scheduler 用来寻找一个运行 pod 的地方。如果没有一个节点有足够的空闲容量（或者不能满足其他 pod 的需求），这个 pod 就需要等待某些 pod 结束，或者一个新的节点被添加。 + + +集群 autoscaler 查找不能被调度的 pod 并检查添加一个新节点（和集群中其它节点类似的）是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 pod。 + + +如果发现在一段延时时间内（默认10分钟，将来有可能改变）某些节点不再需要，集群 autoscaler 也会缩小集群。 + + +集群 autoscaler 在每一个实例组（GCE）或节点池（GKE）上配置。 + + +如果您使用 GCE，那么您可以在使用 kube-up.sh 脚本创建集群的时候启用它。要想配置集群 autoscaler，您需要设置三个环境变量： + + +* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 autoscaler。 +* `KUBE_AUTOSCALER_MIN_NODES` - 集群的最小节点数量。 +* `KUBE_AUTOSCALER_MAX_NODES` - 集群的最大节点数量。 + + +示例： + +```shell +KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh +``` + + +在 GKE 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling` `--min-nodes` 和 `--max-nodes` 来配置集群 autoscaler。 + + +示例： + +```shell +gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5 +``` + +```shell +gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15 +``` + + +**集群 autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因为那些属性可能不能被传递到相同节点组中的新节点上。** + + +## 维护节点 + + +如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，当 Kubelet 重启后，它将尝试重启调度到节点上的 pod。如果重启花费较长时间（默认时间为 5 分钟，由 controller-manager 的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 pod。如果存在对应的 replica set（或者 replication controller）时，则将在另一个节点上启动 pod 的新副本。所以，如果所有的 pod 都是复制而来，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊调整情况下完成。 + + +如果您希望更多的控制升级过程，可以使用下面的工作流程： + + +使用 `kubectl drain` 优雅的结束节点上的所有 pod 并同时标记节点为不可调度： + +```shell +kubectl drain $NODENAME +``` + + +在您正试图使节点离线时，这将阻止新的 pod 落到它们上面。 + + +对于有 replica set 的 pod 来说，它们将会被新的 pod 替换并且将被调度到一个新的节点。此外，如果 pod 是一个 service 的一部分，则客户端将被自动重定向到新的 pod。 + + +对于没有 replica set 的 pod，您需要手动启动 pod 的新副本，并且如果它不是 service 的一部分，您需要手动将客户端重定向到这个 pod。 + + +在节点上执行维护工作。 + + +重新使节点可调度： + +```shell +kubectl uncordon $NODENAME +``` + + +如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建（只在您使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。相关详细信息，请查阅 [节点](/docs/admin/node)。 + + +## 高级主题 + + +### 升级到不同的 API 版本 + + +当新的 API 版本发布时，您可能需要升级集群支持新的 API 版本（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。 + + +这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。 + + 1. 开启新 API 版本。 + 2. 升级集群存储来使用新版本。 + 3. 升级所有配置文件。识别使用旧 API 版本 endpoint 的用户。 + 4. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本。 + 5. 关闭旧 API 版本。 + + +### 打开或关闭集群的 API 版本 + + +可以在启动 API server 时传递 `--runtime-config=api/` 标志来打开或关闭特定的 API 版本。例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。运行时配置还支持两个特殊键值：api/all 和 api/legacy，分别控制全部和遗留 API。例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。对于这些标志来说，_legacy_ API 指那些被显式废弃的 API（例如 `v1beta3`）。 + + +### 切换集群存储的 API 版本 + + +存储于磁盘中，用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本书写。当支撑的 API 改变时，这些对象可能需要使用更新的 API 重写。重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。 + + +`kube-apiserver` 二进制文件的 `KUBE_API_VERSIONS` 环境变量控制了集群支持的 API 版本。列表中的第一个版本被用作集群的存储版本。因此，要设置特定的版本为存储版本，请将其放在 `KUBE_API_VERSIONS` 参数值版本列表的最前面。您需要重启 `kube-apiserver` 二进制以使这个变量的改动生效。 + + +### 切换配置文件为新 API 版本 + + +可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。 + +```shell +kubectl convert -f pod.yaml --output-version v1 +``` + + +更多选项请参考 [kubectl convert](/docs/user-guide/kubectl/v1.6/#convert) 命令用法。 diff --git a/cn/docs/tasks/run-application/scale-stateful-set.md b/cn/docs/tasks/run-application/scale-stateful-set.md new file mode 100644 index 0000000000..9262faae2e --- /dev/null +++ b/cn/docs/tasks/run-application/scale-stateful-set.md @@ -0,0 +1,89 @@ +--- +approvers: +- bprashanth +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +- smarterclayton +title: 弹缩StatefulSet +--- + +{% capture overview %} +本文介绍如何弹缩StatefulSet. +{% endcapture %} + +{% capture prerequisites %} + +* StatefulSets仅适用于Kubernetes1.5及以上版本. +* **不是所有Stateful应用都适合弹缩.** 在弹缩前您的应用前. 您必须充分了解您的应用, 不适当的弹缩StatefulSet或许会造成应用自身功能的不稳定. +* 仅当您确定该Stateful应用的集群是完全健康才可执行弹缩操作. + +{% endcapture %} + +{% capture steps %} + +## 使用 `kubectl` 弹缩StatefulSets + +弹缩请确认 `kubectl` 已经升级到Kubernetes1.5及以上版本. 如果不确定, 执行 `kubectl version` 命令并检查使用的 `Client Version`. + +### `kubectl 弹缩` + +首先, 找到您想要弹缩的StatefulSet. 记住, 您需先清楚是否能弹缩该应用. + +```shell +kubectl get statefulsets +``` + +改变StatefulSet副本数量: + +```shell +kubectl scale statefulsets --replicas= +``` + +### 可使用其他命令: `kubectl apply` / `kubectl edit` / `kubectl patch` + +另外, 您可以 [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) StatefulSets. + +如果您的StatefulSet开始由 `kubectl apply` 或 `kubectl create --save-config` 创建,更新StatefulSet manifests中的 `.spec.replicas`, 然后执行命令 `kubectl apply`: + +```shell +kubectl apply -f +``` + +除此之外, 可以通过命令 `kubectl edit` 编辑该字段: + +```shell +kubectl edit statefulsets +``` + +或使用 `kubectl patch`: + +```shell +kubectl patch statefulsets -p '{"spec":{"replicas":}}' +``` + +## 排查故障 + +### 缩容工作不正常 + +当Stateful管理下的任何一个Pod不健康时您不能缩容该StatefulSet. 仅当Stateful下的所有Pods都处于运行和ready状态后才可缩容. + +当一个StatefulSet的size > 1, 如果有一个Pod不健康, 没有办法让Kubernetes知道是否是由于永久性故障还是瞬态(升级/维护/节点重启)导致. 如果该Pod不健康是由于永久性 +故障导致, 则在不纠正该故障的情况下进行缩容可能会导致一种状态， 即StatefulSet下的Pod数量低于应正常运行的副本数. 这也许会导致StatefulSet不可用. + +如果由于瞬态故障而导致Pod不健康,并且Pod可能再次可用，那么瞬态错误可能会干扰您对 +StatefulSet的扩容/缩容操作. 一些分布式数据库在节点加入和同时离开时存在问题. 在 +这些情况下，最好是在应用级别进行弹缩操作, 并且只有在您确保Stateful应用的集群是完全健康时才执行弹缩. + + +{% endcapture %} + +{% capture whatsnext %} + +了解更多 [deleting a StatefulSet](/docs/tasks/manage-stateful-set/deleting-a-statefulset/). + +{% endcapture %} + +{% include templates/task.md %} diff --git a/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml b/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml index 2253600de6..ce3eb1bf74 100644 --- a/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml +++ b/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml @@ -25,13 +25,17 @@ spec: requests: storage: 20Gi --- -apiVersion: extensions/v1beta1 +apiVersion: apps/v1beta2 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress spec: + selector: + matchLabels: + app: wordpress + tier: mysql strategy: type: Recreate template: diff --git a/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml b/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml index e15edc5998..c354cdef88 100644 --- a/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml +++ b/cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml @@ -25,13 +25,17 @@ spec: requests: storage: 20Gi --- -apiVersion: extensions/v1beta1 +apiVersion: apps/v1beta2 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: + selector: + matchLabels: + app: wordpress + tier: frontend strategy: type: Recreate template: diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index e7aa991c45..a64014c2f1 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -549,7 +549,7 @@ checked. Keystone authentication is enabled by passing the `--experimental-keystone-url=` option to the API server during startup. The plugin is implemented in `plugin/pkg/auth/authenticator/password/keystone/keystone.go` and currently uses -basic auth to verify used by username and password. +basic auth to verify user by username and password. If you have configured self-signed certificates for the Keystone server, you may need to set the `--experimental-keystone-ca-file=SOMEFILE` option when diff --git a/docs/admin/authorization/rbac.md b/docs/admin/authorization/rbac.md index 0ba2e6ece4..56260e13d9 100644 --- a/docs/admin/authorization/rbac.md +++ b/docs/admin/authorization/rbac.md @@ -102,7 +102,7 @@ This allows administrators to define a set of common roles for the entire cluste then reuse them within multiple namespaces. For instance, even though the following `RoleBinding` refers to a `ClusterRole`, -"dave" (the subject) will only be able read secrets in the "development" +"dave" (the subject) will only be able to read secrets in the "development" namespace (the namespace of the `RoleBinding`). ```yaml @@ -181,7 +181,7 @@ metadata: name: configmap-updater rules: - apiGroups: [""] - resources: ["configmap"] + resources: ["configmaps"] resourceNames: ["my-configmap"] verbs: ["update", "get"] ``` @@ -258,7 +258,7 @@ A `RoleBinding` or `ClusterRoleBinding` binds a role to *subjects*. Subjects can be groups, users or service accounts. Users are represented by strings. These can be plain usernames, like -"alice", email-style names, like "bob@example.com", or numeric ids +"alice", email-style names, like "bob@example.com", or numeric IDs represented as a string. It is up to the Kubernetes admin to configure the [authentication modules](/docs/admin/authentication/) to produce usernames in the desired format. The RBAC authorization system does diff --git a/docs/admin/kube-proxy.md b/docs/admin/kube-proxy.md index 167b9f3d6c..6e6551af65 100644 --- a/docs/admin/kube-proxy.md +++ b/docs/admin/kube-proxy.md @@ -11,7 +11,7 @@ notitle: true The Kubernetes network proxy runs on each node. This reflects services as defined in the Kubernetes API on each node and can do simple -TCP,UDP stream forwarding or round robin TCP,UDP forwarding across a set of backends. +TCP, UDP stream forwarding or round robin TCP, UDP forwarding across a set of backends. Service cluster IPs and ports are currently found through Docker-links-compatible environment variables specifying ports opened by the service proxy. There is an optional addon that provides cluster DNS for these cluster IPs. The user must create a service diff --git a/docs/concepts/architecture/nodes.md b/docs/concepts/architecture/nodes.md index 328a71ef56..443a356970 100644 --- a/docs/concepts/architecture/nodes.md +++ b/docs/concepts/architecture/nodes.md @@ -51,6 +51,7 @@ The `conditions` field describes the status of all `Running` nodes. | `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last 40 seconds | | `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` | | `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` | +| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` | The node condition is represented as a JSON object. For example, the following response describes a healthy node. diff --git a/docs/concepts/cluster-administration/addons.md b/docs/concepts/cluster-administration/addons.md index 53b94997dc..eb62a0795e 100644 --- a/docs/concepts/cluster-administration/addons.md +++ b/docs/concepts/cluster-administration/addons.md @@ -21,6 +21,10 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Flannel, Calico, Canal, Romana, or Weave. +## Service Discovery + +* [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods. + ## Visualization & Control * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. diff --git a/docs/concepts/cluster-administration/cloud-providers.md b/docs/concepts/cluster-administration/cloud-providers.md index e0b60896dd..4c0034efb9 100644 --- a/docs/concepts/cluster-administration/cloud-providers.md +++ b/docs/concepts/cluster-administration/cloud-providers.md @@ -44,7 +44,7 @@ Different settings can be applied to a load balancer service in AWS using _annot * `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix. * `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`. * `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used. -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining. * `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout. * `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout. diff --git a/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 3fd78f0ac4..78a63da117 100644 --- a/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -50,7 +50,7 @@ credentials of the user listed in the current context. ## The KUBECONFIG environment variable -The `KUBECONGIG` environment variable holds a list of kubeconfig files. +The `KUBECONFIG` environment variable holds a list of kubeconfig files. For Linux and Mac, the list is colon-delimited. For Windows, the list is semicolon-delimited. The `KUBECONFIG` environment variable is not required. If the `KUBECONFIG` environment variable doesn't exist, diff --git a/docs/concepts/configuration/secret.md b/docs/concepts/configuration/secret.md index 23a1dc1401..102eee8648 100644 --- a/docs/concepts/configuration/secret.md +++ b/docs/concepts/configuration/secret.md @@ -182,32 +182,23 @@ To consume a Secret in a volume in a Pod: This is an example of a pod that mounts a secret in a volume: -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo", - "readOnly": true - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret" - } - }] - } -} +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret ``` Each secret you want to use needs to be referred to in `spec.volumes`. @@ -222,36 +213,26 @@ You can package many files into one secret, or use many secrets, whichever is co We can also control the paths within the volume where Secret keys are projected. You can use `spec.volumes[].secret.items` field to change target path of each key: -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo", - "readOnly": true - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret", - "items": [{ - "key": "username", - "path": "my-group/my-username" - }] - } - }] - } -} +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username ``` What will happen: @@ -271,32 +252,23 @@ mode for the whole secret volume and override per key if needed. For example, you can specify a default mode like this: -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo" - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret", - "defaultMode": 256 - } - }] - } -} +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + defaultMode: 256 ``` Then, the secret will be mounted on `/etc/foo` and all the files created by the @@ -309,36 +281,26 @@ notation to specify permissions in a more natural way. You can also use mapping, as in the previous example, and specify different permission for different files like this: -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo" - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret", - "items": [{ - "key": "username", - "path": "my-group/my-username", - "mode": 511 - }] - } - }] - } -} +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + volumes: + - name: foo + secret: + secretName: mysecret + items: + - key: username + path: my-group/my-username + mode: 511 ``` In this case, the file resulting in `/etc/foo/my-group/my-username` will have @@ -393,19 +355,19 @@ metadata: name: secret-env-pod spec: containers: - - name: mycontainer - image: redis - env: - - name: SECRET_USERNAME - valueFrom: - secretKeyRef: - name: mysecret - key: username - - name: SECRET_PASSWORD - valueFrom: - secretKeyRef: - name: mysecret - key: password + - name: mycontainer + image: redis + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: SECRET_PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password restartPolicy: Never ``` @@ -515,40 +477,25 @@ $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/ Now we can create a pod which references the secret with the ssh key and consumes it in a volume: -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "secret-test-pod", - "labels": { - "name": "secret-test" - } - }, - "spec": { - "volumes": [ - { - "name": "secret-volume", - "secret": { - "secretName": "ssh-key-secret" - } - } - ], - "containers": [ - { - "name": "ssh-test-container", - "image": "mySshImage", - "volumeMounts": [ - { - "name": "secret-volume", - "readOnly": true, - "mountPath": "/etc/secret-volume" - } - ] - } - ] - } -} +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: secret-test-pod + labels: + name: secret-test +spec: + volumes: + - name: secret-volume + secret: + secretName: ssh-key-secret + containers: + - name: ssh-test-container + image: mySshImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" ``` When the container's command runs, the pieces of the key will be available in: @@ -577,78 +524,46 @@ secret "test-db-secret" created Now make the pods: -```json -{ - "apiVersion": "v1", - "kind": "List", - "items": - [{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "prod-db-client-pod", - "labels": { - "name": "prod-db-client" - } - }, - "spec": { - "volumes": [ - { - "name": "secret-volume", - "secret": { - "secretName": "prod-db-secret" - } - } - ], - "containers": [ - { - "name": "db-client-container", - "image": "myClientImage", - "volumeMounts": [ - { - "name": "secret-volume", - "readOnly": true, - "mountPath": "/etc/secret-volume" - } - ] - } - ] - } - }, - { - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "test-db-client-pod", - "labels": { - "name": "test-db-client" - } - }, - "spec": { - "volumes": [ - { - "name": "secret-volume", - "secret": { - "secretName": "test-db-secret" - } - } - ], - "containers": [ - { - "name": "db-client-container", - "image": "myClientImage", - "volumeMounts": [ - { - "name": "secret-volume", - "readOnly": true, - "mountPath": "/etc/secret-volume" - } - ] - } - ] - } - }] -} +```yaml +apiVersion: v1 +kind: List +items: +- kind: Pod + apiVersion: v1 + metadata: + name: prod-db-client-pod + labels: + name: prod-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: prod-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" +- kind: Pod + apiVersion: v1 + metadata: + name: test-db-client-pod + labels: + name: test-db-client + spec: + volumes: + - name: secret-volume + secret: + secretName: test-db-secret + containers: + - name: db-client-container + image: myClientImage + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" ``` Both containers will have the following files present on their filesystems with the values for each container's environment: @@ -665,26 +580,18 @@ You could further simplify the base pod specification by using two Service Accou one called, say, `prod-user` with the `prod-db-secret`, and one called, say, `test-user` with the `test-db-secret`. Then, the pod spec can be shortened to, for example: -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "prod-db-client-pod", - "labels": { - "name": "prod-db-client" - } - }, - "spec": { - "serviceAccount": "prod-db-client", - "containers": [ - { - "name": "db-client-container", - "image": "myClientImage" - } - ] - } -} +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: prod-db-client-pod + labels: + name: prod-db-client +spec: + serviceAccount: prod-db-client + containers: + - name: db-client-container + image: myClientImage ``` ### Use-case: Dotfiles in secret volume @@ -692,49 +599,34 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say, In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply make that key begin with a dot. For example, when the following secret is mounted into a volume: -```json -{ - "kind": "Secret", - "apiVersion": "v1", - "metadata": { - "name": "dotfile-secret" - }, - "data": { - ".secret-file": "dmFsdWUtMg0KDQo=" - } -} - -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "secret-dotfiles-pod" - }, - "spec": { - "volumes": [ - { - "name": "secret-volume", - "secret": { - "secretName": "dotfile-secret" - } - } - ], - "containers": [ - { - "name": "dotfile-test-container", - "image": "gcr.io/google_containers/busybox", - "command": [ "ls", "-l", "/etc/secret-volume" ], - "volumeMounts": [ - { - "name": "secret-volume", - "readOnly": true, - "mountPath": "/etc/secret-volume" - } - ] - } - ] - } -} +```yaml +kind: Secret +apiVersion: v1 +metadata: + name: dotfile-secret +data: + .secret-file: dmFsdWUtMg0KDQo= +--- +kind: Pod +apiVersion: v1 +metadata: + name: secret-dotfiles-pod +spec: + volumes: + - name: secret-volume + secret: + secretName: dotfile-secret + containers: + - name: dotfile-test-container + image: gcr.io/google_containers/busybox + command: + - ls + - "-l" + - "/etc/secret-volume" + volumeMounts: + - name: secret-volume + readOnly: true + mountPath: "/etc/secret-volume" ``` @@ -798,7 +690,7 @@ reference a secret then `watch` the resource, re-requesting the secret when the reference changes. Additionally, a ["bulk watch" API]( https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) to let clients `watch` individual resources has also been proposed, and will likely -be available in future releases of Kubernetes. +be available in future releases of Kubernetes. ## Security Properties diff --git a/docs/concepts/services-networking/service.md b/docs/concepts/services-networking/service.md index e1403ca9af..653e10aeb3 100644 --- a/docs/concepts/services-networking/service.md +++ b/docs/concepts/services-networking/service.md @@ -479,25 +479,25 @@ metadata: {% include tabs.md %} #### SSL support on AWS -For partial SSL support on clusters running on AWS, starting with 1.3 two +For partial SSL support on clusters running on AWS, starting with 1.3 three annotations can be added to a `LoadBalancer` service: ``` - metadata: - name: my-service - annotations: - service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 ``` -The first specifies which certificate to use. It can be either a +The first specifies the ARN of the certificate to use. It can be either a certificate from a third party issuer that was uploaded to IAM or one created within AWS Certificate Manager. ```yaml - metadata: - name: my-service - annotations: - service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp) +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp) ``` The second annotation specifies which protocol a pod speaks. For HTTPS and diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md index 0f88d967f2..9f2c141e88 100644 --- a/docs/concepts/storage/persistent-volumes.md +++ b/docs/concepts/storage/persistent-volumes.md @@ -86,7 +86,7 @@ However, an administrator can configure a custom recycler pod template using the apiVersion: v1 kind: Pod metadata: - name: pv-recycler- + name: pv-recycler namespace: default spec: restartPolicy: Never @@ -128,7 +128,7 @@ For volume plugins that support the Delete reclaim policy, deletion removes both * Glusterfs * VsphereVolume * Quobyte Volumes -* HostPath (single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster) +* HostPath (Single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster) * VMware Photon * Portworx Volumes * ScaleIO Volumes @@ -223,7 +223,7 @@ it will become fully deprecated in a future Kubernetes release. Current reclaim policies are: * Retain -- manual reclamation -* Recycle -- basic scrub ("rm -rf /thevolume/*") +* Recycle -- basic scrub (`rm -rf /thevolume/*`) * Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion. @@ -232,7 +232,7 @@ Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node. -**Note:** Not all Persistent volume types support mount options. +**Note:** Not all Persistent volume types support mount options. {: .note} The following volume types support mount options: @@ -341,7 +341,7 @@ to Kubernetes cluster by addon manager during installation. When a PVC specifies a `selector` in addition to requesting a `StorageClass`, the requirements are ANDed together: only a PV of the requested class and with -the requested labels may be bound to the PVC. +the requested labels may be bound to the PVC. **Note:** Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it. {: .note} @@ -574,6 +574,7 @@ parameters: #### vSphere 1. Create a persistent volume with a user specified disk format. + ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 @@ -587,9 +588,10 @@ parameters: - `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`. 2. Create a persistent volume with a disk format on a user specified datastore. + ```yaml kind: StorageClass -apiVersion: storage.k8s.io/v1beta1 +apiVersion: storage.k8s.io/v1 metadata: name: fast provisioner: kubernetes.io/vsphere-volume @@ -602,9 +604,10 @@ parameters: - `datastore`: The user can also specify the datastore in the Storageclass. The volume will be created on the datastore specified in the storage class which in this case is `VSANDatastore`. This field is optional. If not specified as in previous YAML description, the volume will be created on the datastore specified in the vsphere config file used to initialize the vSphere Cloud Provider. 3. Create a persistent volume with user specified VSAN storage capabilities. + ```yaml kind: StorageClass -apiVersion: storage.k8s.io/v1beta1 +apiVersion: storage.k8s.io/v1 metadata: name: vsan-policy-fast provisioner: kubernetes.io/vsphere-volume @@ -636,22 +639,22 @@ You can see [vSphere example](https://github.com/kubernetes/examples/tree/master #### Ceph RBD ```yaml - apiVersion: storage.k8s.io/v1 - kind: StorageClass - metadata: - name: fast - provisioner: kubernetes.io/rbd - parameters: - monitors: 10.16.153.105:6789 - adminId: kube - adminSecretName: ceph-secret - adminSecretNamespace: kube-system - pool: kube - userId: kube - userSecretName: ceph-secret-user - fsType: ext4 - imageFormat: "2" - imageFeatures: "layering" +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: kubernetes.io/rbd +parameters: + monitors: 10.16.153.105:6789 + adminId: kube + adminSecretName: ceph-secret + adminSecretNamespace: kube-system + pool: kube + userId: kube + userSecretName: ceph-secret-user + fsType: ext4 + imageFormat: "2" + imageFeatures: "layering" ``` * `monitors`: Ceph monitors, comma delimited. This parameter is required. @@ -782,6 +785,7 @@ parameters: * `ephemeral`: specifies whether the volume should be cleaned-up after unmount or should be persistent. `emptyDir` use case can set this value to true and `persistent volumes` use case such as for databases like Cassandra should set to false, [true/false] (default `false`). A string is expected here i.e. `"true"` and not `true`. #### ScaleIO + ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 @@ -818,6 +822,7 @@ $> kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" --fro ``` #### StorageOS + ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md index 05658d0c6b..d79e967928 100644 --- a/docs/concepts/storage/volumes.md +++ b/docs/concepts/storage/volumes.md @@ -851,4 +851,8 @@ several media types. {% endcapture %} +{% capture whatsnext %} +* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). +{% endcapture %} + {% include templates/concept.md %} diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index 0312a6390f..51b395fd62 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -41,15 +41,18 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up In this example: -* A Deployment named `nginx` is created. -* The `nginx` Deployment creates three replicated Pods. -* The Pods are created from the `template` field. +* A Deployment named `nginx` is created, indicated by the `metadata: name` field. +* The Deployment creates three replicated Pods, indicated by the `replicas` field. +* The Pod template's specification, or `template: spec` field, indicates that + the Pods run one container, `nginx`, which runs the `nginx` + [Docker Hub](https://hub.docker.com/) image at version 1.7.9. +* The Deployment opens port 80 for use by the Pods. The `template` field contains the following instructions: -* Create one container in each Pod. -* Label the container `app: nginx`. -* Run the [Docker Hub](https://hub.docker.com) image `nginx` at version `1.7.9`. +* The Pods are labeled `app: nginx` +* Create one container and name it `nginx`. +* Run the `nginx` image at version `1.7.9`. * Open port `80` so that the container can send and accept traffic. To create this Deployment, run the following command: @@ -112,7 +115,7 @@ NAME DESIRED CURRENT READY AGE nginx-deployment-2035384211 3 3 3 18s ``` -Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPALTE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created. +Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created. To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned: diff --git a/docs/concepts/workloads/controllers/statefulset.md b/docs/concepts/workloads/controllers/statefulset.md index 52168247c7..e06551d6d4 100644 --- a/docs/concepts/workloads/controllers/statefulset.md +++ b/docs/concepts/workloads/controllers/statefulset.md @@ -226,6 +226,7 @@ update, roll out a canary, or perform a phased roll out. {% capture whatsnext %} * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set). +* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). {% endcapture %} {% include templates/concept.md %} diff --git a/docs/concepts/workloads/pods/init-containers.md b/docs/concepts/workloads/pods/init-containers.md index 0ed404a667..037873b284 100644 --- a/docs/concepts/workloads/pods/init-containers.md +++ b/docs/concepts/workloads/pods/init-containers.md @@ -151,7 +151,7 @@ spec: Yaml file below outlines the `mydb` and `myservice` services: -``` +```yaml kind: Service apiVersion: v1 metadata: @@ -175,7 +175,7 @@ spec: This Pod can be started and debugged with the following commands: -``` +```shell $ kubectl create -f myapp.yaml pod "myapp-pod" created $ kubectl get -f myapp.yaml @@ -221,7 +221,7 @@ $ kubectl logs myapp-pod -c init-mydb # Inspect the second init container Once we start the `mydb` and `myservice` services, we can see the Init Containers complete and the `myapp-pod` is created: -``` +```shell $ kubectl create -f services.yaml service "myservice" created service "mydb" created diff --git a/docs/getting-started-guides/coreos/bare_metal_offline.md b/docs/getting-started-guides/coreos/bare_metal_offline.md index a471d2db8d..c7684f73b2 100644 --- a/docs/getting-started-guides/coreos/bare_metal_offline.md +++ b/docs/getting-started-guides/coreos/bare_metal_offline.md @@ -42,154 +42,134 @@ To setup CentOS PXELINUX environment there is a complete [guide here](http://doc 1. Install packages needed on CentOS -```shell -sudo yum install tftp-server dhcp syslinux -``` + sudo yum install tftp-server dhcp syslinux 2. `vi /etc/xinetd.d/tftp` to enable tftp service and change disable to 'no' -```conf -disable = no -``` + -disable = no 3. Copy over the syslinux images we will need. -```shell -su - -mkdir -p /tftpboot -cd /tftpboot -cp /usr/share/syslinux/pxelinux.0 /tftpboot -cp /usr/share/syslinux/menu.c32 /tftpboot -cp /usr/share/syslinux/memdisk /tftpboot -cp /usr/share/syslinux/mboot.c32 /tftpboot -cp /usr/share/syslinux/chain.c32 /tftpboot + su - + mkdir -p /tftpboot + cd /tftpboot + cp /usr/share/syslinux/pxelinux.0 /tftpboot + cp /usr/share/syslinux/menu.c32 /tftpboot + cp /usr/share/syslinux/memdisk /tftpboot + cp /usr/share/syslinux/mboot.c32 /tftpboot + cp /usr/share/syslinux/chain.c32 /tftpboot -/sbin/service dhcpd start -/sbin/service xinetd start -/sbin/chkconfig tftp on -``` + /sbin/service dhcpd start + /sbin/service xinetd start + /sbin/chkconfig tftp on 4. Setup default boot menu -```shell -mkdir /tftpboot/pxelinux.cfg -touch /tftpboot/pxelinux.cfg/default -``` + mkdir /tftpboot/pxelinux.cfg + touch /tftpboot/pxelinux.cfg/default 5. Edit the menu `vi /tftpboot/pxelinux.cfg/default` -```conf -default menu.c32 -prompt 0 -timeout 15 -ONTIMEOUT local -display boot.msg + default menu.c32 + prompt 0 + timeout 15 + ONTIMEOUT local + display boot.msg -MENU TITLE Main Menu + MENU TITLE Main Menu -LABEL local - MENU LABEL Boot local hard drive - LOCALBOOT 0 -``` + LABEL local + MENU LABEL Boot local hard drive + LOCALBOOT 0 Now you should have a working PXELINUX setup to image CoreOS nodes. You can verify the services by using VirtualBox locally or with bare metal servers. ## Adding CoreOS to PXE This section describes how to setup the CoreOS images to live alongside a pre-existing PXELINUX environment. - 1. Find or create the TFTP root directory that everything will be based on. - * For this document we will assume `/tftpboot/` is our root directory. -2. Once we know and have our tftp root directory we will create a new directory structure for our CoreOS images. + - For this document we will assume `/tftpboot/` is our root directory. +2. Once we know and have our tftp root directory we will create a new directory structure for our CoreOS images. 3. Download the CoreOS PXE files provided by the CoreOS team. -```shell -MY_TFTPROOT_DIR=/tftpboot -mkdir -p $MY_TFTPROOT_DIR/images/coreos/ -cd $MY_TFTPROOT_DIR/images/coreos/ -wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz -wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz.sig -wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz -wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz.sig -gpg --verify coreos_production_pxe.vmlinuz.sig -gpg --verify coreos_production_pxe_image.cpio.gz.sig -``` + MY_TFTPROOT_DIR=/tftpboot + mkdir -p $MY_TFTPROOT_DIR/images/coreos/ + cd $MY_TFTPROOT_DIR/images/coreos/ + wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz + wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz.sig + wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz + wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz.sig + gpg --verify coreos_production_pxe.vmlinuz.sig + gpg --verify coreos_production_pxe_image.cpio.gz.sig 4. Edit the menu `vi /tftpboot/pxelinux.cfg/default` again -```conf -default menu.c32 -prompt 0 -timeout 300 -ONTIMEOUT local -display boot.msg + default menu.c32 + prompt 0 + timeout 300 + ONTIMEOUT local + display boot.msg -MENU TITLE Main Menu + MENU TITLE Main Menu -LABEL local - MENU LABEL Boot local hard drive - LOCALBOOT 0 + LABEL local + MENU LABEL Boot local hard drive + LOCALBOOT 0 -MENU BEGIN CoreOS Menu + MENU BEGIN CoreOS Menu - LABEL coreos-master - MENU LABEL CoreOS Master - KERNEL images/coreos/coreos_production_pxe.vmlinuz - APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-single-master.yml + LABEL coreos-master + MENU LABEL CoreOS Master + KERNEL images/coreos/coreos_production_pxe.vmlinuz + APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-single-master.yml - LABEL coreos-slave - MENU LABEL CoreOS Slave - KERNEL images/coreos/coreos_production_pxe.vmlinuz - APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-slave.yml -MENU END -``` + LABEL coreos-slave + MENU LABEL CoreOS Slave + KERNEL images/coreos/coreos_production_pxe.vmlinuz + APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-slave.yml + MENU END This configuration file will now boot from local drive but have the option to PXE image CoreOS. ## DHCP configuration This section covers configuring the DHCP server to hand out our new images. In this case we are assuming that there are other servers that will boot alongside other images. - 1. Add the `filename` to the _host_ or _subnet_ sections. -```conf -filename "/tftpboot/pxelinux.0"; -``` + filename "/tftpboot/pxelinux.0"; 2. At this point we want to make pxelinux configuration files that will be the templates for the different CoreOS deployments. -```conf -subnet 10.20.30.0 netmask 255.255.255.0 { - next-server 10.20.30.242; - option broadcast-address 10.20.30.255; - filename ""; + subnet 10.20.30.0 netmask 255.255.255.0 { + next-server 10.20.30.242; + option broadcast-address 10.20.30.255; + filename ""; - ... - # http://www.syslinux.org/wiki/index.php/PXELINUX - host core_os_master { - hardware ethernet d0:00:67:13:0d:00; - option routers 10.20.30.1; - fixed-address 10.20.30.40; - option domain-name-servers 10.20.30.242; - filename "/pxelinux.0"; + ... + # http://www.syslinux.org/wiki/index.php/PXELINUX + host core_os_master { + hardware ethernet d0:00:67:13:0d:00; + option routers 10.20.30.1; + fixed-address 10.20.30.40; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + host core_os_slave { + hardware ethernet d0:00:67:13:0d:01; + option routers 10.20.30.1; + fixed-address 10.20.30.41; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + host core_os_slave2 { + hardware ethernet d0:00:67:13:0d:02; + option routers 10.20.30.1; + fixed-address 10.20.30.42; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + ... } - host core_os_slave { - hardware ethernet d0:00:67:13:0d:01; - option routers 10.20.30.1; - fixed-address 10.20.30.41; - option domain-name-servers 10.20.30.242; - filename "/pxelinux.0"; - } - host core_os_slave2 { - hardware ethernet d0:00:67:13:0d:02; - option routers 10.20.30.1; - fixed-address 10.20.30.42; - option domain-name-servers 10.20.30.242; - filename "/pxelinux.0"; - } - ... -} -``` We will be specifying the node configuration later in the guide. diff --git a/docs/getting-started-guides/kops.md b/docs/getting-started-guides/kops.md index a8720aa46e..e4a030584e 100644 --- a/docs/getting-started-guides/kops.md +++ b/docs/getting-started-guides/kops.md @@ -34,7 +34,7 @@ Download kops from the [releases page](https://github.com/kubernetes/kops/releas On MacOS: ``` -wget https://github.com/kubernetes/kops/releases/download/1.6.1/kops-darwin-amd64 +wget https://github.com/kubernetes/kops/releases/download/1.7.0/kops-darwin-amd64 chmod +x kops-darwin-amd64 mv kops-darwin-amd64 /usr/local/bin/kops # you can also install using Homebrew @@ -44,7 +44,7 @@ brew update && brew install kops On Linux: ``` -wget https://github.com/kubernetes/kops/releases/download/1.6.1/kops-linux-amd64 +wget https://github.com/kubernetes/kops/releases/download/1.7.0/kops-linux-amd64 chmod +x kops-linux-amd64 mv kops-linux-amd64 /usr/local/bin/kops ``` diff --git a/docs/getting-started-guides/kubespray.md b/docs/getting-started-guides/kubespray.md index eee97f6a2a..9ceb1b5af9 100644 --- a/docs/getting-started-guides/kubespray.md +++ b/docs/getting-started-guides/kubespray.md @@ -21,15 +21,15 @@ To choose a tool which best fits your use case, read [this comparison](https://g Provision servers with the following requirements: -* `Ansible v2.3` (or newer) -* `Jinja 2.9` (or newer) +* `Ansible v2.3` (or newer) +* `Jinja 2.9` (or newer) * `python-netaddr` installed on the machine that running Ansible commands * Target servers must have access to the Internet in order to pull docker images * Target servers are configured to allow IPv4 forwarding * Target servers have SSH connectivity ( tcp/22 ) directly to your nodes or through a bastion host/ssh jump box * Target servers have a privileged user * Your SSH key must be copied to all the servers that are part of your inventory -* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate +* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate * If using a cloud provider, you must have the appropriate credentials available and exported as environment variables Kubespray provides the following utilities to help provision your environment: @@ -44,7 +44,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) Compose an inventory file -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) Plan your cluster deployment @@ -65,10 +65,10 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co Next, deploy your cluster with one of two methods: * [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment). -* [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md) +* [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md) **Note:** kubespray-cli is no longer actively maintained. -{. :note} +{: .note} Both methods run the default [cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml). @@ -84,11 +84,11 @@ 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 -You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". +You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)". ## What's next @@ -99,7 +99,7 @@ Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-in You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml). **Caution:** When running the reset playbook, be sure not to accidentally target your production cluster! -{. :caution} +{: .caution} ## Feedback diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index 7bcb341e73..4c067f8d65 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -59,7 +59,7 @@ You can test it with the following command: virsh -c qemu:///system pool-list ``` -If you have access error messages, please read https://libvirt.org/acl.html and https://libvirt.org/aclpolkit.html . +If you have access error messages, please read [https://libvirt.org/acl.html](https://libvirt.org/acl.html) and [https://libvirt.org/aclpolkit.html](https://libvirt.org/aclpolkit.html). In short, if your libvirt has been compiled with Polkit support (ex: Arch, Fedora 21), you can create `/etc/polkit-1/rules.d/50-org.libvirt.unix.manage.rules` as follows to grant full access to libvirt to `$USER` @@ -125,7 +125,7 @@ There is both an automated way and a manual, customizable way of setting up libv #### Automated setup -There is an automated setup script on https://get.k8s.io that will download the tarball for Kubernetes and spawn a Kubernetes cluster on a local CoreOS instances that the script creates. To run this script, use wget or curl with the KUBERNETES_PROVIDER environment variable set to libvirt-coreos: +There is an automated setup script on [https://get.k8s.io]( https://get.k8s.io ) that will download the tarball for Kubernetes and spawn a Kubernetes cluster on a local CoreOS instances that the script creates. To run this script, use wget or curl with the KUBERNETES_PROVIDER environment variable set to libvirt-coreos: ```shell export KUBERNETES_PROVIDER=libvirt-coreos; wget -q -O - https://get.k8s.io | bash diff --git a/docs/getting-started-guides/photon-controller.md b/docs/getting-started-guides/photon-controller.md index 45e4251565..ecdaf13f82 100644 --- a/docs/getting-started-guides/photon-controller.md +++ b/docs/getting-started-guides/photon-controller.md @@ -22,13 +22,13 @@ setup: the actual creation of the cluster can be done by anyone.) needs to be installed on the machine on which you'll be running kube-up. If you have go installed, this can be easily installed with: - go get github.com/vmware/photon-controller-cli/photon + go get github.com/vmware/photon-controller-cli/photon 3. `mkisofs` needs to be installed. The installation process creates a CD-ROM ISO image to bootstrap the VMs with cloud-init. If you are on a Mac, you can install this with [brew](http://brew.sh/): - brew install cdrtools + brew install cdrtools 4. Several common tools need to be installed: `ssh`, `scp`, `openssl` diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index de475a07bb..eebdebb78b 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -68,20 +68,20 @@ another pod using the IP of the second pod. This connectivity can be accomplished in two ways: - **Using an overlay network** - - An overlay network obscures the underlying network architecture from the + - An overlay network obscures the underlying network architecture from the pod network through traffic encapsulation (e.g. vxlan). - Encapsulation reduces performance, though exactly how much depends on your solution. - **Without an overlay network** - Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses. - - This does not require the encapsulation provided by an overlay, and so can achieve + - This does not require the encapsulation provided by an overlay, and so can achieve better performance. -Which method you choose depends on your environment and requirements. There are various ways -to implement one of the above options: +Which method you choose depends on your environment and requirements. There are various ways +to implement one of the above options: - **Use a network plugin which is called by Kubernetes** - Kubernetes supports the [CNI](https://github.com/containernetworking/cni) network plugin interface. - - There are a number of solutions which provide plugins for Kubernetes (listed alphabetically): + - There are a number of solutions which provide plugins for Kubernetes (listed alphabetically): - [Calico](http://docs.projectcalico.org/) - [Flannel](https://github.com/coreos/flannel) - [Open vSwitch (OVS)](http://openvswitch.org/) @@ -628,7 +628,6 @@ Here are some apiserver flags you may need to set: - `--cloud-provider=` see [cloud providers](#cloud-providers) - `--cloud-config=` see [cloud providers](#cloud-providers) - `--address=${MASTER_IP}` *or* `--bind-address=127.0.0.1` and `--address=127.0.0.1` if you want to run a proxy on the master node. -- `--cluster-name=$CLUSTER_NAME` - `--service-cluster-ip-range=$SERVICE_CLUSTER_IP_RANGE` - `--etcd-servers=http://127.0.0.1:4001` - `--tls-cert-file=/srv/kubernetes/server.cert` @@ -792,7 +791,6 @@ Template for controller manager pod: Flags to consider using with controller manager: - - `--cluster-name=$CLUSTER_NAME` - `--cluster-cidr=`, the CIDR range for pods in cluster. - `--allocate-node-cidrs=`, if you are using `--cloud-provider=`, allocate and set the CIDRs for pods on the cloud provider. - `--cloud-provider=` and `--cloud-config` as described in apiserver section. diff --git a/docs/getting-started-guides/ubuntu/manual.md b/docs/getting-started-guides/ubuntu/manual.md deleted file mode 100644 index 7957e10bef..0000000000 --- a/docs/getting-started-guides/ubuntu/manual.md +++ /dev/null @@ -1,308 +0,0 @@ ---- -approvers: -- thockin -title: Manually Deploying Kubernetes on Ubuntu Nodes ---- - -{% capture overview %} -This document describes how to deploy Kubernetes on ubuntu nodes, 1 master and 3 nodes involved -in the given examples. You can scale to **any number of nodes** by changing some settings with ease. -The original idea was heavily inspired by @jainvipin 's ubuntu single node -work, which has been merge into this document. -{% endcapture %} - -The scripting referenced here can be used to deploy Kubernetes with -networking based either on Flannel or on a CNI plugin that you supply. -This document is focused on the Flannel case. See -`kubernetes/cluster/ubuntu/config-default.sh` for remarks on how to -use a CNI plugin instead. - -[Cloud team from Zhejiang University](https://github.com/ZJU-SEL) will maintain this work. - -{% capture prerequisites %} -## Prerequisites - -1. The nodes have installed docker version 1.2+ and bridge-utils to manipulate linux bridge. -2. All machines can communicate with each other. Master node needs to be connected to the -Internet to download the necessary files, while worker nodes do not. -3. These guide is tested OK on Ubuntu 14.04 LTS 64bit server, but it can not work with -Ubuntu 15 which uses systemd instead of upstart. -4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.2.0, may work with higher versions. -5. All the remote servers can be ssh logged in without a password by using key authentication. -6. The remote user on all machines is using /bin/bash as its login shell, and has sudo access. -{% endcapture %} - -{% capture steps %} -## Starting a Cluster - -### Set up working directory - -Clone the Kubernetes github repo locally - -```shell -$ git clone --depth 1 https://github.com/kubernetes/kubernetes.git -``` - -#### Configure and start the Kubernetes cluster - -The startup process will first download all the required binaries automatically. -By default etcd version is 2.2.1, flannel version is 0.5.5 and k8s version is 1.2.0. -You can customize your etcd version, flannel version, k8s version by changing corresponding variables -`ETCD_VERSION` , `FLANNEL_VERSION` and `KUBE_VERSION` like following. - -```shell -$ export KUBE_VERSION=1.2.0 -$ export FLANNEL_VERSION=0.5.0 -$ export ETCD_VERSION=2.2.0 -``` - -**Note** - -For users who want to bring up a cluster with k8s version v1.1.1, `controller manager` may fail to start -due to [a known issue](https://github.com/kubernetes/kubernetes/issues/17109). You could raise it -up manually by using following command on the remote master server. Note that -you should do this only after `api-server` is up. Moreover, this issue is fixed in v1.1.2 and later. - -```shell -$ sudo service kube-controller-manager start -``` - -Note that we use flannel here to set up overlay network, yet it's optional. Actually you can build up k8s -cluster natively, or use flannel, Open vSwitch or any other SDN tool you like. - -An example cluster is listed below: - -```shell -| IP Address | Role | -|-------------|----------| -|10.10.103.223| node | -|10.10.103.162| node | -|10.10.103.250| both master and node| -``` - -First configure the cluster information in cluster/ubuntu/config-default.sh, following is a simple sample. - -```shell -export nodes="vcap@10.10.103.250 vcap@10.10.103.162 vcap@10.10.103.223" - -export roles="ai i i" - -export NUM_NODES=${NUM_NODES:-3} - -export SERVICE_CLUSTER_IP_RANGE=192.168.3.0/24 - -export FLANNEL_NET=172.16.0.0/16 -``` - -The first variable `nodes` defines all your cluster nodes, master node comes first and -separated with blank space like ` ` - -Then the `roles` variable defines the roles of above machine in the same order, "ai" stands for machine -acts as both master and node, "a" stands for master, "i" stands for node. - -The `NUM_NODES` variable defines the total number of nodes. - -The `SERVICE_CLUSTER_IP_RANGE` variable defines the Kubernetes service IP range. Please make sure -that you do have a valid private ip range defined here, because some IaaS provider may reserve private ips. -You can use below three private network range according to rfc1918. Besides you'd better not choose the one -that conflicts with your own private network range. - -```shell -10.0.0.0 - 10.255.255.255 (10/8 prefix) - -172.16.0.0 - 172.31.255.255 (172.16/12 prefix) - -192.168.0.0 - 192.168.255.255 (192.168/16 prefix) -``` - -The `FLANNEL_NET` variable defines the IP range used for flannel overlay network, -should not conflict with above `SERVICE_CLUSTER_IP_RANGE`. -You can optionally provide additional Flannel network configuration -through `FLANNEL_BACKEND` and `FLANNEL_OTHER_NET_CONFIG`, as explained in `cluster/ubuntu/config-default.sh`. - -The default setting for `ADMISSION_CONTROL` is right for the latest -release of Kubernetes, but if you choose an earlier release then you -might want a different setting. See -[the admission control doc](/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use) -for the recommended settings for various releases. - -**Note:** When deploying, master needs to be connected to the Internet to download the necessary files. -If your machines are located in a private network that need proxy setting to connect the Internet, -you can set the config `PROXY_SETTING` in cluster/ubuntu/config-default.sh such as: - - PROXY_SETTING="http_proxy=http://server:port https_proxy=https://server:port" - -After all the above variables being set correctly, we can use following command in `cluster/` directory to -bring up the whole cluster. - -```shell -$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh -``` - -The scripts automatically copy binaries and config files to all the machines via `scp` and start Kubernetes -service on them. The only thing you need to do is to type the sudo password when promoted. - -```shell -Deploying node on machine 10.10.103.223 -... -[sudo] password to start node: -``` - -If everything works correctly, you will see the following message from console indicating the k8s cluster is up. - -```shell -Cluster validation succeeded -``` - -### Test it out - -You can use `kubectl` command to check if the newly created cluster is working correctly. -The `kubectl` binary is under the `cluster/ubuntu/binaries` directory. -You can make it available via PATH, then you can use the below command smoothly. - -For example, use `$ kubectl get nodes` to see if all of your nodes are ready. - -```shell -$ kubectl get nodes -NAME STATUS AGE VERSION -10.10.103.162 Ready 3d v1.6.0+fff5156 -10.10.103.223 Ready 3d v1.6.0+fff5156 -10.10.103.250 Ready 3d v1.6.0+fff5156 -``` - -Also you can run Kubernetes [guest-example](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/guestbook/) to build a redis backend cluster． - - -### Deploy addons - -Assuming you have a starting cluster now, this section will tell you how to deploy addons like DNS -and UI onto the existing cluster. - -The configuration of DNS is configured in cluster/ubuntu/config-default.sh. - -```shell -ENABLE_CLUSTER_DNS="${KUBE_ENABLE_CLUSTER_DNS:-true}" - -DNS_SERVER_IP="192.168.3.10" - -DNS_DOMAIN="cluster.local" - -DNS_REPLICAS=1 -``` - -The `DNS_SERVER_IP` is defining the ip of dns server which must be in the `SERVICE_CLUSTER_IP_RANGE`. -The `DNS_REPLICAS` describes how many dns pod running in the cluster. - -By default, we also take care of kube-ui addon. - -```shell -ENABLE_CLUSTER_UI="${KUBE_ENABLE_CLUSTER_UI:-true}" -``` - -After all the above variables have been set, just type the following command. - -```shell -$ cd cluster/ubuntu -$ KUBERNETES_PROVIDER=ubuntu ./deployAddons.sh -``` - -After some time, you can use `$ kubectl get pods --namespace=kube-system` to see the DNS and UI pods are running in the cluster. - -### On going - -We are working on these features which we'd like to let everybody know: - -1. Run Kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube), -to eliminate OS-distro differences. -2. Tearing Down scripts: clear and re-create the whole stack by one click. - -### Troubleshooting - -Generally, what this approach does is quite simple: - -1. Download and copy binaries and configuration files to proper directories on every node. -2. Configure `etcd` for master node using IPs based on input from user. -3. Create and start flannel network for worker nodes. - -So if you encounter a problem, check etcd configuration of master node first. - -1. Check `/var/log/upstart/etcd.log` for suspicious etcd log -2. You may find following commands useful, the former one to bring down the cluster, while the latter one could start it again. - -```shell -$ KUBERNETES_PROVIDER=ubuntu ./kube-down.sh -$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh -``` - -3. You can also customize your own settings in `/etc/default/{component_name}` and restart it via -`$ sudo service {component_name} restart`. - - -## Upgrading a Cluster - -If you already have a Kubernetes cluster, and want to upgrade to a new version, -you can use following command in `cluster/` directory to update the whole cluster -or a specified node to a new version. - -```shell -$ KUBERNETES_PROVIDER=ubuntu ./kube-push.sh [-m|-n ] -``` - -It can be done for all components (by default), master(`-m`) or specified node(`-n`). -Upgrading a single node is currently experimental. -If the version is not specified, the script will try to use local binaries. You should ensure all -the binaries are well prepared in the expected directory path cluster/ubuntu/binaries. - -```shell -$ tree cluster/ubuntu/binaries -binaries/ -├── kubectl -├── master -│   ├── etcd -│   ├── etcdctl -│   ├── flanneld -│   ├── kube-apiserver -│   ├── kube-controller-manager -│   └── kube-scheduler -└── minion - ├── flanneld - ├── kubelet - └── kube-proxy -``` - -You can use following command to get a help. - -```shell -$ KUBERNETES_PROVIDER=ubuntu ./kube-push.sh -h -``` - -Here are some examples: - -* upgrade master to version 1.0.5: `$ KUBERNETES_PROVIDER=ubuntu ./kube-push.sh -m 1.0.5` -* upgrade node `vcap@10.10.103.223` to version 1.0.5 : `$ KUBERNETES_PROVIDER=ubuntu ./kube-push.sh -n 10.10.103.223 1.0.5` -* upgrade master and all nodes to version 1.0.5: `$ KUBERNETES_PROVIDER=ubuntu ./kube-push.sh 1.0.5` - -The script will not delete any resources of your cluster, it just replaces the binaries. - -### Test it out - -You can use the `kubectl` command to check if the newly upgraded Kubernetes cluster is working correctly. - -To make sure the version of the upgraded cluster is what you expect, you will find these commands helpful. - -* upgrade all components or master: `$ kubectl version`. Check the *Server Version*. -* upgrade node `vcap@10.10.102.223`: `$ ssh -t vcap@10.10.102.223 'cd /opt/bin && sudo ./kubelet --version'`* -{% endcapture %} - - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu) | | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) - - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - -{% include templates/task.md %} diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index ad5c1b9329..96e3c49216 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -32,7 +32,8 @@ The following diagram illustrates the Windows Server networking setup for Kubern ![Windows Setup](windows-setup.png) ## Setting up Windows Server Containers on Kubernetes -To run Windows Server Containers on Kubernetes, you'll need to set up both your host machines and the Kubernetes node components for Windows and setup Routes for Pod communication on different nodes +To run Windows Server Containers on Kubernetes, you'll need to set up both your host machines and the Kubernetes node components for Windows and setup Routes for Pod communication on different nodes. + ### Host Setup **Windows Host Setup** diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index 9ca5dd13a0..65a05b634d 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -468,9 +468,9 @@ control of your Kubernetes cluster. ## Feedback * kubeadm support Slack Channel: - [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) + [kubeadm](https://kubernetes.slack.com/messages/kubeadm/) * General SIG Cluster Lifecycle Development Slack Channel: - [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/) + [sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/) * Mailing List: [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle) * [GitHub Issues in the kubeadm @@ -561,10 +561,10 @@ Verify that the `$HOME/.kube/config` file contains a valid certificate, and rege Another workaround is to overwrite the default `kubeconfig` for the "admin" user: ``` - mv $HOME/.kube $HOME/.kube.bak - mkdir -p $HOME/.kube - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config - sudo chown $(id -u):$(id -g) $HOME/.kube/config +mv $HOME/.kube $HOME/.kube.bak +mkdir -p $HOME/.kube +sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config +sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` 1. If you are using CentOS and encounter difficulty while setting up the master node， diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md index 2b05534ff4..5c65f1a38c 100644 --- a/docs/setup/pick-right-solution.md +++ b/docs/setup/pick-right-solution.md @@ -120,7 +120,6 @@ These solutions are combinations of cloud providers and operating systems not co * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) * [CentOS](/docs/getting-started-guides/centos/centos_manual_config) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) -* [Manually Deploying Kubernetes on Ubuntu Nodes](/docs/getting-started-guides/ubuntu/manual) * [CoreOS on AWS or GCE](/docs/getting-started-guides/coreos) ## Integrations diff --git a/docs/tasks/administer-cluster/calico-network-policy.md b/docs/tasks/administer-cluster/calico-network-policy.md index 8409bc5576..4543aa7069 100644 --- a/docs/tasks/administer-cluster/calico-network-policy.md +++ b/docs/tasks/administer-cluster/calico-network-policy.md @@ -9,7 +9,7 @@ This page shows how to use Calico for NetworkPolicy. {% endcapture %} {% capture prerequisites %} -* Install Calico for Kubernetes. +* [Install Calico for Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/). {% endcapture %} {% capture steps %} diff --git a/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/docs/tasks/administer-cluster/configure-multiple-schedulers.md index f353e75f9f..08e255f732 100644 --- a/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -138,9 +138,9 @@ scheduler in that pod spec. Let's look at three examples. Save this file as `pod1.yaml` and submit it to the Kubernetes cluster. - ```shell - kubectl create -f pod1.yaml - ``` +```shell +kubectl create -f pod1.yaml +``` - Pod spec with `default-scheduler` @@ -151,9 +151,9 @@ scheduler in that pod spec. Let's look at three examples. Save this file as `pod2.yaml` and submit it to the Kubernetes cluster. - ```shell - kubectl create -f pod2.yaml - ``` +```shell +kubectl create -f pod2.yaml +``` - Pod spec with `my-scheduler` diff --git a/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md b/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md index 23049680ee..a78cc683b5 100644 --- a/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md +++ b/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md @@ -42,7 +42,7 @@ You need to have a Kubernetes cluster running version 1.6.x. 2. Restart kubelet. - sudo systemctl restart kubelet + systemctl restart kubelet 3. Delete the `kube-proxy` DaemonSet. @@ -88,7 +88,7 @@ You need to have a Kubernetes cluster running version 1.6.x. 2. Restart kubelet. - sudo systemctl restart kubelet + systemctl restart kubelet {% endcapture %} diff --git a/docs/tasks/administer-cluster/namespaces.md b/docs/tasks/administer-cluster/namespaces.md index eee6e75e46..c59da6b890 100644 --- a/docs/tasks/administer-cluster/namespaces.md +++ b/docs/tasks/administer-cluster/namespaces.md @@ -42,9 +42,10 @@ Or you can get detailed information with: ```shell $ kubectl describe namespaces -Name: default -Labels: -Status: Active +Name: default +Labels: +Annotations: +Status: Active No resource quota. diff --git a/docs/tasks/administer-cluster/opaque-integer-resource-node.md b/docs/tasks/administer-cluster/opaque-integer-resource-node.md index 26f53f1242..c71f45aa6b 100644 --- a/docs/tasks/administer-cluster/opaque-integer-resource-node.md +++ b/docs/tasks/administer-cluster/opaque-integer-resource-node.md @@ -134,7 +134,7 @@ opaque-int-resource-special-storage. ```yaml Capacity: ... - pod.alpha.kubernetes.io/opaque-int-special-storage: 8 + pod.alpha.kubernetes.io/opaque-int-resource-special-storage: 8 ``` If you want to allow arbitrary requests for special storage, you @@ -144,7 +144,7 @@ could advertise special storage in chunks of size 1 byte. In that case, you woul ```yaml Capacity: ... - pod.alpha.kubernetes.io/opaque-int-special-storage: 8Gi + pod.alpha.kubernetes.io/opaque-int-resource-special-storage: 800Gi ``` Then a Container could request any number of bytes of special storage, up to 800Gi. diff --git a/docs/tasks/administer-cluster/static-pod.md b/docs/tasks/administer-cluster/static-pod.md index 1c21a6f178..f2f439470a 100644 --- a/docs/tasks/administer-cluster/static-pod.md +++ b/docs/tasks/administer-cluster/static-pod.md @@ -92,7 +92,7 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/ ```shell [joe@my-master ~] $ kubectl delete pod static-web-my-node1 -pods/static-web-my-node1 +pod "static-web-my-node1" deleted [joe@my-master ~] $ kubectl get pods NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index a842c449cd..9ae8da1f1e 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -268,7 +268,7 @@ have additional fields that can be set on `httpGet`: * `host`: Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. -* `scheme`: Scheme to use for connecting to the host. Defaults to HTTP. +* `scheme`: Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. * `path`: Path to access on the HTTP server. * `httpHeaders`: Custom headers to set in the request. HTTP allows repeated headers. * `port`: Name or number of the port to access on the container. Number must be @@ -276,12 +276,13 @@ in the range 1 to 65535. For an HTTP probe, the kubelet sends an HTTP request to the specified path and port to perform the check. The kubelet sends the probe to the container’s IP address, -unless the address is overridden by the optional `host` field in `httpGet`. -In most scenarios, you do not want to set the `host` field. Here's one scenario -where you would set it. Suppose the Container listens on 127.0.0.1 and the Pod's -`hostNetwork` field is true. Then `host`, under `httpGet`, should be set to 127.0.0.1. -If your pod relies on virtual hosts, which is probably the more common case, -you should not use `host`, but rather set the `Host` header in `httpHeaders`. +unless the address is overridden by the optional `host` field in `httpGet`. If +`scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the +certificate verification. In most scenarios, you do not want to set the `host` field. +Here's one scenario where you would set it. Suppose the Container listens on 127.0.0.1 +and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should be set +to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common +case, you should not use `host`, but rather set the `Host` header in `httpHeaders`. {% endcapture %} diff --git a/docs/tasks/configure-pod-container/configure-volume-storage.md b/docs/tasks/configure-pod-container/configure-volume-storage.md index d2f945097b..56b839619e 100644 --- a/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -40,7 +40,7 @@ restarts. Here is the configuration file for the Pod: 1. Verify that the Pod's Container is running, and then watch for changes to the Pod: - kubectl get --watch pod redis + kubectl get pod redis --watch The output looks like this: diff --git a/docs/tasks/configure-pod-container/opaque-integer-resource.md b/docs/tasks/configure-pod-container/opaque-integer-resource.md index d7db46a250..eb5c017160 100644 --- a/docs/tasks/configure-pod-container/opaque-integer-resource.md +++ b/docs/tasks/configure-pod-container/opaque-integer-resource.md @@ -53,7 +53,7 @@ Describe the Pod: kubectl describe pod oir-demo ``` -The output shows the memory, CPU, and dongle requests: +The output shows dongle requests: ```yaml Requests: diff --git a/docs/tasks/debug-application-cluster/debug-application-introspection.md b/docs/tasks/debug-application-cluster/debug-application-introspection.md index ac936adf74..55c4c24c7f 100644 --- a/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -280,34 +280,55 @@ kubernetes-node-unaj Ready 1h v1.6.0+fff5156 $ kubectl describe node kubernetes-node-861h Name: kubernetes-node-861h -Labels: kubernetes.io/hostname=kubernetes-node-861h -CreationTimestamp: Fri, 10 Jul 2015 14:32:29 -0700 +Role +Labels: beta.kubernetes.io/arch=amd64 + beta.kubernetes.io/os=linux + kubernetes.io/hostname=kubernetes-node-861h +Annotations: node.alpha.kubernetes.io/ttl=0 + volumes.kubernetes.io/controller-managed-attach-detach=true +Taints: +CreationTimestamp: Mon, 04 Sep 2017 17:13:23 +0800 +Phase: Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message - Ready Unknown Fri, 10 Jul 2015 14:34:32 -0700 Fri, 10 Jul 2015 14:35:15 -0700 Kubelet stopped posting node status. + ---- ------ ----------------- ------------------ ------ ------- + OutOfDisk Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + MemoryPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + DiskPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + Ready Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. Addresses: 10.240.115.55,104.197.0.26 Capacity: - cpu: 1 - memory: 3800808Ki - pods: 100 -Version: - Kernel Version: 3.16.0-0.bpo.4-amd64 - OS Image: Debian GNU/Linux 7 (wheezy) - Container Runtime Version: docker://Unknown - Kubelet Version: v0.21.1-185-gffc5a86098dc01 - Kube-Proxy Version: v0.21.1-185-gffc5a86098dc01 -PodCIDR: 10.244.0.0/24 -ExternalID: 15233045891481496305 -Pods: (0 in total) - Namespace Name -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Fri, 10 Jul 2015 14:32:28 -0700 Fri, 10 Jul 2015 14:32:28 -0700 1 {kubelet kubernetes-node-861h} NodeNotReady Node kubernetes-node-861h status is now: NodeNotReady - Fri, 10 Jul 2015 14:32:30 -0700 Fri, 10 Jul 2015 14:32:30 -0700 1 {kubelet kubernetes-node-861h} NodeNotReady Node kubernetes-node-861h status is now: NodeNotReady - Fri, 10 Jul 2015 14:33:00 -0700 Fri, 10 Jul 2015 14:33:00 -0700 1 {kubelet kubernetes-node-861h} starting Starting kubelet. - Fri, 10 Jul 2015 14:33:02 -0700 Fri, 10 Jul 2015 14:33:02 -0700 1 {kubelet kubernetes-node-861h} NodeReady Node kubernetes-node-861h status is now: NodeReady - Fri, 10 Jul 2015 14:35:15 -0700 Fri, 10 Jul 2015 14:35:15 -0700 1 {controllermanager } NodeNotReady Node kubernetes-node-861h status is now: NodeNotReady - + cpu: 2 + hugePages: 0 + memory: 4046788Ki + pods: 110 +Allocatable: + cpu: 1500m + hugePages: 0 + memory: 1479263Ki + pods: 110 +System Info: + Machine ID: 8e025a21a4254e11b028584d9d8b12c4 + System UUID: 349075D1-D169-4F25-9F2A-E886850C47E3 + Boot ID: 5cd18b37-c5bd-4658-94e0-e436d3f110e0 + Kernel Version: 4.4.0-31-generic + OS Image: Debian GNU/Linux 8 (jessie) + Operating System: linux + Architecture: amd64 + Container Runtime Version: docker://1.12.5 + Kubelet Version: v1.6.9+a3d1dfa6f4335 + Kube-Proxy Version: v1.6.9+a3d1dfa6f4335 +ExternalID: 15233045891481496305 +Non-terminated Pods: (9 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- +...... +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%) +Events: $ kubectl get node kubernetes-node-861h -o yaml apiVersion: v1 diff --git a/docs/tasks/debug-application-cluster/debug-service.md b/docs/tasks/debug-application-cluster/debug-service.md index 6ca474efc9..b2ee1307d3 100644 --- a/docs/tasks/debug-application-cluster/debug-service.md +++ b/docs/tasks/debug-application-cluster/debug-service.md @@ -627,7 +627,7 @@ us know, so we can help investigate! Contact us on [Slack](/docs/troubleshooting/#slack) or -[email](https://groups.google.com/forum/#!forum/google-containers) or +[email](https://groups.google.com/forum/#!forum/kubernetes-users) or [GitHub](https://github.com/kubernetes/kubernetes). ## More information diff --git a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index 9caad6cdff..e6962e2389 100644 --- a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -188,15 +188,15 @@ You can use similar commands to view the `cpu_request`, `mem_limit` and The following information is available to Containers through environment variables and DownwardAPIVolumeFiles: -* The node’s name -* The node's IP +* The Node’s name +* The Node's IP * The Pod’s name * The Pod’s namespace * The Pod’s IP address * The Pod’s service account name * The Pod’s UID * A Container’s CPU limit -* A container’s CPU request +* A Container’s CPU request * A Container’s memory limit * A Container’s memory request diff --git a/docs/tasks/job/coarse-parallel-processing-work-queue/index.md b/docs/tasks/job/coarse-parallel-processing-work-queue/index.md index 6ffd1fe1ae..e40bb2d238 100644 --- a/docs/tasks/job/coarse-parallel-processing-work-queue/index.md +++ b/docs/tasks/job/coarse-parallel-processing-work-queue/index.md @@ -225,24 +225,37 @@ Now wait a bit, then check on the job. $ kubectl describe jobs/job-wq-1 Name: job-wq-1 Namespace: default -Image(s): gcr.io/causal-jigsaw-637/job-wq-1 -Selector: app in (job-wq-1) +Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f +Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f + job-name=job-wq-1 +Annotations: Parallelism: 2 Completions: 8 -Labels: app=job-wq-1 +Start Time: Wed, 06 Sep 2017 16:42:02 +0800 Pods Statuses: 0 Running / 8 Succeeded / 0 Failed -No volumes. +Pod Template: + Labels: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f + job-name=job-wq-1 + Containers: + c: + Image: gcr.io/causal-jigsaw-637/job-wq-1 + Port: + Environment: + BROKER_URL: amqp://guest:guest@rabbitmq-service:5672 + QUEUE: job1 + Mounts: + Volumes: Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - ───────── ──────── ───── ──── ───────────── ────── ─────── - 27s 27s 1 {job } SuccessfulCreate Created pod: job-wq-1-hcobb - 27s 27s 1 {job } SuccessfulCreate Created pod: job-wq-1-weytj - 27s 27s 1 {job } SuccessfulCreate Created pod: job-wq-1-qaam5 - 27s 27s 1 {job } SuccessfulCreate Created pod: job-wq-1-b67sr - 26s 26s 1 {job } SuccessfulCreate Created pod: job-wq-1-xe5hj - 15s 15s 1 {job } SuccessfulCreate Created pod: job-wq-1-w2zqe - 14s 14s 1 {job } SuccessfulCreate Created pod: job-wq-1-d6ppa - 14s 14s 1 {job } SuccessfulCreate Created pod: job-wq-1-p17e0 + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + ───────── ──────── ───── ──── ───────────── ────── ────── ─────── + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-hcobb + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-weytj + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-qaam5 + 27s 27s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-b67sr + 26s 26s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-xe5hj + 15s 15s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-w2zqe + 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-d6ppa + 14s 14s 1 {job } Normal SuccessfulCreate Created pod: job-wq-1-p17e0 ``` All our pods succeeded. Yay. 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 887f5e6dd2..9d19895039 100644 --- a/docs/tasks/job/fine-parallel-processing-work-queue/index.md +++ b/docs/tasks/job/fine-parallel-processing-work-queue/index.md @@ -178,14 +178,24 @@ Now wait a bit, then check on the job. $ kubectl describe jobs/job-wq-2 Name: job-wq-2 Namespace: default -Image(s): gcr.io/exampleproject/job-wq-2 -Selector: app in (job-wq-2) +Selector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f +Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f + job-name=job-wq-2 +Annotations: Parallelism: 2 -Completions: Unset +Completions: Start Time: Mon, 11 Jan 2016 17:07:59 -0800 -Labels: app=job-wq-2 Pods Statuses: 1 Running / 0 Succeeded / 0 Failed -No volumes. +Pod Template: + Labels: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f + job-name=job-wq-2 + Containers: + c: + Image: gcr.io/exampleproject/job-wq-2 + Port: + Environment: + Mounts: + Volumes: Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- diff --git a/docs/tasks/manage-gpus/scheduling-gpus.md b/docs/tasks/manage-gpus/scheduling-gpus.md index 8981bc5a31..fa701e4cfa 100644 --- a/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/docs/tasks/manage-gpus/scheduling-gpus.md @@ -60,7 +60,7 @@ Following is an illustration of this workflow: As part of your Node bootstrapping, identify the GPU hardware type on your nodes and expose it as a node label. ```shell -NVIDIA_GPU_NAME=$(nvidia-smi --query-gpu=gpu_name --format=csv,noheader --id=0) +NVIDIA_GPU_NAME=$(nvidia-smi --query-gpu=gpu_name --format=csv,noheader --id=0 | sed -e 's/ /-/g') source /etc/default/kubelet KUBELET_OPTS="$KUBELET_OPTS --node-labels='alpha.kubernetes.io/nvidia-gpu-name=$NVIDIA_GPU_NAME'" echo "KUBELET_OPTS=$KUBELET_OPTS" > /etc/default/kubelet diff --git a/docs/tasks/run-application/run-single-instance-stateful-application.md b/docs/tasks/run-application/run-single-instance-stateful-application.md index ca0bb66775..6a1c305fa9 100644 --- a/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -140,6 +140,8 @@ for a secure solution. Name: mysql-pv Labels: + Annotations: pv.kubernetes.io/bound-by-controller=yes + StorageClass: Status: Bound Claim: default/mysql-pv-claim Reclaim Policy: Retain @@ -152,7 +154,7 @@ for a secure solution. FSType: ext4 Partition: 0 ReadOnly: false - No events. + Events: 1. Inspect the PersistentVolumeClaim: @@ -160,12 +162,15 @@ for a secure solution. Name: mysql-pv-claim Namespace: default + StorageClass: Status: Bound Volume: mysql-pv Labels: + Annotations: pv.kubernetes.io/bind-completed=yes + pv.kubernetes.io/bound-by-controller=yes Capacity: 20Gi Access Modes: RWO - No events. + Events: ## Accessing the MySQL instance diff --git a/docs/tasks/run-application/scale-stateful-set.md b/docs/tasks/run-application/scale-stateful-set.md index ca73a3997e..0ee87d9b20 100644 --- a/docs/tasks/run-application/scale-stateful-set.md +++ b/docs/tasks/run-application/scale-stateful-set.md @@ -70,7 +70,7 @@ kubectl patch statefulsets -p '{"spec":{"replicas":
Either install WordPress by creating a username and password or delete your instance. {: .warning} diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml index 2253600de6..ce3eb1bf74 100644 --- a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml +++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml @@ -25,13 +25,17 @@ spec: requests: storage: 20Gi --- -apiVersion: extensions/v1beta1 +apiVersion: apps/v1beta2 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress spec: + selector: + matchLabels: + app: wordpress + tier: mysql strategy: type: Recreate template: diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml index e15edc5998..c354cdef88 100644 --- a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml +++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml @@ -25,13 +25,17 @@ spec: requests: storage: 20Gi --- -apiVersion: extensions/v1beta1 +apiVersion: apps/v1beta2 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: + selector: + matchLabels: + app: wordpress + tier: frontend strategy: type: Recreate template: diff --git a/docs/tutorials/stateless-application/expose-external-ip-address.md b/docs/tutorials/stateless-application/expose-external-ip-address.md index 39b7bfaa0c..6d4b0a39bc 100644 --- a/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -85,6 +85,7 @@ external IP address. Name: my-service Namespace: default Labels: run=load-balancer-example + Annotations: Selector: run=load-balancer-example Type: LoadBalancer IP: 10.3.245.137 @@ -93,7 +94,7 @@ external IP address. NodePort: 32377/TCP Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... Session Affinity: None - Events: + Events: Make a note of the external IP address exposed by your service. In this example, the external IP address is 104.198.205.71. Also note diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index ddba577c75..db16eed44b 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -128,7 +128,7 @@ $ echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.na # Check which nodes are ready $ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ - && kubectl get nodes -o jsonpath=$JSONPATH | grep "Ready=True" + && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" # List all Secrets currently in use by a pod $ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq diff --git a/images/square-logos/accenture.png b/images/square-logos/accenture.png new file mode 100644 index 0000000000..473e6afd7e Binary files /dev/null and b/images/square-logos/accenture.png differ diff --git a/images/square-logos/applatix.png b/images/square-logos/applatix.png new file mode 100644 index 0000000000..15a30708ca Binary files /dev/null and b/images/square-logos/applatix.png differ diff --git a/images/square-logos/biarca.png b/images/square-logos/biarca.png new file mode 100644 index 0000000000..d99a06d245 Binary files /dev/null and b/images/square-logos/biarca.png differ diff --git a/images/square-logos/bitnami.png b/images/square-logos/bitnami.png index 13d5828776..de807faf78 100644 Binary files a/images/square-logos/bitnami.png and b/images/square-logos/bitnami.png differ diff --git a/images/square-logos/boozallenhamilton.png b/images/square-logos/boozallenhamilton.png new file mode 100644 index 0000000000..23efaf41af Binary files /dev/null and b/images/square-logos/boozallenhamilton.png differ diff --git a/images/square-logos/claranet.png b/images/square-logos/claranet.png new file mode 100644 index 0000000000..63e208eb5b Binary files /dev/null and b/images/square-logos/claranet.png differ diff --git a/images/square-logos/cloudkite.png b/images/square-logos/cloudkite.png new file mode 100644 index 0000000000..7cbe6604b5 Binary files /dev/null and b/images/square-logos/cloudkite.png differ diff --git a/images/square-logos/cloudops.png b/images/square-logos/cloudops.png new file mode 100644 index 0000000000..731a0c11af Binary files /dev/null and b/images/square-logos/cloudops.png differ diff --git a/images/square-logos/contino.png b/images/square-logos/contino.png new file mode 100644 index 0000000000..f2d42c95b0 Binary files /dev/null and b/images/square-logos/contino.png differ diff --git a/images/square-logos/ghostcloud.png b/images/square-logos/ghostcloud.png new file mode 100644 index 0000000000..36d6810a11 Binary files /dev/null and b/images/square-logos/ghostcloud.png differ diff --git a/images/square-logos/heptio.png b/images/square-logos/heptio.png new file mode 100644 index 0000000000..755f6206fe Binary files /dev/null and b/images/square-logos/heptio.png differ diff --git a/partners/index.html b/partners/index.html index c4b58d73da..f19649cf77 100644 --- a/partners/index.html +++ b/partners/index.html @@ -13,10 +13,23 @@ cid: partners
-
We are working with a broad group of partners who contribute to the Kubernetes core codebase, making it stronger and richer. These partners create a vibrant Kubernetes ecosystem supporting a spectrum of complementing platforms, from open source solutions to market-leading technologies. Partners can get their services and offerings added to this page by completing and submitting the partner request form.
-

Technology Partners

+
Kubernetes works with partners to create a strong, vibrant codebase that supports a spectrum of complementary platforms.
+
+
Kubernetes Certified Service Providers
Vetted service providers with deep experience helping enterprises successfully adopt Kubernetes.

+
Technology Partners
Integrations and plugins that add features to Kubernetes applications.


+
Service Providers
Consulting or management services to help companies implement Kubernetes in commercial applications.

+
+

Kubernetes Certified Service Providers (KCSP)

+

The KCSP program is a vetted tier of service providers who have deep experience helping enterprises successfully adopt Kubernetes. KCSP partners offer Kubernetes support, consulting, professional services and training for organizations embarking on their Kubernetes journey.

+

Interested in becoming a KCSP? Learn more.

+
+

Technology Partners

+

Technology partners offer integrations and plugins that add features to Kubernetes applications.

+

Interested in becoming a Technology Partner? Please fill out this form.

-

Services Partners

+

Services Partners

+

Service Providers offer consulting or management services to help companies implement and use Kubernetes in commercial applications.

+

Interested in becoming a Service Provider? Please fill out this form