Update localization guidelines (#10485)
* Update localization guidelines for language labels
Continuing work
Continuing work
Continuing work
More work in progress
Add local OWNERS folders
Add an OWNERS file to Chinese
Remove shortcode for repos
Add Japanese
Alphabetize languages, change weights accordingly
More updates
Add Korean in Korean
Add English to languageName
Feedback from gochist
Move Chinese content from cn/ to zh/
Move OWNERS from cn/ to zh/
Resolve merge conflicts by updating from master
Add files back in to prep for resolution
After rebase on upstream/master, remove files
Review and update localization guidelines
Feedback from gochist, tnir, cstoku
Add a trailing newline to content/ja/OWNERS
Add a trailing newline to content/zh/OWNERS
Drop requirement for GH repo project
Clarify language about forks/branches
Edits and typos
Remove a shortcode specific to a multi-repo language setup
Update aliases and owners
Add explicit OWNERS for content/en
Migrate content from Chinese repo, update regex in config.toml
Remove untranslated strings
Add trailing newline to content/en/OWNERS
Add trailing newlines to OWNERS files
add Jaguar project description (#10433)
* add Jaguar project description
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
* Minor newline tweak
blog post for azure vmss (#10538)
Add microk8s to pick-right-solution.md (#10542)
* Add microk8s to pick-right-solution.md
Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.
* capitalized Istio
Add microk8s to foundational.md (#10543)
* Add microk8s to foundational.md
Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.
* Update foundational.md
Thank you for your suggestions! LMK if this works now?
* Rewrote first paragraph
And included a bullet list of features of microk8s
* Copyedit
fix typo (#10545)
Fix the kubectl subcommands links. (#10550)
Signed-off-by: William Zhang <warmchang@outlook.com>
Fix command issue (#10515)
Signed-off-by: mooncake <xcoder@tenxcloud.com>
remove imported community files per issue 10184 (#10501)
networking.md: Markdown fix (#10498)
Fix front matter, federation command-line tools (#10500)
Clean up glossary entry (#10399)
update slack link (#10536)
typo in StatefulSet docs (#10558)
fix discription about horizontal pod autoscale (#10557)
Remove redundant symbols (#10556)
Fix issue #10520 (#10554)
Signed-off-by: William Zhang <warmchang@outlook.com>
Update api-concepts.md (#10534)
Revert "Fix command issue (#10515)"
This reverts commit c02a7fb9f9.
Update memory-constraint-namespace.md (#10530)
update memory request to 100MiB corresponding the yaml content
Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)
* blog post for azure vmss
* snapshot blog post
Resolve merge conflicts in OWNERS*
Minor typo fix (#10567)
Not sure what's supposed to be here, proposing removing it.
* Feedback from gochist
Tweaks to feedback
* Feedback from ClaudiaJKang
This commit is contained in:
Zach Corleissen
committed by
k8s-ci-robot
k8s-ci-robot
parent
753f57f0e6
commit
abcee2dccd
@@ -0,0 +1,111 @@
|
||||
---
|
||||
|
||||
title: 访问集群上运行的服务
|
||||
redirect_from:
|
||||
- "/docs/user-guide/accessing-the-cluster/"
|
||||
- "/docs/user-guide/accessing-the-cluster.html"
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文展示了如何连接 Kubernetes 集群上运行的服务。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% 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 的方式可能不能理解代理路径前缀。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,412 @@
|
||||
---
|
||||
approvers:
|
||||
- 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"
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
本示例展示了在一个 namespace 中控制资源用量的典型设置。
|
||||
|
||||
|
||||
本文展示了以下资源的使用： [Namespace](/docs/admin/namespaces), [ResourceQuota](/docs/concepts/policy/resource-quotas/) 和 [LimitRange](/docs/tasks/configure-pod-container/limit-range/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% 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: <none>
|
||||
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 上的预期持久程度来为它们指定配额。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## 总结
|
||||
|
||||
|
||||
消耗节点 cpu 和 memory 资源的动作受到 namespace 配额定义的硬性配额限制的管制。
|
||||
|
||||
|
||||
任意消耗那些资源的动作能够被调整，或者获得一个 namespace 级别的默认值以符合你最终的目标。
|
||||
|
||||
|
||||
可以基于服务质量或者在你集群中节点上的预期持久程度来分配配额。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
approvers:
|
||||
- caseydavenport
|
||||
title: 使用 Calico 来提供 NetworkPolicy
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
本页展示怎么样使用 Calico 来提供 NetworkPolicy
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
* 为 Kubernetes 安装 Calico
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 使用 Calico 部署一个集群
|
||||
|
||||
|
||||
使用如下命令，您可以在默认的 [GCE 部署环境中](/docs/getting-started-guides/gce) 部署一个使用 Calico 来提供网络策略的集群：
|
||||
|
||||
```shell
|
||||
export NETWORK_POLICY_PROVIDER=calico
|
||||
export KUBE_NODE_OS_DISTRIBUTION=debian
|
||||
curl -sS https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
|
||||
如果希望了解其它的部署选项，请您参考 [Calico 项目文档](http://docs.projectcalico.org/)
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## 理解 Calico 组件
|
||||
|
||||
|
||||
部署使用 Calico 的集群其实是增加了支持 Kubernetes NetworkPolicy 的 Pods， 这些 Pods 运行在 `kube-system` 命名空间下。
|
||||
|
||||
|
||||
使用如下方式去查看这些运行的 Pods：
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
|
||||
您可以看到类似下面这样的一个 Pods 列表：
|
||||
|
||||
```console
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
calico-node-kubernetes-minion-group-jck6 1/1 Running 0 46m
|
||||
calico-node-kubernetes-minion-group-k9jy 1/1 Running 0 46m
|
||||
calico-node-kubernetes-minion-group-szgr 1/1 Running 0 46m
|
||||
calico-policy-controller-65rw1 1/1 Running 0 46m
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
主要有两种组件
|
||||
|
||||
|
||||
- 在集群的每个节点上都会运行一个以 `calico-node` 开头命名的 Pod，用于配置 iptables 去实现那些机器上 Pods 的出/入网络策略
|
||||
|
||||
- 整个集群环境只有一个以 `calico-policy-controller` 开头命名的 Pod，用于从 Kubernetes API 中读取策略和标签信息，适当的对 Calico 进行配置
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
集群部署完成之后，您可以通过 [NetworkPolicy 入门指南](/docs/getting-started-guides/network-policy/walkthrough)去尝试使用 Kubernetes NetworkPolicy
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
|
||||
title: 改变默认 StorageClass
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文展示了如何改变默认的 Storage Class，它用于为没有特殊需求的 PersistentVolumeClaims 配置 volumes。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% 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 <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
|
||||
|
||||
|
||||
这里的 `<your-class-name>` 是您选择的 StorageClass 的名字。
|
||||
|
||||
|
||||
3. 标记一个 StorageClass 为默认的：
|
||||
|
||||
|
||||
和前面的步骤类似，您需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。
|
||||
|
||||
kubectl patch storageclass <your-class-name> -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
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 了解更多关于 [StorageClasses](/docs/concepts/storage/persistent-volumes/)。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: 更改 PersistentVolume 的回收策略
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文展示了如何更改 Kubernetes PersistentVolume 的回收策略。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 为什么要更改 PersistentVolume 的回收策略
|
||||
|
||||
|
||||
`PersistentVolumes` 可以有多种回收策略，包括 "Retain"、"Recycle" 和 "Delete"。对于动态配置的 `PersistentVolumes` 来说，默认回收策略为 "Delete"。这表示当用户删除对应的 `PersistentVolumeClaim` 时，动态配置的 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 <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
|
||||
这里的 `<your-pv-name>` 是你选择的 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` 时，它不会被自动删除。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 了解更多关于 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)的信息。
|
||||
* 了解更多关于 [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 的信息。
|
||||
|
||||
|
||||
### 参考
|
||||
|
||||
* [PersistentVolume](/docs/api-reference/{{< param "version" >}}/#persistentvolume-v1-core)
|
||||
* [PersistentVolumeClaim](/docs/api-reference/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
|
||||
|
||||
* 查阅 [PersistentVolumeSpec](/docs/api-reference/{{< param "version" >}}/#persistentvolumeclaim-v1-core) 的 `persistentVolumeReclaimPolicy` 字段。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,226 @@
|
||||
---
|
||||
approvers:
|
||||
- lavalamp
|
||||
- thockin
|
||||
title: 集群管理
|
||||
---
|
||||
|
||||
|
||||
{{< 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 Kubernetes Engine 集群
|
||||
|
||||
|
||||
Google Kubernetes Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。
|
||||
|
||||
|
||||
节点升级过程由用户初始化，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-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 或者 Google Kubernetes Engine，这将通过调整管理节点的实例组的大小完成。在 [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 或者 Google Kubernetes Engine，您可以配置您的集群，使其能够基于 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）或节点池（Google Kubernetes Engine）上配置。
|
||||
|
||||
|
||||
如果您使用 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
|
||||
```
|
||||
|
||||
|
||||
在 Google Kubernetes Engine 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `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/<version>` 标志来打开或关闭特定的 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) 命令用法。
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-cpu-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-cpu-demo-2-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1.5"
|
||||
requests:
|
||||
cpu: "500m"
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-cpu-demo-4
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-cpu-demo-4-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: "800m"
|
||||
requests:
|
||||
cpu: "100m"
|
||||
@@ -0,0 +1,8 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-cpu-demo-4
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-cpu-demo-4-ctr
|
||||
image: vish/stress
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-cpu-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-cpu-demo-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: "800m"
|
||||
requests:
|
||||
cpu: "500m"
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: cpu-min-max-demo-lr
|
||||
spec:
|
||||
limits:
|
||||
- max:
|
||||
cpu: "800m"
|
||||
min:
|
||||
cpu: "200m"
|
||||
type: Container
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-cpu-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: default-cpu-demo-2-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-cpu-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: default-cpu-demo-3-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
requests:
|
||||
cpu: "0.75"
|
||||
@@ -0,0 +1,8 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-cpu-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: default-cpu-demo-ctr
|
||||
image: nginx
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: cpu-limit-range
|
||||
spec:
|
||||
limits:
|
||||
- default:
|
||||
cpu: 1
|
||||
defaultRequest:
|
||||
cpu: 0.5
|
||||
type: Container
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: 控制节点上的CPU管理策略
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
按照设计，Kubernetes 对 pod 执行相关的很多方面进行了抽象，使得用户不必关心。然而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。 为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
|
||||
|
||||
## CPU 管理策略
|
||||
|
||||
默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler) 来执行 pod 的 CPU 约束。当节点上运行了很多 CPU 密集的 pod 时，工作负载可能会迁移到不同的 CPU 核，这取决于调度时 pod 是否被扼制，以及哪些 CPU 核是可用的。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
|
||||
|
||||
然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响，对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
|
||||
|
||||
### 配置
|
||||
|
||||
CPU 管理器（CPU Manager）作为 alpha 特性引入 Kubernetes 1.8 版本。 必须在 kubelet 特性开关中显式启用：
|
||||
`--feature-gates=CPUManager=true`。
|
||||
|
||||
CPU 管理策略通过 kubelet 参数 `--cpu-manager-policy` 来指定，
|
||||
有两种支持策略：
|
||||
|
||||
* `none`：默认策略，表示现有的调度行为。
|
||||
* `static`：允许为节点上具有某些资源特征的 pod 赋予增强的 CPU 亲和性和独占性。
|
||||
|
||||
CPU管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过新增的 Kubelet 配置参数
|
||||
`--cpu-manager-reconcile-period` 来设置。 如不指定，默认与 `--node-status-update-frequency` 的周期相同。
|
||||
|
||||
### None 策略
|
||||
|
||||
`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 通过 CFS 配额来实现
|
||||
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) 的 CPU 使用限制。
|
||||
|
||||
### Static 策略
|
||||
|
||||
`static` 策略针对具有整数型 CPU `requests` 的 pod ，它允许该类 pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 [cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) 来实现的。
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 pod。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 该策略的 alpha 版本不保证 Kubelet 重启前后的静态独占性分配。
|
||||
{{< /note >}}
|
||||
|
||||
该策略管理一个共享 CPU 资源池，最初，该资源池包含节点上所有的 CPU 资源。可用的独占性 CPU 资源数量等于节点的 CPU 总量减去通过 `--kube-reserved` 或 `--system-reserved` 参数保留的 CPU 。通过这些参数预留的 CPU 是以整数方式，按物理内核 ID 升序从初始共享池获取的。 共享池是 `BestEffort` 和 `Burstable` pod 运行的 CPU 集合。`Guaranteed` pod 中的容器，如果声明了非整数值的 CPU `requests` ，也将运行在共享池的 CPU 上。只有 `Guaranteed` pod 中，指定了整数型 CPU `requests` 的容器，才会被分配独占 CPU 资源。
|
||||
|
||||
{{< note >}}
|
||||
**注意:** 当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 来保证预留的 CPU 值大于零。 这是因为零预留 CPU 值可能使得共享池变空。
|
||||
{{< /note >}}
|
||||
|
||||
当 `Guaranteed` pod 调度到节点上时，如果其容器符合静态分配要求，相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。换言之，容器 cpuset 中的 CPU 数量与 pod 规格中指定的整数型 CPU `limit` 相等。这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
|
||||
|
||||
考虑以下 Pod 规格的容器：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
```
|
||||
|
||||
该 pod 属于 `BestEffort` 服务质量类型，因为其未指定 `requests` 或
|
||||
`limits` 值。 所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
requests:
|
||||
memory: "100Mi"
|
||||
```
|
||||
|
||||
该 pod 属于 `Burstable` 服务质量类型，因为其资源 `requests` 不等于
|
||||
`limits`， 且未指定 `cpu` 数量。所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
requests:
|
||||
memory: "100Mi"
|
||||
cpu: "1"
|
||||
```
|
||||
|
||||
该 pod 属于 `Burstable` 服务质量类型，因为其资源 `requests` 不等于 `limits`。所以该容器运行在共享 CPU 池中。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
```
|
||||
|
||||
该 pod 属于 `Guaranteed` 服务质量类型，因为其 `requests` 值与 `limits`相等。
|
||||
同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
|
||||
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "1.5"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "1.5"
|
||||
```
|
||||
|
||||
该 pod 属于 `Guaranteed` 服务质量类型，因为其 `requests` 值与 `limits`相等。但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
|
||||
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "2"
|
||||
```
|
||||
|
||||
该 pod 属于 `Guaranteed` 服务质量类型，因其指定了 `limits` 值，
|
||||
同时当未显式指定时，`requests` 值被设置为与 `limits` 值相等。同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
|
||||
|
||||
@@ -0,0 +1,259 @@
|
||||
---
|
||||
approvers:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
title: 设置 Pod CPU 和内存限制
|
||||
redirect_from:
|
||||
- "/docs/admin/limitrange/"
|
||||
- "/docs/admin/limitrange/index.html"
|
||||
- "/docs/tasks/configure-pod-container/limit-range/"
|
||||
- "/docs/tasks/configure-pod-container/limit-range.html"
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
|
||||
默认情况下，Pod 运行没有限制 CPU 使用量和内存使用量。
|
||||
这意味着当前系统中的任何 Pod 能够使用该 Pod 运行节点的所有 CPU 和内存资源。
|
||||
|
||||
|
||||
这个例子演示了如何限制 Kubernetes [Namespace](/docs/tasks/administer-cluster/namespaces-walkthrough/)，以此来控制每个 Pod 的最小/最大资源限额。
|
||||
另外，这个例子演示了当终端用户没有为 Pod 设置资源限额时，如何使用默认的资源限额。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
|
||||
## 创建 Namespace
|
||||
|
||||
这个例子将使用一个自定义的 Namespace 来演示相关的概念。
|
||||
|
||||
让我们创建一个名称为 limit-example 的 Namespace：
|
||||
|
||||
```shell
|
||||
$ kubectl create namespace limit-example
|
||||
namespace "limit-example" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
可以看到 `kubectl` 命令将打印出被创建或修改的资源的类型和名称，也会在后面的命令中使用到：
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 51s
|
||||
limit-example Active 45s
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 对 Namespace 应用限制
|
||||
|
||||
在我们的 Namespace 中创建一个简单的限制：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/limits.yaml --namespace=limit-example
|
||||
limitrange "mylimits" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
让我们查看一下在该 Namespace 中被强加的限制：
|
||||
|
||||
```shell
|
||||
$ kubectl describe limits mylimits --namespace=limit-example
|
||||
Name: mylimits
|
||||
Namespace: limit-example
|
||||
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
|
||||
---- -------- --- --- --------------- ------------- -----------------------
|
||||
Pod cpu 200m 2 - - -
|
||||
Pod memory 6Mi 1Gi - - -
|
||||
Container cpu 100m 2 200m 300m -
|
||||
Container memory 3Mi 1Gi 100Mi 200Mi -
|
||||
```
|
||||
|
||||
|
||||
|
||||
在这个场景下，指定了如下限制：
|
||||
|
||||
1. 如果一个资源被指定了最大约束（在该例子中为 2 CPU 和 1Gi 内存），则必须为跨所有容器的该资源指定限制（limits）。
|
||||
当尝试创建该 Pod 时，指定限额失败将导致一个验证错误。
|
||||
注意，一个默认的限额通过在 `limits.yaml` 文件中的 *default* 来设置（300m CPU 和 200Mi 内存）。
|
||||
2. 如果一个资源被指定了最小约束（在该例子中为 100m CPU 和 3Mi 内存），则必须跨所有容器的该资源指定请求（requests）。
|
||||
当尝试创建该 Pod 时，指定的请求失败将导致一个验证错误。
|
||||
注意，一个默认的请求的值通过在 `limits.yaml` 文件中的 *defaultRequest* 来设置（200m CPU 和 100Mi 内存）。
|
||||
3. 对任意 Pod，所有容器内存 requests 值之和必须 >= 6Mi，所有容器内存 limits 值之和必须 <= 1Gi；
|
||||
所有容器 CPU requests 值之和必须 >= 200m，所有容器 CPU limits 值之和必须 <= 2。
|
||||
|
||||
|
||||
|
||||
## 创建时强制设置限制
|
||||
|
||||
当集群中的 Pod 创建和更新时，在一个 Namespace 中列出的限额是强制设置的。
|
||||
如果将该限额修改成一个不同的值范围，它不会影响先前在该 Namespace 中创建的 Pod。
|
||||
|
||||
|
||||
|
||||
如果资源（CPU 或内存）被设置限额，用户将在创建时得到一个错误，并指出了错误的原因。
|
||||
|
||||
首先让我们启动一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，它创建一个单容器 Pod，演示了如何将默认值应用到每个 Pod 上：
|
||||
|
||||
```shell
|
||||
$ kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example
|
||||
deployment "nginx" created
|
||||
```
|
||||
|
||||
|
||||
注意，在 >= v1.2 版本的 Kubernetes 集群中，`kubectl run` 创建了名称为 “nginx” 的 Deployment。如果在老版本的集群上运行，相反它会创建 ReplicationController。
|
||||
如果想要获取老版本的行为，使用 `--generator=run/v1` 选项来创建 ReplicationController。查看 [`kubectl run`](/docs/user-guide/kubectl/v1.6/#run) 获取更多详细信息。
|
||||
Deployment 管理单容器 Pod 的 1 个副本。让我们看一下它是如何管理 Pod 的。首先，查找到 Pod 的名称：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=limit-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-2040093540-s8vzu 1/1 Running 0 11s
|
||||
```
|
||||
|
||||
|
||||
|
||||
以 yaml 输出格式来打印这个 Pod，然后 `grep` 其中的 `resources` 字段。注意，您自己的 Pod 的名称将不同于上面输出的：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods nginx-2040093540-s8vzu --namespace=limit-example -o yaml | grep resources -C 8
|
||||
resourceVersion: "57"
|
||||
selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu
|
||||
uid: 67b20741-f53b-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: 300m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
terminationMessagePath: /dev/termination-log
|
||||
volumeMounts:
|
||||
```
|
||||
|
||||
|
||||
|
||||
注意，我们的 Nginx 容器已经使用了 Namespace 的默认 CPU 和内存资源的 *limits* 和 *requests*。
|
||||
|
||||
让我们创建一个 Pod，它具有一个请求 3 CPU 核心的容器，这超过了被允许的限额：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/invalid-pod.yaml --namespace=limit-example
|
||||
Error from server: error when creating "http://k8s.io/docs/tasks/configure-pod-container/invalid-pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu usage per Pod is 2, but limit is 3., Maximum cpu usage per Container is 2, but limit is 3.]
|
||||
```
|
||||
|
||||
|
||||
|
||||
让我们创建一个 Pod，使它在允许的最大限额范围之内：
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/valid-pod.yaml --namespace=limit-example
|
||||
pod "valid-pod" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
现在查看该 Pod 的 resources 字段：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources
|
||||
uid: 3b1bfd7a-f53c-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/serve_hostname
|
||||
imagePullPolicy: Always
|
||||
name: kubernetes-serve-hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
requests:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
```
|
||||
|
||||
|
||||
|
||||
注意到这个 Pod 显式地指定了资源 *limits* 和 *requests*，所以它不会使用该 Namespace 的默认值。
|
||||
|
||||
注意：在物理节点上默认安装的 Kubernetes 集群中，CPU 资源的 *limits* 是被强制使用的，该 Kubernetes 集群运行容器，除非管理员在部署 kubelet 时使用了如下标志：
|
||||
|
||||
```shell
|
||||
$ kubelet --help
|
||||
Usage of kubelet
|
||||
....
|
||||
--cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement for containers that specify CPU limits
|
||||
$ kubelet --cpu-cfs-quota=false ...
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 清理
|
||||
|
||||
基于使用的该示例来清理资源，可以通过如下命令删除名称为 limit-example 的 Namespace：
|
||||
|
||||
```shell
|
||||
$ kubectl delete namespace limit-example
|
||||
namespace "limit-example" deleted
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 12m
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
|
||||
## 设置资限额制的动机
|
||||
|
||||
可能由于对资源使用的各种原因，用户希望对单个 Pod 的资源总量进行强制限制。
|
||||
|
||||
例如：
|
||||
|
||||
|
||||
|
||||
1. 集群中每个节点有 2GB 内存。集群操作员不想接受内存需求大于 2GB 的 Pod，因为集群中没有节点能支持这个要求。
|
||||
为了避免 Pod 永远无法被调度到集群中的节点上，操作员会选择去拒绝超过 2GB 内存作为许可控制的 Pod。
|
||||
2. 一个集群被一个组织内部的 2 个团体共享，分别作为生产和开发工作负载来运行。
|
||||
生产工作负载可能消耗多达 8GB 内存，而开发工作负载可能消耗 512MB 内存。
|
||||
集群操作员为每个工作负载创建了一个单独的 Namespace，为每个 Namespace 设置了限额。
|
||||
3. 用户会可能创建一个资源消耗低于机器容量的 Pod。剩余的空间可能太小但很有用，然而对于整个集群来说浪费的代价是足够大的。
|
||||
结果集群操作员会希望设置限额：为了统一调度和限制浪费，Pod 必须至少消耗它们平均节点大小 20% 的内存和 CPU。
|
||||
|
||||
|
||||
|
||||
## 总结
|
||||
|
||||
想要限制单个容器或 Pod 消耗资源总量的集群操作员，能够为每个 Kubernetes Namespace 定义可允许的范围。
|
||||
在没有任何明确指派的情况下，Kubernetes 系统能够使用默认的资源 *limits* 和 *requests*，如果需要的话，限制一个节点上的 Pod 的资源总量。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
* 查看 [LimitRange 设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/admission_control_limit_range.md) 获取更多信息。
|
||||
* 查看 [资源](/docs/concepts/configuration/manage-compute-resources-container/) 获取关于 Kubernetes 资源模型的详细描述。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
approvers:
|
||||
- caseydavenport
|
||||
- danwinship
|
||||
title: 声明网络策略
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
您首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括：
|
||||
|
||||
* [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
|
||||
* [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
|
||||
* [Weave 网络](/docs/tasks/configure-pod-container/weave-network-policy/)
|
||||
|
||||
|
||||
**注意**：以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 创建一个`nginx` deployment 并且通过服务将其暴露
|
||||
|
||||
|
||||
为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始
|
||||
|
||||
```console
|
||||
$ kubectl run nginx --image=nginx --replicas=2
|
||||
deployment "nginx" created
|
||||
$ kubectl expose deployment nginx --port=80
|
||||
service "nginx" exposed
|
||||
```
|
||||
|
||||
|
||||
在 default 命名空间下运行了两个 `nginx` pod，而且通过一个名字为 `nginx` 的服务进行了暴露
|
||||
|
||||
```console
|
||||
$ kubectl get svc,pod
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
svc/kubernetes 10.100.0.1 <none> 443/TCP 46m
|
||||
svc/nginx 10.100.0.16 <none> 80/TCP 33s
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
po/nginx-701339712-e0qfq 1/1 Running 0 35s
|
||||
po/nginx-701339712-o00ef 1/1 Running 0 35s
|
||||
```
|
||||
|
||||
|
||||
## 测试服务能够被其它的 pod 访问
|
||||
|
||||
|
||||
您应该可以从其它的 pod 访问这个新的 `nginx` 服务。为了验证它，从 default 命名空间下的其它 pod 来访问该服务。请您确保在该命名空间下没有执行孤立动作。
|
||||
|
||||
|
||||
启动一个 busybox 容器，然后在容器中使用 `wget` 命令去访问 `nginx` 服务：
|
||||
|
||||
```console
|
||||
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
|
||||
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
/ # wget --spider --timeout=1 nginx
|
||||
Connecting to nginx (10.100.0.16:80)
|
||||
/ #
|
||||
```
|
||||
|
||||
|
||||
## 限制访问 `nginx` 服务
|
||||
|
||||
|
||||
如果说您想限制 `nginx` 服务，只让那些拥有标签 `access: true` 的 pod 访问它，那么您可以创建一个只允许从那些 pod 连接的 `NetworkPolicy`：
|
||||
|
||||
```yaml
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: access-nginx
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
run: nginx
|
||||
ingress:
|
||||
- from:
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
access: "true"
|
||||
```
|
||||
|
||||
|
||||
## 为服务指定策略
|
||||
|
||||
|
||||
使用 kubectl 工具根据上面的 nginx-policy.yaml 文件创建一个 NetworkPolicy：
|
||||
|
||||
```console
|
||||
$ kubectl create -f nginx-policy.yaml
|
||||
networkpolicy "access-nginx" created
|
||||
```
|
||||
|
||||
|
||||
## 当访问标签没有定义时测试访问服务
|
||||
|
||||
|
||||
如果您尝试从没有设定正确标签的 pod 中去访问 `nginx` 服务，请求将会超时：
|
||||
|
||||
```console
|
||||
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
|
||||
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
/ # wget --spider --timeout=1 nginx
|
||||
Connecting to nginx (10.100.0.16:80)
|
||||
wget: download timed out
|
||||
/ #
|
||||
```
|
||||
|
||||
|
||||
## 定义访问标签后再次测试
|
||||
|
||||
|
||||
创建一个拥有正确标签的 pod，您将看到请求是被允许的：
|
||||
|
||||
```console
|
||||
$ kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh
|
||||
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
|
||||
|
||||
Hit enter for command prompt
|
||||
|
||||
/ # wget --spider --timeout=1 nginx
|
||||
Connecting to nginx (10.100.0.16:80)
|
||||
/ #
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,162 @@
|
||||
---
|
||||
approvers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: 在 Kubernetes 中配置私有 DNS 和上游域名服务器
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本页展示了如何添加自定义私有 DNS 域（存根域）和上游域名服务器。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
* Kubernetes 1.6 及其以上版本。
|
||||
* 集群必须配置使用 `kube-dns` 插件。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
|
||||
## 配置存根域和上游 DNS 服务器
|
||||
|
||||
通过为 kube-dns （`kube-system:kube-dns`）提供 ConfigMap，集群管理员能够指定自定义存根域和上游域名服务器。
|
||||
|
||||
例如，下面的 ConfigMap 建立了一个 DNS 配置，它具有一个单独的存根域和两个上游域名服务器：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“acme.local”: [“1.2.3.4”]}
|
||||
upstreamNameservers: |
|
||||
[“8.8.8.8”, “8.8.4.4”]
|
||||
```
|
||||
|
||||
|
||||
|
||||
按如上说明，具有 “.acme.local” 后缀的 DNS 请求被转发到 DNS 1.2.3.4。Google 公共 DNS服务器 为上游查询提供服务。
|
||||
下表描述了具有特定域名的查询如何映射到它们的目标 DNS 服务器：
|
||||
|
||||
|
||||
| 域名 | 响应查询的服务器 |
|
||||
| ----------- | -------------------------- |
|
||||
| kubernetes.default.svc.cluster.local| kube-dns |
|
||||
| foo.acme.local| 自定义 DNS (1.2.3.4) |
|
||||
| widget.com | 上游 DNS (8.8.8.8, 8.8.4.4，其中之一) |
|
||||
|
||||
|
||||
查看 [ConfigMap 选项](#configmap-options) 获取更多关于配置选项格式的详细信息。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
|
||||
|
||||
## 理解 Kubernetes 中名字解析
|
||||
|
||||
可以为每个 Pod 设置 DNS 策略。
|
||||
当前 Kubernetes 支持两种 Pod 特定的 DNS 策略：“Default” 和 “ClusterFirst”。
|
||||
可以通过 `dnsPolicy` 标志来指定这些策略。
|
||||
*注意：“Default” 不是默认的 DNS 策略。如果没有显式地指定 `dnsPolicy`，将会使用 “ClusterFirst”。*
|
||||
|
||||
|
||||
|
||||
### "Default" DNS 策略
|
||||
|
||||
如果 `dnsPolicy` 被设置为 “Default”，则名字解析配置会继承自 Pod 运行所在的节点。
|
||||
自定义上游域名服务器和存根域不能够与这个策略一起使用。
|
||||
|
||||
|
||||
|
||||
### "ClusterFirst" DNS 策略
|
||||
|
||||
如果 `dnsPolicy` 被设置为 "ClusterFirst"，处理名字解析有所不同，*依赖于是否配置了存根域和上游 DNS 服务器*。
|
||||
|
||||
**未进行自定义配置**：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。
|
||||
|
||||
**进行自定义配置**：如果配置了存根域和上游 DNS 服务器（类似于 [前面示例](#configuring-stub-domain-and-upstream-dns-servers) 配置的内容），DNS 查询将基于下面的流程对请求进行路由：
|
||||
|
||||
|
||||
|
||||
1. 查询首先被发送到 kube-dns 中的 DNS 缓存层。
|
||||
|
||||
1. 从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
|
||||
|
||||
* *具有集群后缀的名字*（例如 ".cluster.local"）：请求被发送到 kube-dns。
|
||||
|
||||
* *具有存根域后缀的名字*（例如 ".acme.local"）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
|
||||
|
||||
* *未能匹配上后缀的名字*（例如 "widget.com"）：请求被转发到上游 DNS（例如：Google 公共 DNS 服务器，8.8.8.8 和 8.8.4.4）。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## ConfigMap 选项
|
||||
|
||||
kube-dns `kube-system:kube-dns` 对应的 ConfigMap 选项如下所示：
|
||||
|
||||
| 字段 | 格式 | 描述 |
|
||||
| ----- | ------ | ----------- |
|
||||
| `stubDomains`（可选）| 使用 DNS 后缀作为键（例如 “acme.local”）的 JSON map，以及由 DNS IP 的 JSON 数组组成的值。 | 目标域名服务器可能是一个 Kubernetes Service。例如，可以运行自己的 dnsmasq 副本，将 DNS 名字暴露到 ClusterDNS namespace 中。|
|
||||
| `upstreamNameservers`（可选）| DNS IP 的 JSON 数组。 | 注意：如果指定，则指定的值会替换掉被默认从节点的 `/etc/resolv.conf` 中获取到的域名服务器。限制：最多可以指定三个上游域名服务器。|
|
||||
|
||||
|
||||
|
||||
## 附加示例
|
||||
|
||||
### 示例：存根域
|
||||
|
||||
在这个例子中，用户有一个 Consul DNS 服务发现系统，他们希望能够与 kube-dns 集成起来。
|
||||
Consul 域名服务器地址为 10.150.0.1，所有的 Consul 名字具有后缀 “.consul.local”。
|
||||
要配置 Kubernetes，集群管理员只需要简单地创建一个 ConfigMap 对象，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“consul.local”: [“10.150.0.1”]}
|
||||
```
|
||||
|
||||
|
||||
注意，集群管理员不希望覆盖节点的上游域名服务器，所以他们不会指定可选的 `upstreamNameservers` 字段。
|
||||
|
||||
|
||||
|
||||
### 示例：上游域名服务器
|
||||
|
||||
在这个示例中，集群管理员不希望显式地强制所有非集群 DNS 查询进入到他们自己的域名服务器 172.16.0.1。
|
||||
而且这很容易实现：他们只需要创建一个 ConfigMap，`upstreamNameservers` 字段指定期望的域名服务器即可：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
[“172.16.0.1”]
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: kube-dns-autoscaler
|
||||
namespace: kube-system
|
||||
labels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
k8s-app: kube-dns-autoscaler
|
||||
spec:
|
||||
containers:
|
||||
- name: autoscaler
|
||||
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
|
||||
resources:
|
||||
requests:
|
||||
cpu: "20m"
|
||||
memory: "10Mi"
|
||||
command:
|
||||
- /cluster-proportional-autoscaler
|
||||
- --namespace=kube-system
|
||||
- --configmap=kube-dns-autoscaler
|
||||
- --target=<SCALE_TARGET>
|
||||
# When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
|
||||
# If using small nodes, "nodesPerReplica" should dominate.
|
||||
- --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
|
||||
- --logtostderr=true
|
||||
- --v=2
|
||||
@@ -0,0 +1,323 @@
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- smarterclayton
|
||||
title: Encrypting Secret Data at Rest
|
||||
content_template: templates/task
|
||||
---
|
||||
-->
|
||||
---
|
||||
reviewers:
|
||||
- smarterclayton
|
||||
title: 加密静态 Secret 数据
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
This page shows how to enable and configure encryption of secret data at rest.
|
||||
-->
|
||||
本文展示如何启用和配置静态 Secret 数据的加密
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
* Kubernetes version 1.7.0 or later is required
|
||||
|
||||
* etcd v3 or later is required
|
||||
|
||||
* Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
|
||||
-->
|
||||
* 需要 Kubernetes 1.7.0 或者更高版本
|
||||
|
||||
* 需要 etcd v3 或者更高版本
|
||||
|
||||
* 静态数据加密在 1.7.0 中仍然是 alpha 版本，这意味着它可能会在没有通知的情况下进行更改。在升级到 1.8.0 之前，用户可能需要解密他们的数据。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Configuration and determining whether encryption at rest is already enabled
|
||||
|
||||
The `kube-apiserver` process accepts an argument `--experimental-encryption-provider-config`
|
||||
that controls how API data is encrypted in etcd. An example configuration
|
||||
is provided below.
|
||||
|
||||
## Understanding the encryption at rest configuration.
|
||||
-->
|
||||
## 配置并确定是否已启用静态数据加密
|
||||
|
||||
`kube-apiserver` 的参数 `--experimental-encryption-provider-config` 控制 API 数据在 etcd 中的加密方式。
|
||||
下面提供一个配置示例。
|
||||
|
||||
## 理解静态数据加密
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfig
|
||||
apiVersion: v1
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- identity: {}
|
||||
- aesgcm:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- secretbox:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
```
|
||||
|
||||
<!--
|
||||
Each `resources` array item is a separate config and contains a complete configuration. The
|
||||
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
|
||||
that should be encrypted. The `providers` array is an ordered list of the possible encryption
|
||||
providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
|
||||
but not both in the same item).
|
||||
|
||||
The first provider in the list is used to encrypt resources going into storage. When reading
|
||||
resources from storage each provider that matches the stored data attempts to decrypt the data in
|
||||
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
|
||||
is returned which prevents clients from accessing that resource.
|
||||
|
||||
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
|
||||
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
|
||||
read that resource will fail until it is deleted or a valid decryption key is provided.
|
||||
-->
|
||||
每个 `resources` 数组项目是一个单独的完整的配置。 `resources.resources` 字段是要加密的 Kubernetes 资源名称（`resource` 或 `resource.group`）的数组。
|
||||
`providers` 数组是可能的加密 provider 的有序列表。每个条目只能指定一个 provider 类型（可以是 `identity` 或 `aescbc`，但不能在同一个项目中同时指定）。
|
||||
|
||||
列表中的第一个提供者用于加密进入存储的资源。当从存储器读取资源时，与存储的数据匹配的所有提供者将尝试按顺序解密数据。
|
||||
如果由于格式或密钥不匹配而导致提供者无法读取存储的数据，则会返回一个错误，以防止客户端访问该资源。
|
||||
|
||||
**重要：** 如果通过加密配置无法读取资源（因为密钥已更改），唯一的方法是直接从基础 etcd 中删除该密钥。任何尝试读取资源的调用将会失败，直到它被删除或提供有效的解密密钥。
|
||||
|
||||
### Providers:
|
||||
|
||||
<!--
|
||||
Name | Encryption | Strength | Speed | Key Length | Other Considerations
|
||||
-----|------------|----------|-------|------------|---------------------
|
||||
`identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
|
||||
`aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`.
|
||||
`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
|
||||
`aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
|
||||
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
|
||||
|
||||
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
|
||||
is the first provider, the first key is used for encryption.
|
||||
-->
|
||||
名称 | 加密类型 | 强度 | 速度 | 密钥长度 | 其它事项
|
||||
-----|------------|----------|-------|------------|---------------------
|
||||
`identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时，资源将在新值写入时被解密。
|
||||
`aescbc` | 填充 PKCS#7 的 AES-CBC | 最强 | 快 | 32字节 | 建议使用的加密项，但可能比 `secretbox` 稍微慢一些。
|
||||
`secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准，在需要高度评审的环境中可能不被接受。
|
||||
`aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24, 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。
|
||||
`kms` | 使用信封加密方案：数据使用带有 PKCS#7 填充的 AES-CBC 通过 data encryption keys（DEK）加密，DEK 根据 Key Management Service（KMS）中的配置通过 key encryption keys（KEK）加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK，并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/docs/tasks/administer-cluster/kms-provider/)
|
||||
|
||||
每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。
|
||||
|
||||
<!--
|
||||
## Encrypting your data
|
||||
|
||||
Create a new encryption config file:
|
||||
-->
|
||||
## 加密您的数据
|
||||
|
||||
创建一个新的加密配置文件：
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfig
|
||||
apiVersion: v1
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: <BASE 64 ENCODED SECRET>
|
||||
- identity: {}
|
||||
```
|
||||
|
||||
<!--
|
||||
To create a new secret perform the following steps:
|
||||
|
||||
1. Generate a 32 byte random key and base64 encode it. If you're on Linux or Mac OS X, run the following command:
|
||||
-->
|
||||
遵循如下步骤来创建一个新的 secret：
|
||||
|
||||
1. 生成一个 32 字节的随机密钥并进行 base64 编码。如果您在 Linux 或 Mac OS X 上，请运行以下命令：
|
||||
|
||||
```
|
||||
head -c 32 /dev/urandom | base64
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Place that value in the secret field.
|
||||
3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
|
||||
4. Restart your API server.
|
||||
|
||||
**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
|
||||
-->
|
||||
2. 将这个值放入到 secret 字段中。
|
||||
3. 设置 `kube-apiserver` 的 `--experimental-encryption-provider-config` 参数，将其指定到配置文件所在位置。
|
||||
4. 重启您的 API server。
|
||||
|
||||
**重要：** 您的配置文件包含可以解密 etcd 内容的密钥，因此您必须正确限制主设备的权限，以便只有能运行 kube-apiserver 的用户才能读取它。
|
||||
|
||||
|
||||
<!--
|
||||
## Verifying that data is encrypted
|
||||
|
||||
Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or
|
||||
updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line
|
||||
program to retrieve the contents of your secret.
|
||||
|
||||
1. Create a new secret called `secret1` in the `default` namespace:
|
||||
-->
|
||||
## 验证数据是否被加密
|
||||
|
||||
数据在写入 etcd 时会被加密。重新启动你的 `kube-apiserver` 后，任何新创建或更新的密码在存储时都应该被加密。
|
||||
如果想要检查，你可以使用 `etcdctl` 命令行程序来检索你的加密内容。
|
||||
|
||||
1. 创建一个新的 secret，名称为 `secret1`，命名空间为 `default`：
|
||||
|
||||
```
|
||||
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Using the etcdctl commandline, read that secret out of etcd:
|
||||
-->
|
||||
2. 使用 etcdctl 命令行，从 etcd 中读取 secret：
|
||||
|
||||
```
|
||||
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
|
||||
```
|
||||
|
||||
<!--
|
||||
where `[...]` must be the additional arguments for connecting to the etcd server.
|
||||
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
|
||||
4. Verify the secret is correctly decrypted when retrieved via the API:
|
||||
-->
|
||||
这里的 `[...]` 是用来连接 etcd 服务的额外参数。
|
||||
3. 验证存储的密钥前缀是否为 `k8s:enc:aescbc:v1:`，这表明 `aescbc` provider 已加密结果数据。
|
||||
4. 通过 API 检索，验证 secret 是否被正确解密：
|
||||
|
||||
```
|
||||
kubectl describe secret secret1 -n default
|
||||
```
|
||||
|
||||
<!--
|
||||
should match `mykey: mydata`
|
||||
-->
|
||||
必须匹配 `mykey: mydata`
|
||||
|
||||
|
||||
<!--
|
||||
## Ensure all secrets are encrypted
|
||||
|
||||
Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
|
||||
-->
|
||||
## 确保所有 secret 都被加密
|
||||
|
||||
由于 secret 是在写入时被加密，因此对 secret 执行更新也会加密该内容。
|
||||
|
||||
```
|
||||
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
|
||||
```
|
||||
|
||||
<!--
|
||||
The command above reads all secrets and then updates them to apply server side encryption.
|
||||
If an error occurs due to a conflicting write, retry the command.
|
||||
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
|
||||
-->
|
||||
上面的命令读取所有 secret，然后使用服务端加密来进行更新。
|
||||
如果由于冲突写入而发生错误，请重试该命令。
|
||||
对于较大的集群，您可能希望通过命名空间或更新脚本来分割 secret。
|
||||
|
||||
|
||||
<!--
|
||||
## Rotating a decryption key
|
||||
|
||||
Changing the secret without incurring downtime requires a multi step operation, especially in
|
||||
the presence of a highly available deployment where multiple `kube-apiserver` processes are running.
|
||||
|
||||
1. Generate a new key and add it as the second key entry for the current provider on all servers
|
||||
2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
|
||||
3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
|
||||
4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
|
||||
5. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
|
||||
6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets
|
||||
|
||||
With a single `kube-apiserver`, step 2 may be skipped.
|
||||
-->
|
||||
## 回滚解密密钥
|
||||
|
||||
在不发生停机的情况下更改 secret 需要多步操作，特别是在有多个 `kube-apiserver` 进程正在运行的高可用部署的情况下。
|
||||
|
||||
1. 生成一个新密钥并将其添加为所有服务器上当前提供程序的第二个密钥条目
|
||||
2. 重新启动所有 `kube-apiserver` 进程以确保每台服务器都可以使用新密钥进行解密
|
||||
3. 将新密钥设置为 `keys` 数组中的第一个条目，以便在配置中使用其进行加密
|
||||
4. 重新启动所有 `kube-apiserver` 进程以确保每个服务器现在都使用新密钥进行加密
|
||||
5. 运行 `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` 以用新密钥加密所有现有的秘密
|
||||
6. 在使用新密钥备份 etcd 后，从配置中删除旧的解密密钥并更新所有密钥
|
||||
|
||||
如果只有一个 `kube-apiserver`，第 2 步可能可以忽略。
|
||||
|
||||
|
||||
<!--
|
||||
## Decrypting all data
|
||||
|
||||
To disable encryption at rest place the `identity` provider as the first entry in the config:
|
||||
-->
|
||||
## 解密所有数据
|
||||
|
||||
要禁用 rest 加密，请将 `identity` provider 作为配置中的第一个条目：
|
||||
|
||||
```yaml
|
||||
kind: EncryptionConfig
|
||||
apiVersion: v1
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
providers:
|
||||
- identity: {}
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: <BASE 64 ENCODED SECRET>
|
||||
```
|
||||
|
||||
<!--
|
||||
and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -`
|
||||
to force all secrets to be decrypted.
|
||||
-->
|
||||
并重新启动所有 `kube-apiserver` 进程。然后运行命令 `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` 强制解密所有 secret。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
approvers:
|
||||
- davidopp
|
||||
- filipg
|
||||
- piosz
|
||||
title: 关键插件 Pod 的调度保证
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
|
||||
|
||||
## 概览
|
||||
|
||||
除了 Kubernetes 核心组件，像运行在 master 机器上的 api-server、scheduler、controller-manager，由于各种原因，还有很多插件必须运行在一个普通的集群节点上（而不是 Kubernetes master）。
|
||||
这些插件中的一些对于一个功能完备的集群来说是非常关键的，例如 Heapster、DNS 以及 UI。
|
||||
如果一个关键的插件被移除（或者手动，或是类似升级这样具有副作用的其它操作），或者变成挂起状态（例如，当集群利用率过高，以及或者其它被调度到该空间中的挂起 Pod 被清理关键插件 Pod 给移除，或者由于其它原因导致节点上可用资源的总量发生变化），集群可能会停止正常工作。
|
||||
|
||||
|
||||
|
||||
## 二次调度器：关键插件的调度保证
|
||||
|
||||
二次调度器确保关键的插件总是能被调度（假定普通的 Pod 不存在时，集群具有足够的资源去运行关键插件 Pod）。
|
||||
如果调度器确定没有节点有足够资源去运行关键插件 Pod，假使有 Pod 已经运行在集群中（通过将关键插件 Pod 的条件 PodScheduled 设置为 false，原因设置为 Unschedulable 来指示），这时二次调度器通过清理一些 Pod 尽量去释放空间，然后调度器将调度该插件 Pod。
|
||||
|
||||
|
||||
|
||||
为了避免这种情况，当另一个 Pod 被调度到该空间，为了该关键插件，被选择的节点导致临时变成 "CriticalAddonsOnly" 的 taint（查看 [更多详情](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md)）。
|
||||
每个关键插件不得不容忍它，然而其它一些 Pod 不可能容忍该 taint。一旦该插件被成功调度，该 taint 会被移除。
|
||||
|
||||
*警告：* 当前对选中哪个节点，以及为了调度该关键 Pod 杀掉哪个 Pod 并没有任何保证，所以如果启用了二次调度器，任何 Pod 都可能被偶然的杀掉以达到目的。
|
||||
|
||||
|
||||
|
||||
## 配置
|
||||
|
||||
二次调度器应该被 [作为 static Pod 默认启用](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest)。
|
||||
它没有任何面向用户的配置（组件配置），或者 API，可以通过如下方式来禁用：
|
||||
|
||||
|
||||
|
||||
* 在集群安装过程中通过设置 `ENABLE_RESCHEDULER` 标志为 `false`
|
||||
* 在运行中的集群中从 master 节点删除它的 manifest（默认路径 `/etc/kubernetes/manifests/rescheduler.manifest`）
|
||||
|
||||
|
||||
|
||||
### 标记关键插件
|
||||
|
||||
想变成关键插件，必须运行在 `kube-system` Namespace 中（是基于标志可配置的），并且：
|
||||
* 将 `scheduler.alpha.kubernetes.io/critical-pod` annotation 设置为空字符串，并且
|
||||
* 将 PodSpec 的 `tolerations` 字段设置为 `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
|
||||
|
||||
第一个表示是一个关键 Pod。第二个是二次调度器算法必需的。
|
||||
|
||||
@@ -0,0 +1,453 @@
|
||||
---
|
||||
reviewers:
|
||||
- pipejakob
|
||||
- luxas
|
||||
- roberthbailey
|
||||
- jbeda
|
||||
title: 将 kubeadm 集群在 v1.8 版本到 v1.9 版本之间升级/降级
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
---
|
||||
reviewers:
|
||||
- pipejakob
|
||||
- luxas
|
||||
- roberthbailey
|
||||
- jbeda
|
||||
title: Upgrading/downgrading kubeadm clusters between v1.8 to v1.9
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
|
||||
This guide is for upgrading `kubeadm` clusters from version 1.8.x to 1.9.x, as well as 1.8.x to 1.8.y and 1.9.x to 1.9.y where `y > x`.
|
||||
See also [upgrading kubeadm clusters from 1.7 to 1.8](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/) if you're on a 1.7 cluster currently.
|
||||
|
||||
--->
|
||||
本文主要描述如何将 `kubeadm` 集群从 1.8.x 版本升级到 1.9.x 版本，包括从 1.8.x 版本升级到 1.8.y 版本，和从版本 1.9.x 版本到 1.9.y 版本（`y > x`）。
|
||||
如果您目前安装的是集群是 1.7 版本，也可以查看[ kubeadm clusters 集群从 1.7 版本升级到 1.8 版本](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
<!--
|
||||
|
||||
Before proceeding:
|
||||
|
||||
- You need to have a functional `kubeadm` Kubernetes cluster running version 1.8.0 or higher in order to use the process described here. Swap also needs to be disabled.
|
||||
- Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md) carefully.
|
||||
- `kubeadm upgrade` now allows you to upgrade etcd. `kubeadm upgrade` will also upgrade of etcd to 3.1.10 as part of upgrading from v1.8 to v1.9 by default. This is due to the fact that etcd 3.1.10 is the officially validated etcd version for Kubernetes v1.9. The upgrade is handled automatically by kubeadm for you.
|
||||
- Note that `kubeadm upgrade` will not touch any of your workloads, only Kubernetes-internal components. As a best-practice you should back up what's important to you. For example, any app-level state, such as a database an app might depend on (like MySQL or MongoDB) must be backed up beforehand.
|
||||
|
||||
--->
|
||||
升级之前：
|
||||
|
||||
- 您需要先安装一个版本为 1.8.0 或更高版本的 `kubeadm` Kubernetes 集群。另外还需要禁用节点的交换分区。
|
||||
- 一定要认真阅读[发布说明](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md)
|
||||
- `kubeadm upgrade` 可以更新 etcd。默认情况下，从 Kubernetes 1.8 版本升级到 1.9 版本时，`kubeadm upgrade` 也会升级 etcd 到 3.1.10 版本。这是由于 etcd3.1.10 是官方验证的 etcd 版本对于 kubernetes1.9。kubeadm 为您提供了自动化的升级过程。
|
||||
- 请注意，`kubeadm upgrade`命令 不会触及任何工作负载，只有 kubernetes 内部组件。作为最佳实践，您应当备份，因为备份相当的重要。例如，任何应用程序级别的状态（如应用程序可能依赖的数据库，如 mysql 或 mongoDB）必须预先备份。
|
||||
{{< caution >}}
|
||||
<!--
|
||||
|
||||
**Caution:** All the containers will get restarted after the upgrade, due to container spec hash value gets changed.
|
||||
|
||||
--->
|
||||
**注意:** 由于容器的具体哈希值改变了，所有的容器在升级之后会重新启动。
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
|
||||
Also, note that only one minor version upgrade is supported. For example, you can only upgrade from 1.8 to 1.9, not from 1.7 to 1.9.
|
||||
|
||||
--->
|
||||
同时，也要注意只有小范围的升级是支持的。例如，您只可以从 1.8 版本升级到 1.9 版本，但是不能从 1.7 版本升级到 1.9 版本。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
|
||||
## Upgrading your control plane
|
||||
|
||||
-->
|
||||
## 升级控制面板
|
||||
<!--
|
||||
|
||||
Execute these commands on your master node:
|
||||
|
||||
1. Install the most recent version of `kubeadm` using `curl` like so:
|
||||
|
||||
-->
|
||||
在您的 master 节点上执行这些命令：
|
||||
|
||||
1. 使用 `curl` 命令进行安装最新的版本的 `kubeadm` ，例如：
|
||||
```shell
|
||||
export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
|
||||
export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
|
||||
curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
|
||||
chmod a+rx /usr/bin/kubeadm
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
|
||||
**Caution:** Upgrading the `kubeadm` package on your system prior to upgrading the control plane causes a failed upgrade.
|
||||
Even though `kubeadm` ships in the Kubernetes repositories, it's important to install `kubeadm` manually. The kubeadm
|
||||
team is working on fixing this limitation.
|
||||
|
||||
--->
|
||||
**注意:** 在您的系统上升级控制面板之前升级 `kubeadm` 包会导致升级失败。
|
||||
尽管 `kubeadm` ships 在 kubernetes 仓库中，手动安装 `kubeadm` 是重要的。kubeadm 团队在努力解决这种手动安装的限制。
|
||||
{{< /caution >}}
|
||||
<!--
|
||||
|
||||
Verify that this download of kubeadm works and has the expected version:
|
||||
|
||||
--->
|
||||
验证 kubeadm 下载工作是否正常，并是否有达到预期的版本：
|
||||
```shell
|
||||
kubeadm version
|
||||
```
|
||||
<!--
|
||||
|
||||
2. On the master node, run the following:
|
||||
|
||||
--->
|
||||
2. 在master节点上运行如下命令：
|
||||
```shell
|
||||
kubeadm upgrade plan
|
||||
```
|
||||
<!--
|
||||
|
||||
You should see output similar to this:
|
||||
|
||||
--->
|
||||
可以得到类型的结果：
|
||||
<!--
|
||||
|
||||
```shell
|
||||
[preflight] Running pre-flight checks
|
||||
[upgrade] Making sure the cluster is healthy:
|
||||
[upgrade/health] Checking API Server health: Healthy
|
||||
[upgrade/health] Checking Node health: All Nodes are healthy
|
||||
[upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
|
||||
[upgrade/config] Making sure the configuration is correct:
|
||||
[upgrade/config] Reading configuration from the cluster...
|
||||
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
|
||||
[upgrade] Fetching available versions to upgrade to:
|
||||
[upgrade/versions] Cluster version: v1.8.1
|
||||
[upgrade/versions] kubeadm version: v1.9.0
|
||||
[upgrade/versions] Latest stable version: v1.9.0
|
||||
[upgrade/versions] Latest version in the v1.8 series: v1.8.6
|
||||
|
||||
Components that must be upgraded manually after you've upgraded the control plane with 'kubeadm upgrade apply':
|
||||
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
Kubelet 1 x v1.8.1 v1.8.6
|
||||
|
||||
Upgrade to the latest version in the v1.8 series:
|
||||
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
API Server v1.8.1 v1.8.6
|
||||
Controller Manager v1.8.1 v1.8.6
|
||||
Scheduler v1.8.1 v1.8.6
|
||||
Kube Proxy v1.8.1 v1.8.6
|
||||
Kube DNS 1.14.4 1.14.5
|
||||
|
||||
You can now apply the upgrade by executing the following command:
|
||||
|
||||
kubeadm upgrade apply v1.8.6
|
||||
|
||||
_____________________________________________________________________
|
||||
|
||||
Components that must be upgraded manually after you've upgraded the control plane with 'kubeadm upgrade apply':
|
||||
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
Kubelet 1 x v1.8.1 v1.9.0
|
||||
|
||||
Upgrade to the latest stable version:
|
||||
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
API Server v1.8.1 v1.9.0
|
||||
Controller Manager v1.8.1 v1.9.0
|
||||
Scheduler v1.8.1 v1.9.0
|
||||
Kube Proxy v1.8.1 v1.9.0
|
||||
Kube DNS 1.14.5 1.14.7
|
||||
|
||||
You can now apply the upgrade by executing the following command:
|
||||
|
||||
kubeadm upgrade apply v1.9.0
|
||||
|
||||
Note: Before you do can perform this upgrade, you have to update kubeadm to v1.9.0
|
||||
|
||||
_____________________________________________________________________
|
||||
```
|
||||
|
||||
--->
|
||||
|
||||
```shell
|
||||
[preflight] Running pre-flight checks
|
||||
[upgrade] Making sure the cluster is healthy:
|
||||
[upgrade/health] Checking API Server health: Healthy
|
||||
[upgrade/health] Checking Node health: All Nodes are healthy
|
||||
[upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
|
||||
[upgrade/config] Making sure the configuration is correct:
|
||||
[upgrade/config] Reading configuration from the cluster...
|
||||
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
|
||||
[upgrade] Fetching available versions to upgrade to:
|
||||
[upgrade/versions] Cluster version: v1.8.1
|
||||
[upgrade/versions] kubeadm version: v1.9.0
|
||||
[upgrade/versions] Latest stable version: v1.9.0
|
||||
[upgrade/versions] Latest version in the v1.8 series: v1.8.6
|
||||
|
||||
在升级控制面板并使用 'kubeadm upgrade apply' 后，必须手动升级组件：
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
Kubelet 1 x v1.8.1 v1.8.6
|
||||
|
||||
升级到最新的 v1.8 系列的版本：
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
API Server v1.8.1 v1.8.6
|
||||
Controller Manager v1.8.1 v1.8.6
|
||||
Scheduler v1.8.1 v1.8.6
|
||||
Kube Proxy v1.8.1 v1.8.6
|
||||
Kube DNS 1.14.4 1.14.5
|
||||
|
||||
您可以通过以下的命令来进行升级：
|
||||
kubeadm upgrade apply v1.8.6
|
||||
|
||||
_____________________________________________________________________
|
||||
|
||||
在升级控制面板并使用 'kubeadm upgrade apply' 后，必须手动升级组件：
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
Kubelet 1 x v1.8.1 v1.9.0
|
||||
|
||||
升级到最新和稳定的版本：
|
||||
COMPONENT CURRENT AVAILABLE
|
||||
API Server v1.8.1 v1.9.0
|
||||
Controller Manager v1.8.1 v1.9.0
|
||||
Scheduler v1.8.1 v1.9.0
|
||||
Kube Proxy v1.8.1 v1.9.0
|
||||
Kube DNS 1.14.5 1.14.7
|
||||
|
||||
您可以通过以下命令来进行升级：
|
||||
kubeadm upgrade apply v1.9.0
|
||||
|
||||
请注意：在您执行升级之前，您必须升级 kubeadm 到 v1.9.0 版本
|
||||
_____________________________________________________________________
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
The `kubeadm upgrade plan` checks that your cluster is upgradeable and fetches the versions available to upgrade to in an user-friendly way.
|
||||
|
||||
To check CoreDNS version, include the `--feature-gates=CoreDNS=true` flag to verify the CoreDNS version which will be installed in place of kube-dns.
|
||||
|
||||
3. Pick a version to upgrade to and run. For example:
|
||||
|
||||
--->
|
||||
`kubeadm upgrade plan` 命令检查您的集群是否处于可升级的状态并且获取可以以用户友好方式升级的版本。
|
||||
|
||||
检查 coreDNS 版本，包括 `--feature-gates=CoreDNS=true` 标志来验证存放 kube-dns 在某个位置的 coreDNS 版本。
|
||||
|
||||
3. 选择一个版本来进行升级和运行，例如：
|
||||
```shell
|
||||
kubeadm upgrade apply v1.9.0
|
||||
```
|
||||
<!--
|
||||
|
||||
You should see output similar to this:
|
||||
|
||||
--->
|
||||
可以得到如下类似的输出：
|
||||
```shell
|
||||
[preflight] Running pre-flight checks.
|
||||
[upgrade] Making sure the cluster is healthy:
|
||||
[upgrade/config] Making sure the configuration is correct:
|
||||
[upgrade/config] Reading configuration from the cluster...
|
||||
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
|
||||
[upgrade/version] You have chosen to upgrade to version "v1.9.0"
|
||||
[upgrade/versions] Cluster version: v1.8.1
|
||||
[upgrade/versions] kubeadm version: v1.9.0
|
||||
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
|
||||
[upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler]
|
||||
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.9.0"...
|
||||
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/etcd.yaml"
|
||||
[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/etcd.yaml"
|
||||
[upgrade/staticpods] Waiting for the kubelet to restart the component
|
||||
[apiclient] Found 1 Pods for label selector component=etcd
|
||||
[upgrade/staticpods] Component "etcd" upgraded successfully!
|
||||
[upgrade/staticpods] Writing upgraded Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-apiserver.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-controller-manager.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests802453804/kube-scheduler.yaml"
|
||||
[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-apiserver.yaml"
|
||||
[upgrade/staticpods] Waiting for the kubelet to restart the component
|
||||
[apiclient] Found 1 Pods for label selector component=kube-apiserver
|
||||
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
|
||||
[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-controller-manager.yaml"
|
||||
[upgrade/staticpods] Waiting for the kubelet to restart the component
|
||||
[apiclient] Found 1 Pods for label selector component=kube-controller-manager
|
||||
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
|
||||
[upgrade/staticpods] Moved upgraded manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests502223003/kube-scheduler.yaml"
|
||||
[upgrade/staticpods] Waiting for the kubelet to restart the component
|
||||
[apiclient] Found 1 Pods for label selector component=kube-scheduler
|
||||
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
|
||||
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
|
||||
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
|
||||
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
|
||||
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
|
||||
[addons] Applied essential addon: kube-dns
|
||||
[addons] Applied essential addon: kube-proxy
|
||||
|
||||
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.9.0". Enjoy!
|
||||
|
||||
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets in turn.
|
||||
```
|
||||
<!--
|
||||
|
||||
To upgrade the cluster with CoreDNS as the default internal DNS, invoke `kubeadm upgrade apply` with the `--feature-gates=CoreDNS=true` flag.
|
||||
`kubeadm upgrade apply` does the following:
|
||||
|
||||
- Checks that your cluster is in an upgradeable state:
|
||||
- The API server is reachable,
|
||||
- All nodes are in the `Ready` state
|
||||
- The control plane is healthy
|
||||
- Enforces the version skew policies.
|
||||
- Makes sure the control plane images are available or available to pull to the machine.
|
||||
- Upgrades the control plane components or rollbacks if any of them fails to come up.
|
||||
- Applies the new `kube-dns` and `kube-proxy` manifests and enforces that all necessary RBAC rules are created.
|
||||
- Creates new certificate and key files of apiserver and backs up old files if they're about to expire in 180 days.
|
||||
|
||||
--->
|
||||
|
||||
升级具有默认内部的 DNS 的 coreDNS 集群，调用具有 `--feature-gates=CoreDNS=true` 标记的 `kubeadm upgrade apply`。
|
||||
`kubeadm upgrade apply`按照如下进行：
|
||||
|
||||
- 检查集群是否处于可升级状态：
|
||||
-API服务器是否可达
|
||||
-所有的节点处于`Ready`状态
|
||||
-控制面板是健康的
|
||||
- 强制执行版本倾斜策略
|
||||
- 确保控制面板镜像可用或者可用于机器pull
|
||||
- 升级控制面板组件或者回滚如果其中一个无法出现
|
||||
- 应用新的`kube-dns`和`kube-proxy`清单并强制创建所必须的RBAC规则
|
||||
- 创建API服务器新的证书和秘钥文件，并备份旧文件（如果它们即将在180天到期）
|
||||
<!--
|
||||
|
||||
4. Manually upgrade your Software Defined Network (SDN).
|
||||
|
||||
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.
|
||||
Check the [addons](/docs/concepts/cluster-administration/addons/) page to find your CNI provider and see if there are additional upgrade steps necessary.
|
||||
|
||||
--->
|
||||
|
||||
4. 手动升级定义网络（SDN）的软件
|
||||
|
||||
容器网络接口（CNI）提供者具有升级说明指导。
|
||||
检查这个[插件](/docs/concepts/cluster-administration/addons/)页面来找到 CNI 提供者和查看是否需要额外的升级步骤。
|
||||
|
||||
<!--
|
||||
|
||||
## Upgrading your master and node packages
|
||||
|
||||
--->
|
||||
|
||||
## 升级master和node包
|
||||
<!--
|
||||
For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet` by executing the following commands:
|
||||
|
||||
1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:
|
||||
--->
|
||||
在集群中涉及 `$HOST` 的每个主机，执行如下命令来升级 `kubelet` ：
|
||||
|
||||
1. 准备主机维修，并标记为不可调度和驱逐工作负载：
|
||||
```shell
|
||||
kubectl drain $HOST --ignore-daemonsets
|
||||
```
|
||||
<!--
|
||||
|
||||
When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
|
||||
|
||||
--->
|
||||
当在 master 主机上运行这个命令，这个错误是可以预料的并且可以忽略（因为静态的 pods 运行在 master 上）
|
||||
```shell
|
||||
node "master" already cordoned
|
||||
error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to override): etcd-kubeadm, kube-apiserver-kubeadm, kube-controller-manager-kubeadm, kube-scheduler-kubeadm
|
||||
```
|
||||
<!--
|
||||
|
||||
2. Upgrade the Kubernetes package versions on the `$HOST` node by using a Linux distribution-specific package manager:
|
||||
|
||||
If the host is running a Debian-based distro such as Ubuntu, run:
|
||||
|
||||
--->
|
||||
2. 在 `$HOST` 节点上使用特定的包管理器升级 kubernetes 包版本：
|
||||
|
||||
如果主机运行 Debian-based 发行版如 ubuntu，运行如下：
|
||||
```shell
|
||||
apt-get update
|
||||
apt-get upgrade
|
||||
```
|
||||
<!--
|
||||
|
||||
If the host is running CentOS or the like, run:
|
||||
|
||||
--->
|
||||
如果主机运行centos或者类似，运行如下:
|
||||
```shell
|
||||
yum update
|
||||
```
|
||||
<!--
|
||||
Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:
|
||||
--->
|
||||
现在 `kubelet` 新的版本运行在主机上。在` $HOST` 上使用如下命令验证：
|
||||
```shell
|
||||
systemctl status kubelet
|
||||
```
|
||||
<!--
|
||||
|
||||
3. Bring the host back online by marking it schedulable:
|
||||
|
||||
--->
|
||||
3. 通过标记可计划的将主机从新联机：
|
||||
```shell
|
||||
kubectl uncordon $HOST
|
||||
```
|
||||
<!--
|
||||
4. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):
|
||||
--->
|
||||
在所以主机升级 `kubelet` 后，通过从任意位置运行以下命令例如从集群外来验证所有节点是否可用：
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
<!--
|
||||
If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
|
||||
--->
|
||||
如果上面命令的 `STATUS` 列显示所有的主机的 `Ready`，就完成了。
|
||||
<!--
|
||||
## Recovering from a failure state
|
||||
--->
|
||||
## ##从坏的状态中恢复
|
||||
<!--
|
||||
|
||||
If `kubeadm upgrade` somehow fails and fails to roll back, for example due to an unexpected shutdown during execution,
|
||||
you can run `kubeadm upgrade` again as it is idempotent and should eventually make sure the actual state is the desired state you are declaring.
|
||||
--->
|
||||
如果 `kubeadm upgrade` 以某种方式失败了并无法回滚，原因有在执行过程中出现意外关机，可以再次运行 `kubeadm upgrade`，因为它是幂等的，并且最终确保实际状态是期待的状态。
|
||||
|
||||
<!--
|
||||
You can use `kubeadm upgrade` to change a running cluster with `x.x.x -> x.x.x` with `--force`, which can be used to recover from a bad state.
|
||||
--->
|
||||
|
||||
可以使用 `kubeadm upgrade` 来更改运行的集群并使用具有 `--force` 参数的 `x.x.x --> x.x.x`，这样可以恢复坏的状态。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
approvers:
|
||||
- mtaufen
|
||||
- dawnchen
|
||||
cn-approvers:
|
||||
- xiaosuiba
|
||||
cn-reviwers:
|
||||
- pigletfly
|
||||
- zjj2wry
|
||||
- chentao1596
|
||||
title: 通过配置文件设置 Kubelet 参数
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
|
||||
在 Kubernetes 1.8 版本上，除了可以通过命令行参数外，还可以通过保存在硬盘的配置文件设置 Kubelet 的配置子集。
|
||||
将来，大部分现存的命令行参数都将被废弃，取而代之以配置文件的方式提供参数，以简化节点部署过程。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
- 需要安装 1.8 版本或更高版本的 Kubelet 二进制文件。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 创建配置文件
|
||||
|
||||
|
||||
`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集，该结构体在 [这里（v1alpha1）](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go) 可以找到。配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。请注意，这个结构体及配置文件 API 仍然为 alpha 版本，对其稳定性不作保证。
|
||||
|
||||
|
||||
在单独的文件夹中创建一个名为 `kubelet` 的文件，并保证 Kubelet 可以读取该文件夹及文件。您应该在这个 `kubelet` 文件中编写 Kubelet 配置。
|
||||
|
||||
|
||||
作为一个小技巧，您可以从活动节点生成配置文件，相关方法请查看 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。
|
||||
|
||||
|
||||
## 启动通过配置文件配置的 Kubelet 进程
|
||||
|
||||
|
||||
启动 Kubelet 需要将其 `--init-config-dir` 标志设置为包含 `kubelet` 文件的文件夹路径。Kubelet 将从 `kubelet` 文件中读取由 `KubeletConfiguration` 定义的参数，而不是从参数相关的命令行标志中读取。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
|
||||
## 与动态 Kubelet 配置的关系
|
||||
|
||||
|
||||
如果您正在使用 [动态 Kubelet 配置（Dynamic Kubelet Configuration）](/docs/tasks/administer-cluster/reconfigure-kubelet) 特性，那么自动回滚机制将认为通过 `--init-config-dir` 提供的配置是“最后已知正常（last known good）”的配置。
|
||||
|
||||
|
||||
请注意，`--init-config-dir` 文件的布局结构镜像了 ConfigMap 中用于动态 Kubelet 配置的数据结构；文件命名和 ConfigMap 的 key 相同，文件的内容是 ConfigMap 中相同数据结构的 JSON 或 YAML 表现形式。虽然以后可能会出现更多，但目前只有 kubelet:KubeletConfiguration 配置对。更多信息请查阅 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-mem-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-mem-demo-2-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "1.5Gi"
|
||||
requests:
|
||||
memory: "800Mi"
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-mem-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-mem-demo-3-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "800Mi"
|
||||
requests:
|
||||
memory: "100Mi"
|
||||
@@ -0,0 +1,9 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-mem-demo-4
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-mem-demo-4-ctr
|
||||
image: nginx
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: constraints-mem-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: constraints-mem-demo-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "800Mi"
|
||||
requests:
|
||||
memory: "600Mi"
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: mem-min-max-demo-lr
|
||||
spec:
|
||||
limits:
|
||||
- max:
|
||||
memory: 1Gi
|
||||
min:
|
||||
memory: 500Mi
|
||||
type: Container
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-mem-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: defalt-mem-demo-2-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "1Gi"
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-mem-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: default-mem-demo-3-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
requests:
|
||||
memory: "128Mi"
|
||||
@@ -0,0 +1,8 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: default-mem-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: default-mem-demo-ctr
|
||||
image: nginx
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: mem-limit-range
|
||||
spec:
|
||||
limits:
|
||||
- default:
|
||||
memory: 512Mi
|
||||
defaultRequest:
|
||||
memory: 256Mi
|
||||
type: Container
|
||||
@@ -0,0 +1,43 @@
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
component: scheduler
|
||||
tier: control-plane
|
||||
name: my-scheduler
|
||||
namespace: kube-system
|
||||
spec:
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
component: scheduler
|
||||
tier: control-plane
|
||||
version: second
|
||||
spec:
|
||||
containers:
|
||||
- command:
|
||||
- /usr/local/bin/kube-scheduler
|
||||
- --address=0.0.0.0
|
||||
- --leader-elect=false
|
||||
- --scheduler-name=my-scheduler
|
||||
image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 10251
|
||||
initialDelaySeconds: 15
|
||||
name: kube-second-scheduler
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 10251
|
||||
resources:
|
||||
requests:
|
||||
cpu: '0.1'
|
||||
securityContext:
|
||||
privileged: false
|
||||
volumeMounts: []
|
||||
hostNetwork: false
|
||||
hostPID: false
|
||||
volumes: []
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
---
|
||||
reviewers:
|
||||
- caseydavenport
|
||||
title: 使用 Calico 作为 NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- This page shows a couple of quick ways to create a Calico cluster on Kubernetes. -->
|
||||
本页展示了两种在 Kubernetes 上快速创建 Calico 集群的方法。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
<!-- Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster. -->
|
||||
|
||||
决定您想部署一个[云](#在-Google-Kubernetes-Engine-GKE-上创建一个-Calico-集群) 还是 [本地](#使用-kubeadm-创建一个本地-Calico-集群) 集群。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!-- ## Creating a Calico cluster with Google Kubernetes Engine (GKE)
|
||||
|
||||
**Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
|
||||
|
||||
1. To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
|
||||
|
||||
**Syntax**
|
||||
```shell
|
||||
gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
|
||||
```
|
||||
|
||||
**Example**
|
||||
```shell
|
||||
gcloud container clusters create my-calico-cluster --enable-network-policy
|
||||
```
|
||||
|
||||
1. To verify the deployment, use the following command.
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
The Calico pods begin with `calico`. Check to make sure each one has a status of `Running`.
|
||||
-->
|
||||
## 在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群
|
||||
|
||||
**先决条件**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts)
|
||||
|
||||
1. 启动一个带有 Calico 的 GKE 集群，只需加上flag `--enable-network-policy`。
|
||||
|
||||
**语法**
|
||||
```shell
|
||||
gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
|
||||
```
|
||||
|
||||
**示例**
|
||||
```shell
|
||||
gcloud container clusters create my-calico-cluster --enable-network-policy
|
||||
```
|
||||
|
||||
1. 使用如下命令验证部署是否正确。
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
Calico 的 pods 名以 `calico` 打头，检查确认每个 pods 状态为 `Running`。
|
||||
<!--
|
||||
## Creating a local Calico cluster with kubeadm
|
||||
|
||||
To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the
|
||||
[Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
|
||||
-->
|
||||
|
||||
## 使用 kubeadm 创建一个本地 Calico 集群
|
||||
|
||||
在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考
|
||||
[Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!-- Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
|
||||
集群运行后，您可以按照 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
|
||||
{{% /capture %}}
|
||||
+133
@@ -0,0 +1,133 @@
|
||||
---
|
||||
reviewers:
|
||||
- danwent
|
||||
title: 使用 Cilium 作为 NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- This page shows how to use Cilium for NetworkPolicy.
|
||||
|
||||
For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro). -->
|
||||
|
||||
本页展示了如何使用 Cilium 作为 NetworkPolicy。
|
||||
|
||||
关于 Cilium 的背景知识，请阅读 [Cilium 介绍](https://cilium.readthedocs.io/en/latest/intro)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
## Deploying Cilium on Minikube for Basic Testing
|
||||
|
||||
To get familiar with Cilium easily you can follow the
|
||||
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
|
||||
to perform a basic DaemonSet installation of Cilium in minikube.
|
||||
|
||||
Installation in a minikube setup uses a simple ''all-in-one'' YAML
|
||||
file that includes DaemonSet configurations for Cilium, to connect
|
||||
to the minikube's etcd instance as well as appropriate RBAC settings:
|
||||
-->
|
||||
|
||||
## 在 Minikube 上部署 Cilium 用于基本测试
|
||||
|
||||
为了轻松熟悉 Cilium 您可以根据[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/latest/gettingstarted/minikube/)在 minikube 中执行一个 cilium 的基本的 DaemonSet 安装。
|
||||
|
||||
在 minikube 中的安装配置使用一个简单的“一体化” YAML 文件，包括了 Cilium 的 DaemonSet 配置，连接 minikube 的 etcd 实例，以及适当的 RBAC 设置。
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
|
||||
configmap "cilium-config" created
|
||||
secret "cilium-etcd-secrets" created
|
||||
serviceaccount "cilium" created
|
||||
clusterrolebinding "cilium" created
|
||||
daemonset "cilium" created
|
||||
clusterrole "cilium" created
|
||||
```
|
||||
<!--
|
||||
The remainder of the Getting Started Guide explains how to enforce both L3/L4
|
||||
(i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
|
||||
policies using an example application.
|
||||
-->
|
||||
入门指南其余的部分用一个示例应用说明了如何强制执行L3/L4（即 IP 地址+端口）的安全策略以及L7 （如 HTTP）的安全策略。
|
||||
|
||||
<!--
|
||||
## Deploying Cilium for Production Use
|
||||
|
||||
For detailed instructions around deploying Cilium for production, see:
|
||||
[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
This documentation includes detailed requirements, instructions and example
|
||||
production DaemonSet files.
|
||||
-->
|
||||
|
||||
## 部署 Cilium 用于生产用途
|
||||
关于部署 Cilium 用于生产的详细说明，请见[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
，此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
<!--
|
||||
## Understanding Cilium components
|
||||
|
||||
Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
|
||||
this list of Pods run:
|
||||
-->
|
||||
## 了解 Cilium 组件
|
||||
|
||||
部署使用 Cilium 的集群会添加 Pods 到`kube-system`命名空间。 要查看此Pod列表，运行：
|
||||
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
<!-- You'll see a list of Pods similar to this: -->
|
||||
您将看到像这样的 Pods 列表：
|
||||
|
||||
```console
|
||||
NAME DESIRED CURRENT READY NODE-SELECTOR AGE
|
||||
cilium 1 1 1 <none> 2m
|
||||
...
|
||||
```
|
||||
<!--
|
||||
There are two main components to be aware of:
|
||||
|
||||
- One `cilium` Pod runs on each node in your cluster and enforces network policy
|
||||
on the traffic to/from Pods on that node using Linux BPF.
|
||||
- For production deployments, Cilium should leverage the key-value store cluster
|
||||
(e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.
|
||||
The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
includes an example DaemonSet which can be customized to point to this key-value
|
||||
store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such
|
||||
configuration because it automatically connects to the minikube's etcd instance.
|
||||
-->
|
||||
有两个主要组件需要注意：
|
||||
|
||||
- 在集群中的每个节点上都会运行一个 `cilium` Pod，并利用Linux BPF执行网络策略管理该节点上进出 Pod 的流量。
|
||||
- 对于生产部署，Cilium 应该复用 Kubernetes 所使用的键值存储集群（如 etcd），其通常在Kubernetes 的 master 节点上运行。
|
||||
[Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
|
||||
包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。
|
||||
简单的 minikube 的“一体化” DaemonSet 不需要这样的配置，因为它会自动连接到 minikube 的 etcd 实例。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!-- Once your cluster is running, you can follow the
|
||||
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
|
||||
to try out Kubernetes NetworkPolicy with Cilium.
|
||||
Have fun, and if you have questions, contact us using the
|
||||
[Cilium Slack Channel](https://cilium.herokuapp.com/). -->
|
||||
群集运行后，您可以按照[声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/)
|
||||
用 Cilium 试用 Kubernetes NetworkPolicy。
|
||||
玩得开心，如果您有任何疑问，请联系我们
|
||||
[Cilium Slack Channel](https://cilium.herokuapp.com/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
---
|
||||
reviewers:
|
||||
- murali-reddy
|
||||
title: 使用 Kube-router 作为 NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!-- This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy. -->
|
||||
本页展示了如何使用 [Kube-router](https://github.com/cloudnativelabs/kube-router) 作为 NetworkPolicy。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
<!-- You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc. -->
|
||||
|
||||
您需要拥有一个正在运行的 Kubernetes 集群。如果您还没有集群，可以使用任意的集群安装器如 Kops，Bootkube，Kubeadm 等创建一个。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!-- ## Installing Kube-router addon
|
||||
The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon. -->
|
||||
|
||||
## 安装 Kube-router 插件
|
||||
Kube-router 插件自带一个Network Policy 控制器，监视来自于Kubernetes API server 的 NetworkPolicy 和 pods 的变化，根据策略指示配置 iptables 规则和 ipsets 来允许或阻止流量。请根据 [尝试通过集群安装器使用 Kube-router](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 指南安装 Kube-router 插件。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!-- Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
|
||||
在您安装 Kube-router 插件后，可以根据 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
|
||||
{{% /capture %}}
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
reviewers:
|
||||
- chrismarino
|
||||
title: 使用 Romana 作为 NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- This page shows how to use Romana for NetworkPolicy. -->
|
||||
本页展示如何使用 Romana 作为 NetworkPolicy。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!-- Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -->
|
||||
完成[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)中的1、2、3步。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
## Installing Romana with kubeadm
|
||||
|
||||
Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadmin.
|
||||
|
||||
## Applying network policies
|
||||
|
||||
To apply network policies use one of the following:
|
||||
|
||||
* [Romana network policies](https://github.com/romana/romana/wiki/Romana-policies).
|
||||
* [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
|
||||
* The NetworkPolicy API.
|
||||
-->
|
||||
## 使用 kubeadm 安装 Romana
|
||||
|
||||
按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)获取 kubeadmin。
|
||||
|
||||
## 运用网络策略
|
||||
|
||||
使用以下的一种方式去运用网络策略：
|
||||
|
||||
* [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
|
||||
* [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
|
||||
* NetworkPolicy API
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
Once your have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
|
||||
-->
|
||||
Romana 安装完成后，您可以按照[声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 Kubernetes NetworkPolicy。
|
||||
|
||||
{{% /capture %}}
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
reviewers:
|
||||
- bboreham
|
||||
title: 使用 Weave Net 作为 NetworkPolicy
|
||||
content_template: templates/task
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- This page shows how to use Weave Net for NetworkPolicy. -->
|
||||
|
||||
本页展示了如何使用使用 Weave Net 作为 NetworkPolicy。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
<!--
|
||||
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
|
||||
-->
|
||||
您需要拥有一个 Kubernetes 集群。按照[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)来引导一个。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
## Install the Weave Net addon
|
||||
|
||||
Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.
|
||||
|
||||
The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
|
||||
-->
|
||||
## 安装 Weave Net 插件
|
||||
|
||||
按照[通过插件集成Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)指南。
|
||||
|
||||
Kubernetes 的 Weave Net 插件带有[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，可自动监控 Kubernetes 所有名称空间中的任何 NetworkPolicy 注释。 配置`iptables`规则以允许或阻止策略指示的流量。
|
||||
<!--
|
||||
## Test the installation
|
||||
|
||||
Verify that the weave works.
|
||||
|
||||
Enter the following command:
|
||||
-->
|
||||
|
||||
## 测试安装
|
||||
|
||||
验证 weave 是否有效。
|
||||
|
||||
输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl get po -n kube-system -o wide
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
输出类似这样：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3
|
||||
weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu
|
||||
weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode
|
||||
weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2
|
||||
```
|
||||
|
||||
<!-- Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.) -->
|
||||
每个 Node 都有一个 weave Pod，所有 Pod 都是`Running`和`2/2 READY`。（`2/2`表示每个Pod都有`weave`和`weave-npc`。）
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
|
||||
-->
|
||||
|
||||
安装Weave Net插件后，您可以按照[声明网络策略](/docs/tasks/administration-cluster/declare-network-policy/)来试用 Kubernetes NetworkPolicy。 如果您有任何疑问，请联系我们[#weave-community on Slack 或 Weave User Group](https://github.com/weaveworks/weave#getting-help)。
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: no-annotation
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
containers:
|
||||
- name: pod-with-no-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: annotation-default-scheduler
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
schedulerName: default-scheduler
|
||||
containers:
|
||||
- name: pod-with-default-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -0,0 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: annotation-second-scheduler
|
||||
labels:
|
||||
name: multischeduler-example
|
||||
spec:
|
||||
schedulerName: my-scheduler
|
||||
containers:
|
||||
- name: pod-with-second-annotation-container
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
@@ -0,0 +1,16 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: quota-mem-cpu-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: quota-mem-cpu-demo-2-ctr
|
||||
image: redis
|
||||
resources:
|
||||
limits:
|
||||
memory: "1Gi"
|
||||
cpu: "800m"
|
||||
requests:
|
||||
memory: "700Mi"
|
||||
cpu: "400m"
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: quota-mem-cpu-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: quota-mem-cpu-demo-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "800Mi"
|
||||
cpu: "800m"
|
||||
requests:
|
||||
memory: "600Mi"
|
||||
cpu: "400m"
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: mem-cpu-demo
|
||||
spec:
|
||||
hard:
|
||||
requests.cpu: "1"
|
||||
requests.memory: 1Gi
|
||||
limits.cpu: "2"
|
||||
limits.memory: 2Gi
|
||||
@@ -0,0 +1,11 @@
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: pvc-quota-demo-2
|
||||
spec:
|
||||
storageClassName: manual
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 4Gi
|
||||
@@ -0,0 +1,11 @@
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: pvc-quota-demo
|
||||
spec:
|
||||
storageClassName: manual
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 3Gi
|
||||
@@ -0,0 +1,9 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: object-quota-demo
|
||||
spec:
|
||||
hard:
|
||||
persistentvolumeclaims: "1"
|
||||
services.loadbalancers: "2"
|
||||
services.nodeports: "0"
|
||||
@@ -0,0 +1,14 @@
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: pod-quota-demo
|
||||
spec:
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
purpose: quota-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: pod-quota-demo
|
||||
image: nginx
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: 配置命名空间下pod总数
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文主要描述如何配置一个命名空间下可运行的pod总数。资源配额详细信息可查看：[资源配额](/docs/api-reference/v1.7/#resourcequota-v1-core)
|
||||
。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 创建一个命名空间
|
||||
|
||||
首先创建一个命名空间，这样可以将本次操作中创建的资源与集群其他资源隔离开来。
|
||||
|
||||
```shell
|
||||
kubectl create namespace quota-pod-example
|
||||
```
|
||||
|
||||
## 创建资源配额
|
||||
|
||||
下面是一个资源配额的配置文件：
|
||||
|
||||
{{< code file="quota-pod.yaml" >}}
|
||||
|
||||
创建这个资源配额：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/administer-cluster/quota-pod.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
查看资源配额的详细信息：
|
||||
|
||||
```shell
|
||||
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
从输出的信息我们可以看到，该命名空间下pod的配额是2个，目前创建的pods数为0，配额使用率为0。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
hard:
|
||||
pods: "2"
|
||||
status:
|
||||
hard:
|
||||
pods: "2"
|
||||
used:
|
||||
pods: "0"
|
||||
```
|
||||
|
||||
下面是一个Deployment的配置文件：
|
||||
|
||||
{{< code file="quota-pod-deployment.yaml" >}}
|
||||
|
||||
在配置文件中， `replicas: 3` 告诉kubernetes尝试创建三个pods，且运行相同的应用。
|
||||
|
||||
创建这个Deployment：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/administer-cluster/quota-pod-deployment.yaml --namespace=quota-pod-example
|
||||
```
|
||||
|
||||
查看Deployment的详细信息：
|
||||
|
||||
```shell
|
||||
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
|
||||
```
|
||||
|
||||
从输出的信息我们可以看到，尽管尝试创建三个pod，但是由于配额的限制，只有两个pod能被成功创建。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
...
|
||||
replicas: 3
|
||||
...
|
||||
status:
|
||||
availableReplicas: 2
|
||||
...
|
||||
lastUpdateTime: 2017-07-07T20:57:05Z
|
||||
message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden:
|
||||
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
|
||||
```
|
||||
|
||||
## 清理
|
||||
|
||||
删除命名空间：
|
||||
|
||||
```shell
|
||||
kubectl delete namespace quota-pod-example
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
### 对于集群管理
|
||||
|
||||
* [配置命名空间下，内存默认的request值和limit值](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [配置命名空间下，CPU默认的request值和limit值](/docs/tasks/administer-cluster/cpu-default-namespace/)
|
||||
|
||||
* [配置命名空间下，内存的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [配置命名空间下，CPU的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [配置命名空间下，内存和CPU的配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [配置命名空间下，API对象的配额](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
### 对于应用开发
|
||||
|
||||
* [给容器和pod分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [给容器和pod分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [配置pod的QoS](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: pod-demo
|
||||
spec:
|
||||
hard:
|
||||
pods: "2"
|
||||
@@ -0,0 +1,11 @@
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: pvc-quota-demo-2
|
||||
spec:
|
||||
storageClassName: manual
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 4Gi
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
approvers:
|
||||
- chrismarino
|
||||
title: 使用 Romana 来提供 NetworkPolicy
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
本页展示怎么样使用 Romana 来提供 NetworkPolicy
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
完成 [kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)中的步骤1、2和3
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 使用 kubeadm 安装 Romana
|
||||
|
||||
|
||||
按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)中使用 kubeadm 的方式安装
|
||||
|
||||
|
||||
## 应用网络策略
|
||||
|
||||
|
||||
要应用网络策略，请使用以下方式之一：
|
||||
|
||||
|
||||
* [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
|
||||
* [Romana 网络策略示例](https://github.com/romana/core/tree/master/policy)
|
||||
|
||||
* NetworkPolicy API
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
Romana 安装完成之后，您可以通过 [NetworkPolicy 入门指南](/docs/getting-started-guides/network-policy/walkthrough)去尝试使用 Kubernetes NetworkPolicy
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
approvers:
|
||||
- jsafrane
|
||||
title: 静态Pods
|
||||
---
|
||||
|
||||
**如果你正在运行Kubernetes集群并且使用静态pods在每个节点上起一个pod，那么最好使用[DaemonSet](/cn/docs/concepts/workloads/controllers/daemonset/)!**
|
||||
|
||||
*静态pods*直接由特定节点上的kubelet进程来管理，不通过主控节点上的API服务器。静态pod不关联任何replication controller，它由kubelet进程自己来监控，当pod崩溃时重启该pod。对于静态pod没有健康检查。静态pod始终绑定在某一个kubelet，并且始终运行在同一个节点上。
|
||||
|
||||
Kubelet自动为每一个静态pod在Kubernetes的API服务器上创建一个镜像Pod（Mirror Pod），因此可以在API服务器查询到该pod，但是不被API服务器控制（例如不能删除）。
|
||||
|
||||
## 静态pod创建
|
||||
|
||||
静态pod有两种创建方式：用配置文件或者通过HTTP。
|
||||
|
||||
### 配置文件
|
||||
|
||||
配置文件就是放在特定目录下的标准的JSON或YAML格式的pod定义文件。用`kubelet --pod-manifest-path=<the directory>`来启动kubelet进程，kubelet将会周期扫描<the directory>这个目录，根据这个目录下出现或消失的YAML/JSON文件来创建或删除静态pod。
|
||||
|
||||
下面例子用静态pod的方式启动一个nginx的Web服务器：
|
||||
|
||||
1. 选择一个节点来运行静态pod。这个例子中就是`my-node1`。
|
||||
|
||||
```
|
||||
[joe@host ~] $ ssh my-node1
|
||||
```
|
||||
|
||||
2. 选择一个目录，例如/etc/kubelet.d，把web服务器的pod定义文件放在这个目录下，例如`/etc/kubelet.d/static-web.yaml`:
|
||||
|
||||
```
|
||||
[root@my-node1 ~] $ mkdir /etc/kubelet.d/
|
||||
[root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: static-web
|
||||
labels:
|
||||
role: myrole
|
||||
spec:
|
||||
containers:
|
||||
- name: web
|
||||
image: nginx
|
||||
ports:
|
||||
- name: web
|
||||
containerPort: 80
|
||||
protocol: TCP
|
||||
EOF
|
||||
```
|
||||
|
||||
3.配置节点上的kubelet使用这个目录，kubelet启动时增加`--pod-manifest-path=/etc/kubelet.d/`参数。如果是Fedora系统，在Kubelet配置文件/etc/kubernetes/kubelet中添加下面这行：
|
||||
|
||||
```
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
|
||||
```
|
||||
|
||||
如果是其它Linux发行版或者其它Kubernetes安装方式，配置方法可能会不一样。
|
||||
|
||||
4. 重启kubelet。如果是Fedora系统，就是：
|
||||
|
||||
```
|
||||
[root@my-node1 ~] $ systemctl restart kubelet
|
||||
```
|
||||
|
||||
## 通过HTTP创建静态Pods
|
||||
|
||||
Kubelet周期地从--manifest-url=<URL>参数指定的地址下载文件，并且把它翻译成JSON/YAML格式的pod定义。此后的操作方式与--pod-manifest-path=<directory>相同，kubelet会不时地重新下载该文件，当文件变化时对应地终止或启动静态pod（如下）。
|
||||
|
||||
## 静态pods的动作行为
|
||||
|
||||
kubelet启动时，由`--pod-manifest-path=` or `--manifest-url=`参数指定的目录下定义的所有pod都会自动创建，例如，我们示例中的static-web。 （可能要花些时间拉取nginx镜像，耐心等待...）
|
||||
|
||||
```shell
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
|
||||
```
|
||||
|
||||
如果我们查看Kubernetes的API服务器（运行在主机 `my-master`），可以看到这里创建了一个新的镜像Pod：
|
||||
|
||||
```shell
|
||||
[joe@host ~] $ ssh my-master
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
静态pod的标签会传递给镜像Pod，可以用来过滤或筛选。
|
||||
|
||||
需要注意的是，我们不能通过API服务器来删除静态pod（例如，通过 [`kubectl`](/docs/user-guide/kubectl/) 命令），kebelet不会删除它。
|
||||
|
||||
```shell
|
||||
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
|
||||
pods/static-web-my-node1
|
||||
[joe@my-master ~] $ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
static-web-my-node1 1/1 Running 0 12s
|
||||
```
|
||||
|
||||
返回`my-node1`主机，我们尝试手动终止容器，可以看到kubelet很快就会自动重启容器。
|
||||
|
||||
```shell
|
||||
[joe@host ~] $ ssh my-node1
|
||||
[joe@my-node1 ~] $ docker stop f6d05272b57e
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
|
||||
```
|
||||
|
||||
## 静态pods的动态增加和删除
|
||||
|
||||
运行中的kubelet周期扫描配置的目录（我们这个例子中就是`/etc/kubelet.d`）下文件的变化，当这个目录中有文件出现或消失时创建或删除pods。
|
||||
|
||||
```shell
|
||||
[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
// no nginx container is running
|
||||
[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```
|
||||
@@ -0,0 +1,329 @@
|
||||
---
|
||||
title: 在 Kubernetes 集群中使用 sysctl
|
||||
reviewers:
|
||||
- sttts
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
---
|
||||
title: Using sysctls in a Kubernetes Cluster
|
||||
reviewers:
|
||||
- sttts
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
|
||||
<!--
|
||||
This document describes how to configure and use kernel parameters within a
|
||||
Kubernetes cluster using the sysctl interface.
|
||||
--->
|
||||
本文档介绍如何通过 sysctl 接口在 Kubernetes 集群中配置和使用内核参数。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Listing all Sysctl Parameters
|
||||
--->
|
||||
## 获取 Sysctl 的参数列表
|
||||
|
||||
<!--
|
||||
In Linux, the sysctl interface allows an administrator to modify kernel
|
||||
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
|
||||
process file system. The parameters cover various subsystems such as:
|
||||
--->
|
||||
在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/` 虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
|
||||
|
||||
<!--
|
||||
- kernel (common prefix: `kernel.`)
|
||||
- networking (common prefix: `net.`)
|
||||
- virtual memory (common prefix: `vm.`)
|
||||
- MDADM (common prefix: `dev.`)
|
||||
- More subsystems are described in [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
|
||||
--->
|
||||
- 内核子系统 (通常前缀为: `kernel.`)
|
||||
- 网络子系统 (通常前缀为: `net.`)
|
||||
- 虚拟内存子系统 (通常前缀为: `vm.`)
|
||||
- MDADM 子系统 (通常前缀为: `dev.`)
|
||||
- 更多子系统请参见 [内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
|
||||
|
||||
<!--
|
||||
To get a list of all parameters, you can run
|
||||
--->
|
||||
若要获取完整的参数列表，请执行以下命令
|
||||
|
||||
```shell
|
||||
$ sudo sysctl -a
|
||||
```
|
||||
|
||||
<!--
|
||||
## Enabling Unsafe Sysctls
|
||||
--->
|
||||
## 启用非安全的 Sysctl 参数
|
||||
|
||||
<!--
|
||||
Sysctls are grouped into _safe_ and _unsafe_ sysctls. In addition to proper
|
||||
namespacing a _safe_ sysctl must be properly _isolated_ between pods on the same
|
||||
node. This means that setting a _safe_ sysctl for one pod
|
||||
--->
|
||||
sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod 之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
|
||||
|
||||
<!--
|
||||
- must not have any influence on any other pod on the node
|
||||
- must not allow to harm the node's health
|
||||
- must not allow to gain CPU or memory resources outside of the resource limits
|
||||
of a pod.
|
||||
--->
|
||||
- 必须不能影响到节点上的其他 Pod
|
||||
- 必须不能损害节点的健康
|
||||
- 必须不允许使用超出 Pod 的资源限制的 CPU 或内存资源。
|
||||
|
||||
<!--
|
||||
By far, most of the _namespaced_ sysctls are not necessarily considered _safe_.
|
||||
The following sysctls are supported in the _safe_ set:
|
||||
--->
|
||||
至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。以下几种 sysctl 参数是 _安全的_：
|
||||
|
||||
- `kernel.shm_rmid_forced`,
|
||||
- `net.ipv4.ip_local_port_range`,
|
||||
- `net.ipv4.tcp_syncookies`.
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
|
||||
--->
|
||||
**注意**: 示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
This list will be extended in future Kubernetes versions when the kubelet
|
||||
supports better isolation mechanisms.
|
||||
--->
|
||||
在未来的 Kubernetes 版本中，若kubelet 支持更好的隔离机制，则上述列表中将会列出更多 _安全的_ sysctl 参数。
|
||||
|
||||
<!--
|
||||
All _safe_ sysctls are enabled by default.
|
||||
--->
|
||||
所有 _安全的_ sysctl 参数都默认启用。
|
||||
|
||||
<!--
|
||||
All _unsafe_ sysctls are disabled by default and must be allowed manually by the
|
||||
cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
|
||||
scheduled, but will fail to launch.
|
||||
--->
|
||||
所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
|
||||
|
||||
<!--
|
||||
With the warning above in mind, the cluster admin can allow certain _unsafe_
|
||||
sysctls for very special situations like e.g. high-performance or real-time
|
||||
application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
|
||||
flag of the kubelet, e.g.:
|
||||
--->
|
||||
参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），才可以启用特定的 _非安全的_ sysctl 参数。如需启用 _非安全的_ sysctl 参数，请您在每个节点上分别设置 kubelet 命令行参数，例如：
|
||||
|
||||
```shell
|
||||
$ kubelet --allowed-unsafe-sysctls \
|
||||
'kernel.msg*,net.ipv4.route.min_pmtu' ...
|
||||
```
|
||||
<!--
|
||||
For minikube, this can be done via the `extra-config` flag:
|
||||
--->
|
||||
如果您使用 minikube，可以通过 `extra-config` 参数来配置：
|
||||
|
||||
```shell
|
||||
$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
|
||||
```
|
||||
<!--
|
||||
Only _namespaced_ sysctls can be enabled this way.
|
||||
--->
|
||||
只有 _有命名空间的_ sysctl 参数可以通过该方式启用。
|
||||
|
||||
<!--
|
||||
## Setting Sysctls for a Pod
|
||||
--->
|
||||
## 设置 Pod 的 Sysctl 参数
|
||||
|
||||
<!--
|
||||
A number of sysctls are _namespaced_ in today's Linux kernels. This means that
|
||||
they can be set independently for each pod on a node. Only namespaced sysctls
|
||||
are configurable via the pod securityContext within Kubernetes.
|
||||
--->
|
||||
目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。 这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。 在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
|
||||
|
||||
<!--
|
||||
The following sysctls are known to be namespaced. This list could change
|
||||
in future versions of the Linux kernel.
|
||||
--->
|
||||
以下列出有命名空间的 sysctl 参数，在未来的 Linux 内核版本中，此列表可能会发生变化。
|
||||
|
||||
- `kernel.shm*`,
|
||||
- `kernel.msg*`,
|
||||
- `kernel.sem`,
|
||||
- `fs.mqueue.*`,
|
||||
- `net.*`.
|
||||
|
||||
<!--
|
||||
Sysctls with no namespace are called _node-level_ sysctls. If you need to set
|
||||
them, you must manually configure them on each node's operating system, or by
|
||||
using a DaemonSet with privileged containers.
|
||||
--->
|
||||
没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。 如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，或者通过在 DaemonSet 中运行特权模式容器来配置。
|
||||
|
||||
<!--
|
||||
Use the pod securityContext to configure namespaced sysctls. The securityContext
|
||||
applies to all containers in the same pod.
|
||||
--->
|
||||
可使用 pod 的 securityContext 来配置有命名空间的 sysctl 参数，securityContext 应用于同一个 pod 中的所有容器。
|
||||
|
||||
<!--
|
||||
This example uses the pod securityContext to set a safe sysctl
|
||||
`kernel.shm_rmid_forced` and two unsafe sysctls `net.ipv4.route.min_pmtu` and
|
||||
`kernel.msgmax` There is no distinction between _safe_ and _unsafe_ sysctls in
|
||||
the specification.
|
||||
--->
|
||||
此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数 `kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数 `net.ipv4.route.min_pmtu`和 `kernel.msgmax` 进行设置。在 Pod 规格中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Only modify sysctl parameters after you understand their effects, to avoid
|
||||
destabilizing your operating system.
|
||||
--->
|
||||
为了避免破坏操作系统的稳定性，请您在了解变更后果之后再修改 sysctl 参数。
|
||||
{{< /warning >}}
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: sysctl-example
|
||||
spec:
|
||||
securityContext:
|
||||
sysctls:
|
||||
- name: kernel.shm_rmid_forced
|
||||
value: "0"
|
||||
- name: net.ipv4.route.min_pmtu
|
||||
value: "552"
|
||||
- name: kernel.msgmax
|
||||
value: "65536"
|
||||
...
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
|
||||
is at-your-own-risk and can lead to severe problems like wrong behavior of
|
||||
containers, resource shortage or complete breakage of a node.
|
||||
--->
|
||||
**警告**：由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，用户需自行承担风险。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
It is good practice to consider nodes with special sysctl settings as
|
||||
_tainted_ within a cluster, and only schedule pods onto them which need those
|
||||
sysctl settings. It is suggested to use the Kubernetes [_taints and toleration_
|
||||
feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) to implement this.
|
||||
--->
|
||||
最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _受感染的_，并且只调度需要使用到特殊 sysctl 设置的 Pod 到这些节点上。 建议使用 Kubernetes 的 [ _taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
|
||||
|
||||
<!--
|
||||
A pod with the _unsafe_ sysctls will fail to launch on any node which has not
|
||||
enabled those two _unsafe_ sysctls explicitly. As with _node-level_ sysctls it
|
||||
is recommended to use
|
||||
[_taints and toleration_ feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) or
|
||||
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
|
||||
to schedule those pods onto the right nodes.
|
||||
--->
|
||||
设置了 _非安全的_ sysctl 参数的 pod，在禁用了以下两种 _非安全的_ sysctl 参数配置的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
|
||||
[_taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
|
||||
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
|
||||
以便将 Pod 调度到正确的节点之上。
|
||||
|
||||
## PodSecurityPolicy
|
||||
|
||||
<!--
|
||||
You can further control which sysctls can be set in pods by specifying lists of
|
||||
sysctls or sysctl patterns in the `forbiddenSysctls` and/or
|
||||
`allowedUnsafeSysctls` fields of the PodSecurityPolicy. A sysctl pattern ends
|
||||
with a `*` character, such as `kernel.*`. A `*` character on its own matches
|
||||
all sysctls.
|
||||
--->
|
||||
您可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls` 字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。 单独的 `*` 字符匹配所有 sysctl 参数。
|
||||
|
||||
<!--
|
||||
By default, all safe sysctls are allowed.
|
||||
--->
|
||||
所有 _安全的_ sysctl 参数都默认启用。
|
||||
|
||||
<!--
|
||||
Both `forbiddenSysctls` and `allowedUnsafeSysctls` are lists of plain sysctl names
|
||||
or sysctl patterns (which end with `*`). The string `*` matches all sysctls.
|
||||
--->
|
||||
`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。 只填写 `*` 则匹配所有的 sysctl 参数。
|
||||
|
||||
<!--
|
||||
The `forbiddenSysctls` field excludes specific sysctls. You can forbid a
|
||||
combination of safe and unsafe sysctls in the list. To forbid setting any
|
||||
sysctls, use `*` on its own.
|
||||
--->
|
||||
`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。 您可以在列表中禁用安全和非安全的 sysctl 参数的组合。 要禁用所有的 sysctl 参数，请设置为 `*`。
|
||||
|
||||
<!--
|
||||
If you specify any unsafe sysctl in the `allowedUnsafeSysctls` field and it is
|
||||
not present in the `forbiddenSysctls` field, that sysctl can be used in Pods
|
||||
using this PodSecurityPolicy. To allow all unsafe sysctls in the
|
||||
PodSecurityPolicy to be set, use `*` on its own.
|
||||
--->
|
||||
如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，并且它在`forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过 PodSecurityPolicy 启用该 sysctl 参数。 若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，请设 `allowedUnsafeSysctls` 字段值为 `*`。
|
||||
|
||||
<!--
|
||||
Do not configure these two fields such that there is overlap, meaning that a
|
||||
given sysctl is both allowed and forbidden.
|
||||
--->
|
||||
`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
|
||||
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
|
||||
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
|
||||
flag as well on that node.
|
||||
--->
|
||||
**警告**：如果您通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl 参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数 `--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl 参数的 Pod 将会启动失败。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
This example allows unsafe sysctls prefixed with `kernel.msg` to be set and
|
||||
disallows setting of the `kernel.shm_rmid_forced` sysctl.
|
||||
--->
|
||||
以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，以及禁用了 sysctl 参数 `kernel.shm_rmid_forced`。
|
||||
|
||||
```yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: sysctl-psp
|
||||
spec:
|
||||
allowedUnsafeSysctls:
|
||||
- kernel.msg*
|
||||
forbiddenSysctls:
|
||||
- kernel.shm_rmid_forced
|
||||
...
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
approvers:
|
||||
- bboreham
|
||||
title: 使用 Weave 网络来提供 NetworkPolicy
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
本页展示怎么样使用 Weave 网络来提供 NetworkPolicy
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
|
||||
完成 [kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)中的步骤1、2和3
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 安装 Weave 网络插件
|
||||
|
||||
|
||||
按照[通过插件方式集成到 Kubernetes ](https://www.weave.works/docs/net/latest/kube-addon/)指南完成安装
|
||||
|
||||
|
||||
Kubernetes 的 Weave 网络插件配有一个[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，它监控所有命名空间下 NetworkPolicy 相关的注解，然后配置 iptables 规则生成允许或者阻断通信的策略
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture example %}}
|
||||
|
||||
|
||||
## 命名空间隔离示例
|
||||
|
||||
|
||||
1. 创建携带 `DefaultDeny` 标识的命名空间
|
||||
|
||||
```yaml
|
||||
kind: Namespace
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: myns
|
||||
annotations:
|
||||
net.beta.kubernetes.io/network-policy: |
|
||||
{
|
||||
"ingress": {
|
||||
"isolation": "DefaultDeny"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
2. 在命名空间下创建2个 pod
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: pod1
|
||||
namespace: myns
|
||||
labels:
|
||||
inns: "yes"
|
||||
spec:
|
||||
containers:
|
||||
- name: pod1
|
||||
image: nginx
|
||||
---
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: pod2
|
||||
namespace: myns
|
||||
labels:
|
||||
inns: "yes"
|
||||
spec:
|
||||
containers:
|
||||
- name: pod2
|
||||
image: nginx
|
||||
```
|
||||
|
||||
|
||||
3. 获取 pod 的 IP 地址
|
||||
|
||||
```shell
|
||||
kubectl get po -n myns -o wide
|
||||
```
|
||||
|
||||
**注意：** 如果您对 pod 的 cURL 请求是被禁止的，请尝试在 pod 中访问其它的 pod
|
||||
|
||||
|
||||
4. 创建一个允许 pod 访问命名空间内其它 pod 的 Kubernetes NetworkPolicy
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: aaa
|
||||
namespace: myns
|
||||
spec:
|
||||
podSelector:
|
||||
matchExpressions:
|
||||
- {key: inns, operator: In, values: ["yes"]}
|
||||
ingress:
|
||||
- from:
|
||||
- podSelector:
|
||||
matchExpressions:
|
||||
- {key: inns, operator: In, values: ["yes"]}
|
||||
```
|
||||
|
||||
Weave 网络插件安装完成之后，您可以通过 [NetworkPolicy 入门指南](/docs/getting-started-guides/network-policy/walkthrough)去尝试使用 Kubernetes NetworkPolicy
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user