Merge branch 'master' into release-1.13
This commit is contained in:
Jim Angel
@@ -1,4 +1,3 @@
|
||||
---
|
||||
title: Home
|
||||
weight: 5
|
||||
title: 文档
|
||||
---
|
||||
|
||||
@@ -237,11 +237,12 @@ rules:
|
||||
|
||||
以下云服务供应商为自己的云部署了CCM。
|
||||
|
||||
* [Digital Ocean]()
|
||||
* [Oracle]()
|
||||
* [Azure]()
|
||||
* [GCE]()
|
||||
* [AWS]()
|
||||
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
|
||||
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
|
||||
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
|
||||
## 群集管理
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ content_template: templates/concept
|
||||
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。
|
||||
|
||||
操作 Kubernetes 对象 —— 是否创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
|
||||
操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
|
||||
，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用
|
||||
|
||||
当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
|
||||
当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。
|
||||
**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
|
||||
**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
|
||||
`kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。
|
||||
|
||||
这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约：
|
||||
@@ -95,5 +95,3 @@ deployment "nginx-deployment" created
|
||||
|
||||
* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -398,7 +398,7 @@ $ kubectl rollout undo deployment/nginx-deployment
|
||||
deployment "nginx-deployment" rolled back
|
||||
```
|
||||
|
||||
Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
|
||||
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
|
||||
|
||||
```shell
|
||||
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
|
||||
|
||||
@@ -1,33 +1,34 @@
|
||||
---
|
||||
# title: Overview of kubeadm
|
||||
title: kubeadm概述
|
||||
title: kubeadm 概述
|
||||
weight: 10
|
||||
---
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">
|
||||
<!-- Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. -->
|
||||
Kubeadm是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建kubernetes集群的最佳实践。
|
||||
Kubeadm 是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。
|
||||
|
||||
<!-- kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. -->
|
||||
kubeadm通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是之前的节点准备工作。同样的，诸如安装各种各样的可有可无的插件，例如Kubernetes 控制面板、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
|
||||
kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是之前的节点准备工作。同样的，诸如安装各种各样值得拥有的插件，例如 Kubernetes Dashboard、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
|
||||
|
||||
<!-- Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. -->
|
||||
相反，我们期望由一个基于kubeadm从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用kubeadm作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
相反，我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
|
||||
<!-- ## What's next -->
|
||||
## 接下可以做什么
|
||||
|
||||
<!-- * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node -->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个Kubernetes主节点
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个 Kubernetes 主节点
|
||||
<!-- * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster -->
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个Kubernetes工作节点并且将其加入到集群
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个 Kubernetes 工作节点并且将其加入到集群
|
||||
<!-- * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version -->
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个Kubernetes集群到新版本
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本
|
||||
<!-- * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -->
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用kubeadm v1.7.x或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果使用 v1.7.x 或者更低版本的 kubeadm 初始化集群，您需要对集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 管理 `kubeadm join` 使用的令牌
|
||||
<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -->
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 使用 `kubeadm init` 或者 `kubeadm join`来恢复对节点的改变
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原 `kubeadm init` 或者 `kubeadm join` 对主机所做的任何更改
|
||||
<!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -->
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出kubeadm版本
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印 kubeadm 版本
|
||||
<!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community -->
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈
|
||||
|
||||
@@ -78,23 +78,31 @@ If these values are not unique to each node, the installation process
|
||||
may [fail](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
-->
|
||||
一般来讲，硬件设备会拥有独一无二的地址，但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一，可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。
|
||||
|
||||
<!--
|
||||
## Check network adapters
|
||||
-->
|
||||
|
||||
## 检查网络适配器
|
||||
|
||||
<!--
|
||||
If you have more than one network adapter, and your Kubernetes components are not reachable on the default
|
||||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
-->
|
||||
|
||||
如果您有一个以上的网络适配器，同时您的 Kubernetes 组件通过默认路由不可达，我们建议您预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。
|
||||
|
||||
<!--
|
||||
## Check required ports
|
||||
-->
|
||||
|
||||
## 检查所需端口
|
||||
|
||||
<!--
|
||||
### Master node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Master 节点
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
|----------|-----------|------------|-------------------------|---------------------------|
|
||||
@@ -107,6 +115,7 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
|
||||
### Worker node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Worker 节点
|
||||
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
@@ -116,6 +125,7 @@ route, we recommend you add IP route(s) so Kubernetes cluster addresses go via t
|
||||
<!--
|
||||
** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
|
||||
** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。
|
||||
|
||||
<!--
|
||||
@@ -230,6 +240,11 @@ apt-get update
|
||||
apt-get install -y kubelet kubeadm kubectl
|
||||
apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
<!--
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
-->
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```bash
|
||||
@@ -244,9 +259,6 @@ gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cl
|
||||
exclude=kube*
|
||||
EOF
|
||||
|
||||
<!--
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
-->
|
||||
# 将 SELinux 设置为 permissive 模式(将其禁用)
|
||||
setenforce 0
|
||||
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
|
||||
|
||||
@@ -133,6 +133,8 @@ In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the
|
||||
|
||||
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
|
||||
|
||||
`grep/cut` 方法实现：
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
|
||||
$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
|
||||
@@ -151,6 +153,26 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
}
|
||||
```
|
||||
|
||||
`jsonpath` 方法实现：
|
||||
|
||||
```shell
|
||||
$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
|
||||
$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
|
||||
$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
||||
{
|
||||
"kind": "APIVersions",
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
The above examples use the `--insecure` flag. This leaves it subject to MITM
|
||||
attacks. When kubectl accesses the cluster it uses a stored root certificate
|
||||
|
||||
+105
-69
@@ -1,33 +1,52 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
title: 配置你的云平台防火墙
|
||||
content_template: templates/task
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
许多云服务商（比如 Google Compute Engine）定义防火墙以防止服务无意间暴露到 internet 上。
|
||||
<!--
|
||||
Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
|
||||
exposure to the internet. When exposing a service to the external world, you may need to open up
|
||||
one or more ports in these firewalls to serve traffic. This document describes this process, as
|
||||
well as any provider specific details that may be necessary.
|
||||
-->
|
||||
许多云服务提供商（比如 谷歌计算引擎）定义防火墙以防止服务无意间暴露到互联网上。
|
||||
当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。
|
||||
本文描述了这个过程，以及其他云服务商的具体信息。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
<!--
|
||||
## Restrict Access For LoadBalancer Service
|
||||
-->
|
||||
## 负载均衡（LoadBalancer）服务的访问限制
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。
|
||||
这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Kubernetes Engine 和 AWS。
|
||||
如果云服务商不支持这个功能，这个字段会被忽略。
|
||||
<!--
|
||||
When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer
|
||||
by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions.
|
||||
This feature is currently supported on Google Compute Engine, Google Kubernetes Engine, AWS Elastic Kubernetes Service, and Azure Kubernetes Service. This field will be ignored if the cloud provider does not support the feature.
|
||||
-->
|
||||
当以 `spec.type: LoadBalancer` 方式配置服务时，你可以使用 `spec.loadBalancerSourceRanges` 来指定允许访问负载均衡器的 ip 段。
|
||||
这个字段采用 CIDR 的 IP 段， kubernetes 使用该段配置防火墙。目前只有 谷歌计算引擎，谷歌云原生引擎，亚马逊弹性原生云服务 和 微软云原生平台支持此功能。
|
||||
如果云服务提供商不支持这个功能，这个字段将被忽略。
|
||||
|
||||
|
||||
|
||||
假设 10.0.0.0/8 是内部的子网。在下面这个例子中，会创建一个只有集群内部 ip 可以访问的负载均衡器。
|
||||
集群外部的客户端是无法访问这个负载均衡器的。
|
||||
<!--
|
||||
Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs.
|
||||
This will not allow clients from outside of your Kubernetes cluster to access the load balancer.
|
||||
-->
|
||||
假设内部子网为假设10.0.0.0/8，在下面这个例子中，将创建一个仅能由群集内部IP访问的负载均衡器。此负载均衡器不允许来自 kubernetes 集群外部客户端的访问。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -36,17 +55,18 @@ metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
loadBalancerSourceRanges:
|
||||
- 10.0.0.0/8
|
||||
```
|
||||
|
||||
|
||||
这个例子中，会创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
|
||||
<!--
|
||||
In the following example, a load balancer will be created that is only accessible to clients with IP addresses from 130.211.204.1 and 130.211.204.2.
|
||||
-->
|
||||
在下面这个例子中，将创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -55,8 +75,8 @@ metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
@@ -64,63 +84,79 @@ spec:
|
||||
- 130.211.204.1/32
|
||||
- 130.211.204.2/32
|
||||
```
|
||||
<!--
|
||||
## Google Compute Engine
|
||||
-->
|
||||
## 谷歌计算引擎 （Google Compute Engine）
|
||||
|
||||
<!--
|
||||
When using a Service with `spec.type: LoadBalancer`, the firewall will be
|
||||
opened automatically. When using `spec.type: NodePort`, however, the firewall
|
||||
is *not* opened by default.
|
||||
-->
|
||||
当以 `spec.type: LoadBalancer` 方式配置服务时，该服务的防火墙将自动打开。
|
||||
当以 `spec.type: NodePort` 方式配置服务时，该服务的防火墙在默认情况下不会打开。
|
||||
|
||||
### 谷歌计算引擎（Google Compute Engine）
|
||||
<!--
|
||||
Google Compute Engine firewalls are documented [elsewhere](https://cloud.google.com/compute/docs/networking#firewalls_1).
|
||||
-->
|
||||
谷歌计算引擎的防火墙会进行记录 [他处] (https://cloud.google.com/compute/docs/networking#firewalls_1)。
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，防火墙会被自动打开。
|
||||
然而，当以 `spec.type: NodePort` 使用服务时，防火墙默认 *不会* 被打开。
|
||||
|
||||
|
||||
Google Compute Engine 的防火墙文档在[别处](https://cloud.google.com/compute/docs/networking#firewalls_1)。
|
||||
|
||||
|
||||
你可以使用 `gcloud` 命令行工具添加一个防火墙：
|
||||
<!--
|
||||
You can add a firewall with the `gcloud` command line tool:
|
||||
-->
|
||||
你也可以使用 gcloud 命令行工具自行添加防火墙：
|
||||
|
||||
```shell
|
||||
$ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
```
|
||||
|
||||
|
||||
|
||||
**注意**
|
||||
使用 Google Compute Engine 平台的防火墙时有一个重要的关于安全的注意点：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在 Kubernetes v1.0.0 版本，GCE 防火墙是定义按虚拟机（VM）来的，而不是按 ip 来的。
|
||||
{{< note >}}
|
||||
<!--
|
||||
GCE firewalls are defined per-vm, rather than per-ip address. This means that
|
||||
when you open a firewall for a service's ports, anything that serves on that
|
||||
port on that VM's host IP address may potentially serve traffic. Note that this
|
||||
is not a problem for other Kubernetes services, as they listen on IP addresses
|
||||
that are different than the host node's external IP address.
|
||||
-->
|
||||
GCE 防火墙是按照虚拟机来定义的，而不是通过ip地址来定义的。
|
||||
这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务
|
||||
都有被外部访问的潜在可能。注意，这对于其他 Kubernetes 服务来说不是问题，因为他们监
|
||||
听的 IP 地址与主机节点的外部 IP 地址不同。
|
||||
都有被外部访问的潜在可能。需要注意的是，对于其他的 kubernetes 服务而言，这不是问题。
|
||||
因为他们监听的ip 地址与主机节点外部的 ip 地址并不相同。
|
||||
|
||||
<!--
|
||||
Consider:
|
||||
-->
|
||||
试想一下：
|
||||
|
||||
考虑一下:
|
||||
<!--
|
||||
* You create a Service with an external load balancer (IP Address 1.2.3.4)
|
||||
and port 80
|
||||
-->
|
||||
* 你建立一个（ ip 地址为1.2.3.4）端口为80的外部负载均衡器
|
||||
|
||||
* 你创建了一个服务，使用了外部服务均衡 (IP 地址为 1.2.3.4) 和 80 端口。
|
||||
* 你在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
|
||||
<!--
|
||||
* You open the firewall for port 80 for all nodes in your cluster, so that
|
||||
the external Service actually can deliver packets to your Service
|
||||
-->
|
||||
* 因为在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
|
||||
服务发送数据包。
|
||||
* 你又在虚拟机（IP 为2.3.4.5）上使用 80 端口启动了一台 nginx 服务器.
|
||||
这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了 internet 上。
|
||||
|
||||
<!--
|
||||
* You start an nginx server, running on port 80 on the host virtual machine
|
||||
(IP Address 2.3.4.5). This nginx is also exposed to the internet on
|
||||
the VM's external IP address.
|
||||
-->
|
||||
* 最后你又虚拟机上的80端口启动 nginx 服务器（ip地址2.3.4.5）。
|
||||
这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了互联网上。
|
||||
|
||||
<!--
|
||||
Consequently, please be careful when opening firewalls in Google Compute Engine
|
||||
or Google Kubernetes Engine. You may accidentally be exposing other services to
|
||||
the wilds of the internet.
|
||||
-->
|
||||
因此请务必小心，在谷歌计算引擎或者谷歌云原生引擎中打开防火墙时，可能无意间把其他服务也暴露给了互联网。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
因此，在 Google Compute Engine 或者 Google Kubernetes Engine 上开启防火墙端口时请
|
||||
小心。你可能无意间把其他服务也暴露给了 internet。
|
||||
|
||||
|
||||
这个问题会在 Kubernetes 后续版本中被修复。
|
||||
|
||||
|
||||
### 其他云服务商
|
||||
|
||||
|
||||
即将更新
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -44,13 +44,17 @@ content_template: templates/task
|
||||
|
||||
2. 选择你的 PersistentVolumes 中的一个并更改它的回收策略：
|
||||
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
|
||||
```shell
|
||||
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
这里的 `<your-pv-name>` 是你选择的 PersistentVolume 的名字。
|
||||
|
||||
3. 验证你选择的 PersistentVolume 拥有正确的策略：
|
||||
|
||||
kubectl get pv
|
||||
```shell
|
||||
kubectl get pv
|
||||
```
|
||||
|
||||
输出类似于这样：
|
||||
|
||||
|
||||
@@ -40,9 +40,9 @@ metadata:
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“acme.local”: [“1.2.3.4”]}
|
||||
{"acme.local": ["1.2.3.4"]}
|
||||
upstreamNameservers: |
|
||||
[“8.8.8.8”, “8.8.4.4”]
|
||||
["8.8.8.8", "8.8.4.4"]
|
||||
```
|
||||
|
||||
|
||||
@@ -130,17 +130,15 @@ apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{“consul.local”: [“10.150.0.1”]}
|
||||
namespace: kube-system
|
||||
data:
|
||||
stubDomains: |
|
||||
{"consul.local": ["10.150.0.1"]}
|
||||
```
|
||||
|
||||
|
||||
注意，集群管理员不希望覆盖节点的上游域名服务器，所以他们不会指定可选的 `upstreamNameservers` 字段。
|
||||
|
||||
|
||||
|
||||
### 示例：上游域名服务器
|
||||
|
||||
在这个示例中，集群管理员不希望显式地强制所有非集群 DNS 查询进入到他们自己的域名服务器 172.16.0.1。
|
||||
@@ -151,10 +149,10 @@ apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
[“172.16.0.1”]
|
||||
namespace: kube-system
|
||||
data:
|
||||
upstreamNameservers: |
|
||||
["172.16.0.1"]
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
+27
-11
@@ -34,34 +34,48 @@ content_template: templates/task
|
||||
{{< code file="commands.yaml" >}}
|
||||
|
||||
1. 基于YAML文件创建一个Pod：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
2. List the running Pods:
|
||||
-->
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息：
|
||||
|
||||
kubectl get pods
|
||||
获取正在运行的 pod
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
查询结果显示在command-demo这个Pod下运行的容器已经启动完成
|
||||
|
||||
1. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
|
||||
3. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
|
||||
|
||||
kubectl logs command-demo
|
||||
```shell
|
||||
kubectl logs command-demo
|
||||
```
|
||||
|
||||
日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值：
|
||||
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
|
||||
|
||||
```shell
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
```
|
||||
|
||||
## 使用环境变量来设置入参
|
||||
|
||||
在上面的示例中，我们直接将一串字符作为命令的入参。除此之外，我们还可以
|
||||
将环境变量作为命令的入参。
|
||||
|
||||
```shell
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "hello world"
|
||||
command: ["/bin/echo"]
|
||||
args: ["$(MESSAGE)"]
|
||||
```
|
||||
|
||||
这样一来，我们就可以将那些用来设置环境变量的方法应用于设置命令的入参，其
|
||||
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
@@ -78,8 +92,10 @@ content_template: templates/task
|
||||
有时候，需要通过shell来执行命令。 例如，命令可能由多个命令组合而成，抑或包含
|
||||
在一个shell脚本中。这时，就可以通过如下方式在shell中执行命令：
|
||||
|
||||
```shell
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
```
|
||||
|
||||
## 注意
|
||||
|
||||
|
||||
+23
-11
@@ -30,32 +30,44 @@ content_template: templates/task
|
||||
|
||||
1. 基于YAML文件创建一个Pod:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/envars.yaml
|
||||
```
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息:
|
||||
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
```shell
|
||||
kubectl get pods -l purpose=demonstrate-envars
|
||||
```
|
||||
|
||||
查询结果应为:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
```log
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
envar-demo 1/1 Running 0 9s
|
||||
```
|
||||
|
||||
1. 进入该Pod下的容器并打开一个命令终端:
|
||||
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```shell
|
||||
kubectl exec -it envar-demo -- /bin/bash
|
||||
```
|
||||
|
||||
1. 在命令终端中通过执行`printenv`打印出环境变量。
|
||||
|
||||
root@envar-demo:/# printenv
|
||||
```shell
|
||||
root@envar-demo:/# printenv
|
||||
```
|
||||
|
||||
打印结果应为:
|
||||
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
```log
|
||||
NODE_VERSION=4.4.2
|
||||
EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237
|
||||
HOSTNAME=envar-demo
|
||||
...
|
||||
DEMO_GREETING=Hello from the environment
|
||||
```
|
||||
|
||||
1. 通过键入`exit`退出命令终端。
|
||||
|
||||
|
||||
@@ -20,8 +20,10 @@ content_template: templates/task
|
||||
假设用户想要有两条 secret 数据：用户名 `my-app` 和密码
|
||||
`39528$vdg7Jb`。 首先使用 [Base64 编码](https://www.base64encode.org/) 将用户名和密码转化为 base-64 形式。 这里是一个 Linux 示例：
|
||||
|
||||
```shell
|
||||
echo -n 'my-app' | base64
|
||||
echo -n '39528$vdg7Jb' | base64
|
||||
```
|
||||
|
||||
结果显示 base-64 形式的用户名为 `bXktYXBw`，
|
||||
base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
@@ -30,26 +32,32 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
|
||||
这里是一个配置文件，可以用来创建存有用户名和密码的 Secret:
|
||||
|
||||
{{< code file="secret.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret.yaml" >}}
|
||||
|
||||
1. 创建 Secret
|
||||
|
||||
kubectl create -f secret.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**注意：** 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
|
||||
{{< /note >}}
|
||||
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```shell
|
||||
kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
|
||||
```
|
||||
|
||||
1. 查看 Secret 相关信息：
|
||||
|
||||
kubectl get secret test-secret
|
||||
|
||||
输出：
|
||||
|
||||
NAME TYPE DATA AGE
|
||||
test-secret Opaque 2 1m
|
||||
|
||||
```shell
|
||||
NAME TYPE DATA AGE
|
||||
test-secret Opaque 2 1m
|
||||
```
|
||||
|
||||
1. 查看 Secret 相关的更多详细信息：
|
||||
|
||||
@@ -57,97 +65,127 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
|
||||
输出：
|
||||
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
```shell
|
||||
Name: test-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
Data
|
||||
====
|
||||
password: 13 bytes
|
||||
username: 7 bytes
|
||||
```
|
||||
|
||||
## 创建可以通过卷访问 secret 数据的 Pod
|
||||
|
||||
这里是一个可以用来创建 pod 的配置文件：
|
||||
|
||||
{{< code file="secret-pod.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret-pod.yaml" >}}
|
||||
|
||||
1. 创建 Pod：
|
||||
|
||||
kubectl create -f secret-pod.yaml
|
||||
```shell
|
||||
kubectl create -f secret-pod.yaml
|
||||
```
|
||||
|
||||
1. 确认 Pod 正在运行：
|
||||
|
||||
kubectl get pod secret-test-pod
|
||||
|
||||
```shell
|
||||
kubectl get pod secret-test-pod
|
||||
```
|
||||
|
||||
输出：
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-test-pod 1/1 Running 0 42m
|
||||
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-test-pod 1/1 Running 0 42m
|
||||
```
|
||||
|
||||
1. 在 Pod 中运行的容器中获取一个 shell：
|
||||
|
||||
kubectl exec -it secret-test-pod -- /bin/bash
|
||||
|
||||
```shell
|
||||
kubectl exec -it secret-test-pod -- /bin/bash
|
||||
```
|
||||
|
||||
1. secret 数据通过挂载在 `/etc/secret-volume` 目录下的卷暴露在容器中。
|
||||
在 shell 中，进入 secret 数据被暴露的目录：
|
||||
|
||||
root@secret-test-pod:/# cd /etc/secret-volume
|
||||
|
||||
```shell
|
||||
root@secret-test-pod:/# cd /etc/secret-volume
|
||||
```
|
||||
1. 在 shell 中，列出 `/etc/secret-volume` 目录的文件：
|
||||
|
||||
root@secret-test-pod:/etc/secret-volume# ls
|
||||
|
||||
```shell
|
||||
root@secret-test-pod:/etc/secret-volume# ls
|
||||
```
|
||||
|
||||
输出显示了两个文件，每个对应一条 secret 数据：
|
||||
|
||||
password username
|
||||
```shell
|
||||
password username
|
||||
```
|
||||
|
||||
1. 在 shell 中，显示 `username` 和 `password` 文件的内容：
|
||||
|
||||
root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
|
||||
```shell
|
||||
root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
|
||||
```
|
||||
|
||||
输出为用户名和密码：
|
||||
|
||||
my-app
|
||||
39528$vdg7Jb
|
||||
```shell
|
||||
my-app
|
||||
39528$vdg7Jb
|
||||
```
|
||||
|
||||
## 创建通过环境变量访问 secret 数据的 Pod
|
||||
|
||||
这里是一个可以用来创建 pod 的配置文件：
|
||||
|
||||
{{< code file="secret-envars-pod.yaml" >}}
|
||||
{{< codenew file="pods/inject/secret-envars-pod.yaml" >}}
|
||||
|
||||
1. 创建 Pod：
|
||||
|
||||
kubectl create -f secret-envars-pod.yaml
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
|
||||
```
|
||||
|
||||
1. 确认 Pod 正在运行：
|
||||
|
||||
kubectl get pod secret-envars-test-pod
|
||||
|
||||
```shell
|
||||
kubectl get pod secret-envars-test-pod
|
||||
```
|
||||
|
||||
输出：
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-envars-test-pod 1/1 Running 0 4m
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
secret-envars-test-pod 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
1. 在 Pod 中运行的容器中获取一个 shell：
|
||||
|
||||
kubectl exec -it secret-envars-test-pod -- /bin/bash
|
||||
|
||||
```shell
|
||||
kubectl exec -it secret-envars-test-pod -- /bin/bash
|
||||
```
|
||||
|
||||
1. 在 shell 中，显示环境变量：
|
||||
|
||||
root@secret-envars-test-pod:/# printenv
|
||||
|
||||
```shell
|
||||
root@secret-envars-test-pod:/# printenv
|
||||
```
|
||||
|
||||
输出包括用户名和密码：
|
||||
|
||||
...
|
||||
SECRET_USERNAME=my-app
|
||||
...
|
||||
SECRET_PASSWORD=39528$vdg7Jb
|
||||
```shell
|
||||
...
|
||||
SECRET_USERNAME=my-app
|
||||
...
|
||||
SECRET_PASSWORD=39528$vdg7Jb
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -163,5 +201,3 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
|
||||
* [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
+5
-2
@@ -43,7 +43,7 @@ content_template: templates/task
|
||||
**注意:** 本示例中的字段是Pod字段，不是Pod中容器的字段。
|
||||
{{< /note >}}
|
||||
|
||||
创建Pod：
|
||||
创建 Pod：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/cn/docs/tasks/inject-data-application/dapi-volume.yaml
|
||||
@@ -61,7 +61,10 @@ kubectl get pods
|
||||
kubectl logs kubernetes-downwardapi-volume-example
|
||||
```
|
||||
|
||||
输出显示`labels`和`annotations`文件的内容：
|
||||
<!--
|
||||
The output shows the contents of the labels file and the annotations file:
|
||||
-->
|
||||
输出显示 `labels` 和 `annotations` 文件的内容：
|
||||
|
||||
```shell
|
||||
cluster="test-cluster1"
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: secret-envars-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: envars-test-container
|
||||
image: nginx
|
||||
env:
|
||||
- name: SECRET_USERNAME
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: test-secret
|
||||
key: username
|
||||
- name: SECRET_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: test-secret
|
||||
key: password
|
||||
@@ -1,17 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: secret-test-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
# name must match the volume name below
|
||||
- name: secret-volume
|
||||
mountPath: /etc/secret-volume
|
||||
# The secret data is exposed to Containers in the Pod through a Volume.
|
||||
volumes:
|
||||
- name: secret-volume
|
||||
secret:
|
||||
secretName: test-secret
|
||||
@@ -1,7 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: test-secret
|
||||
data:
|
||||
username: bXktYXBwCg==
|
||||
password: Mzk1MjgkdmRnN0piCg==
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 概述
|
||||
linkTitle: Try Our Interactive Tutorials
|
||||
title: 学习 Kubernetes 基础知识
|
||||
linkTitle: 学习 Kubernetes 基础知识
|
||||
---
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
@@ -147,7 +147,7 @@ MySQL 和 WordPress pod 配置引用了这个 secret，所以这些 pods 就可
|
||||
|
||||
## 部署 MySQL
|
||||
|
||||
<--
|
||||
<!--
|
||||
Now that the persistent disks and secrets are defined, the Kubernetes
|
||||
pods can be launched. Start MySQL using
|
||||
[mysql-deployment.yaml](https://git.k8s.io/examples/mysql-wordpress-pd/mysql-deployment.yaml).
|
||||
|
||||
@@ -12,7 +12,7 @@ title: Docker 用户使用 kubectl 命令指南
|
||||
|
||||
#### docker run
|
||||
|
||||
如何运行一个 nginx Deployment 并将其暴露出来？ 查看 [kubectl run](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 。
|
||||
如何运行一个 nginx Deployment 并将其暴露出来？ 查看 [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run) 。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -26,22 +26,30 @@ a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago
|
||||
|
||||
使用 kubectl 命令：
|
||||
|
||||
```shell
|
||||
<!--
|
||||
# start the pod running nginx
|
||||
-->
|
||||
|
||||
```shell
|
||||
# 启动运行 nginx 的 pod
|
||||
$ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
|
||||
deployment "nginx-app" created
|
||||
```
|
||||
|
||||
在 1.2 及以上版本的 Kubernetes 集群中，使用`kubectl run` 命令将创建一个名为 "nginx-app" 的 Deployment。如果您运行的是老版本，将会创建一个 replication controller。
|
||||
如果您想沿用旧的行为，使用 `--generation=run/v1` 参数，这样就会创建 replication controller。查看 [`kubectl run`](/docs/user-guide/kubectl/{{< param "version" >}}/#run) 获取更多详细信息。
|
||||
如果您想沿用旧的行为，使用 `--generation=run/v1` 参数，这样就会创建 replication controller。查看 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 获取更多详细信息。
|
||||
|
||||
<!--
|
||||
# expose a port through with a service
|
||||
-->
|
||||
|
||||
```shell
|
||||
# expose a port through with a service
|
||||
# 通过服务暴露端口
|
||||
$ kubectl expose deployment nginx-app --port=80 --name=nginx-http
|
||||
service "nginx-http" exposed
|
||||
```
|
||||
|
||||
在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod（N 代表 spec 中声明的 replica 数，默认为 1）。我们还创建了一个 [service](/docs/user-guide/services)，使用 selector 匹配具有相应的 selector 的 Deployment。查看 [快速开始](/docs/user-guide/quick-start) 获取更多信息。
|
||||
在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod（N 代表 spec 中声明的 replica 数，默认为 1）。我们还创建了一个 [service](/docs/user-guide/services)，使用 selector 匹配具有相应的 selector 的 Deployment。查看[快速开始](/docs/user-guide/quick-start)获取更多信息。
|
||||
|
||||
默认情况下镜像会在后台运行，与`docker run -d ...` 类似，如果您想在前台运行，使用：
|
||||
|
||||
@@ -56,7 +64,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
|
||||
#### docker ps
|
||||
|
||||
如何列出哪些正在运行？查看 [kubectl get](/docs/user-guide/kubectl/{{< param "version" >}}/#get)。
|
||||
如何列出哪些正在运行？查看 [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -76,7 +84,7 @@ nginx-app-5jyvm 1/1 Running 0 1h
|
||||
|
||||
#### docker attach
|
||||
|
||||
如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/user-guide/kubectl/{{< param "version" >}}/#attach)。
|
||||
如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -100,7 +108,7 @@ $ kubectl attach -it nginx-app-5jyvm
|
||||
|
||||
#### docker exec
|
||||
|
||||
如何在容器中执行命令？查看 [kubectl exec](/docs/user-guide/kubectl/{{< param "version" >}}/#exec)。
|
||||
如何在容器中执行命令？查看 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -138,11 +146,11 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
|
||||
# exit
|
||||
```
|
||||
|
||||
更多信息请查看 [获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。
|
||||
更多信息请查看[获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。
|
||||
|
||||
#### docker logs
|
||||
|
||||
如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/user-guide/kubectl/{{< param "version" >}}/#logs)。
|
||||
如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -168,11 +176,12 @@ $ kubectl logs --previous nginx-app-zibvs
|
||||
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
|
||||
```
|
||||
|
||||
查看 [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 获取更多信息。
|
||||
查看[记录和监控集群活动](/docs/concepts/cluster-administration/logging/)获取更多信息。
|
||||
|
||||
#### docker stop 和 docker rm
|
||||
|
||||
如何停止和删除运行中的进程？查看 [kubectl delete](/docs/user-guide/kubectl/{{< param "version" >}}/#delete)。
|
||||
|
||||
如何停止和删除运行中的进程？查看 [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -201,15 +210,15 @@ $ kubectl get po -l run=nginx-app
|
||||
# Return nothing
|
||||
```
|
||||
|
||||
请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除pod，Deployment 将会重新创建该 pod。
|
||||
请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除 pod，Deployment 将会重新创建该 pod。
|
||||
|
||||
#### docker login
|
||||
|
||||
在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅 [使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。
|
||||
在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅[使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。
|
||||
|
||||
#### docker version
|
||||
|
||||
如何查看客户端和服务端的版本？查看 [kubectl version](/docs/user-guide/kubectl/{{< param "version" >}}/#version)。
|
||||
如何查看客户端和服务端的版本？查看 [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
@@ -237,7 +246,7 @@ Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4
|
||||
|
||||
#### docker info
|
||||
|
||||
如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/user-guide/kubectl/{{< param "version" >}}/#cluster-info)。
|
||||
如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info)。
|
||||
|
||||
使用 docker 命令：
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ kubectl [command] [TYPE] [NAME] [flags]
|
||||
* 要分别指定多种资源类型: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
|
||||
例: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-config-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
|
||||
使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-configuration-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
|
||||
例：$ kubectl get pod -f ./pod.yaml
|
||||
|
||||
* flags：指定可选标志。例如，您可以使用`-s`或`--serverflags`来指定Kubernetes API服务器的地址和端口。
|
||||
|
||||
Reference in New Issue
Block a user