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,573 @@
|
||||
<!--
|
||||
---
|
||||
title: Accessing Clusters
|
||||
weight: 20
|
||||
content_template: templates/concept
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 访问集群
|
||||
weight: 20
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This topic discusses multiple ways to interact with clusters.
|
||||
-->
|
||||
本文阐述多种与集群交互的方法。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Accessing for the first time with kubectl
|
||||
|
||||
When accessing the Kubernetes API for the first time, we suggest using the
|
||||
Kubernetes CLI, `kubectl`.
|
||||
|
||||
To access a cluster, you need to know the location of the cluster and have credentials
|
||||
to access it. Typically, this is automatically set-up when you work through
|
||||
a [Getting started guide](/docs/setup/),
|
||||
or someone else setup the cluster and provided you with credentials and a location.
|
||||
|
||||
Check the location and credentials that kubectl knows about with this command:
|
||||
-->
|
||||
## 使用 kubectl 完成集群的第一次访问
|
||||
|
||||
当您第一次访问 Kubernetes API 的时候，我们建议您使用 Kubernetes CLI，`kubectl`。
|
||||
|
||||
访问集群时，您需要知道集群的地址并且拥有访问的凭证。通常，这些在您通过 [Getting started guide](/docs/setup/) 安装集群时都是自动安装好的，或者其他人安装时也应该提供了凭证和集群地址。
|
||||
|
||||
通过以下命令检查 kubectl 是否知道集群地址及凭证：
|
||||
|
||||
```shell
|
||||
$ kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
|
||||
kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl-overview).
|
||||
|
||||
## Directly accessing the REST API
|
||||
|
||||
Kubectl handles locating and authenticating to the apiserver.
|
||||
If you want to directly access the REST API with an http client like
|
||||
curl or wget, or a browser, there are several ways to locate and authenticate:
|
||||
|
||||
- Run kubectl in proxy mode.
|
||||
- Recommended approach.
|
||||
- Uses stored apiserver location.
|
||||
- Verifies identity of apiserver using self-signed cert. No MITM possible.
|
||||
- Authenticates to apiserver.
|
||||
- In future, may do intelligent client-side load-balancing and failover.
|
||||
- Provide the location and credentials directly to the http client.
|
||||
- Alternate approach.
|
||||
- Works with some types of client code that are confused by using a proxy.
|
||||
- Need to import a root cert into your browser to protect against MITM.
|
||||
-->
|
||||
有许多 [例子](/docs/user-guide/kubectl-cheatsheet) 介绍了如何使用 kubectl，可以在 [kubectl手册](/docs/user-guide/kubectl-overview) 中找到更完整的文档。
|
||||
|
||||
## 直接访问 REST API
|
||||
Kubectl 处理 apiserver 的定位和身份验证。
|
||||
如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过多种方式查找和验证：
|
||||
|
||||
|
||||
- 以代理模式运行 kubectl。
|
||||
- 推荐此方式。
|
||||
- 使用已存储的 apiserver 地址。
|
||||
- 使用自签名的证书来验证 apiserver 的身份。杜绝 MITM 攻击。
|
||||
- 对 apiserver 进行身份验证。
|
||||
- 未来可能会实现智能化的客户端负载均衡和故障恢复。
|
||||
- 直接向 http 客户端提供位置和凭据。
|
||||
- 可选的方案。
|
||||
- 适用于代理可能引起混淆的某些客户端类型。
|
||||
- 需要引入根证书到您的浏览器以防止 MITM 攻击。
|
||||
|
||||
<!--
|
||||
### Using kubectl proxy
|
||||
|
||||
The following command runs kubectl in a mode where it acts as a reverse proxy. It handles
|
||||
locating the apiserver and authenticating.
|
||||
Run it like this:
|
||||
-->
|
||||
### 使用 kubectl 代理
|
||||
|
||||
以下命令以反向代理的模式运行kubectl。它处理 apiserver 的定位和验证。
|
||||
像这样运行：
|
||||
|
||||
```shell
|
||||
$ kubectl proxy --port=8080 &
|
||||
```
|
||||
|
||||
<!--
|
||||
See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details.
|
||||
|
||||
Then you can explore the API with curl, wget, or a browser, replacing localhost
|
||||
with [::1] for IPv6, like so:
|
||||
-->
|
||||
参阅 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多详细信息。
|
||||
|
||||
然后，您可以使用 curl、wget 或浏览器访问 API，如果是 IPv6 则用 [::1] 替换 localhost，如下所示：
|
||||
|
||||
```shell
|
||||
$ curl http://localhost:8080/api/
|
||||
{
|
||||
"versions": [
|
||||
"v1"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
### Without kubectl proxy
|
||||
|
||||
In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
|
||||
-->
|
||||
### 不使用 kubectl 代理
|
||||
|
||||
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。使用 `kubectl describe secret ...` 来获取默认服务帐户的 token，如下所示：
|
||||
|
||||
```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')
|
||||
$ 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
|
||||
and client certificates to access the server. (These are installed in the
|
||||
`~/.kube` directory). Since cluster certificates are typically self-signed, it
|
||||
may take special configuration to get your http client to use root
|
||||
certificate.
|
||||
|
||||
On some clusters, the apiserver does not require authentication; it may serve
|
||||
on localhost, or be protected by a firewall. There is not a standard
|
||||
for this. [Configuring Access to the API](/docs/admin/accessing-the-api)
|
||||
describes how a cluster admin can configure this. Such approaches may conflict
|
||||
with future high-availability support.
|
||||
-->
|
||||
上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器（这些安装在 `~/.kube` 目录中）。由于集群证书通常是自签名的，因此可能需要特殊配置才能让您的 http 客户端使用根证书。
|
||||
|
||||
在一些集群中，apiserver 不需要身份验证；它可能只服务于 localhost，或者被防火墙保护，这个没有一定的标准。 [配置对 API 的访问](/docs/admin/accessing-the-api) 描述了集群管理员如何进行配置。此类方法可能与未来的高可用性支持相冲突。
|
||||
|
||||
<!--
|
||||
## Programmatic access to the API
|
||||
|
||||
Kubernetes officially supports [Go](#go-client) and [Python](#python-client)
|
||||
client libraries.
|
||||
|
||||
### Go client
|
||||
|
||||
* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
|
||||
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
|
||||
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
|
||||
|
||||
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
|
||||
-->
|
||||
## 以编程方式访问 API
|
||||
|
||||
Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客户端库支持。
|
||||
|
||||
### Go 客户端
|
||||
|
||||
* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 来查看目前支持哪些版本。
|
||||
* 基于这个 client-go 客户端库编写应用程序。 请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
|
||||
|
||||
Go 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver。可参阅 [示例](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)。
|
||||
|
||||
如果应用程序以 Pod 的形式部署在集群中，那么请参阅 [下一章](#accessing-the-api-from-a-pod)。
|
||||
|
||||
<!--
|
||||
### Python client
|
||||
|
||||
To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
|
||||
|
||||
The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples/example1.py).
|
||||
|
||||
### Other languages
|
||||
|
||||
There are [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages.
|
||||
See documentation for other libraries for how they authenticate.
|
||||
-->
|
||||
### Python 客户端
|
||||
|
||||
如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，请运行命令：`pip install kubernetes`。参阅 [Python Client Library page](https://github.com/kubernetes-client/python) 以获得更详细的安装参数。
|
||||
|
||||
Python 客户端可以像 kubectl CLI 一样使用相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 来定位和验证 apiserver，可参阅 [示例](https://github.com/kubernetes-client/python/tree/master/examples/example1.py)。
|
||||
|
||||
### 其它语言
|
||||
|
||||
目前有多个 [客户端库](/docs/reference/using-api/client-libraries/) 为其它语言提供访问 API 的方法。
|
||||
参阅其它库的相关文档以获取他们是如何验证的。
|
||||
|
||||
<!--
|
||||
## Accessing the API from a Pod
|
||||
|
||||
When accessing the API from a pod, locating and authenticating
|
||||
to the apiserver are somewhat different.
|
||||
|
||||
The recommended way to locate the apiserver within the pod is with
|
||||
the `kubernetes.default.svc` DNS name, which resolves to a Service IP which in turn
|
||||
will be routed to an apiserver.
|
||||
|
||||
The recommended way to authenticate to the apiserver is with a
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
|
||||
is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
-->
|
||||
### 从 Pod 中访问 API
|
||||
|
||||
当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
|
||||
|
||||
在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc` 这个 DNS 名称，该名称将会解析为服务 IP，然后服务 IP 将会路由到 apiserver。
|
||||
|
||||
向 apiserver 进行身份验证的推荐方法是使用 [服务帐户](/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
|
||||
通过 kube-system，pod 与服务帐户相关联，并且该服务帐户的凭证（token）被放置在该 pod 中每个容器的文件系统中，位于 `/var/run/secrets/kubernetes.io/serviceaccount/token`。
|
||||
|
||||
<!--
|
||||
If available, a certificate bundle is placed into the filesystem tree of each
|
||||
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
|
||||
used to verify the serving certificate of the apiserver.
|
||||
|
||||
Finally, the default namespace to be used for namespaced API operations is placed in a file
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
|
||||
|
||||
From within a pod the recommended ways to connect to API are:
|
||||
|
||||
- run `kubectl proxy` in a sidecar container in the pod, or as a background
|
||||
process within the container. This proxies the
|
||||
Kubernetes API to the localhost interface of the pod, so that other processes
|
||||
in any container of the pod can access it.
|
||||
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
|
||||
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
|
||||
|
||||
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
||||
-->
|
||||
如果可用，则将证书放入每个容器的文件系统中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`，并且应该用于验证 apiserver 的服务证书。
|
||||
|
||||
最后，命名空间化的 API 操作所使用的默认命名空间将被放置在每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
|
||||
|
||||
在 pod 中，建议连接 API 的方法是：
|
||||
|
||||
- 在 pod 的 sidecar 容器中运行 `kubectl proxy`，或者以后台进程的形式运行。
|
||||
这将把 Kubernetes API 代理到当前 pod 的 localhost interface，所以 pod 中的所有容器中的进程都能访问它。
|
||||
- 使用 Go 客户端库，并使用 `rest.InClusterConfig()` 和 `kubernetes.NewForConfig()` 函数创建一个客户端。
|
||||
他们处理 apiserver 的定位和身份验证。[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
|
||||
|
||||
在每种情况下，pod 的凭证都是为了与 apiserver 安全地通信。
|
||||
|
||||
<!--
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In Kubernetes, the
|
||||
[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
-->
|
||||
## 访问集群中正在运行的服务
|
||||
|
||||
上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
|
||||
在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。
|
||||
在许多情况下，集群上的节点 IP，pod IP 和某些服务 IP 将无法路由，因此无法从集群外部的计算机（例如桌面计算机）访问它们。
|
||||
|
||||
<!--
|
||||
### Ways to connect
|
||||
|
||||
You have several options for connecting to nodes, pods and services from outside the cluster:
|
||||
|
||||
- Access services through public IPs.
|
||||
- Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
|
||||
the cluster. See the [services](/docs/user-guide/services) and
|
||||
[kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) documentation.
|
||||
- Depending on your cluster environment, this may just expose the service to your corporate network,
|
||||
or it may expose it to the internet. Think about whether the service being exposed is secure.
|
||||
Does it do its own authentication?
|
||||
- Place pods behind services. To access one specific pod from a set of replicas, such as for debugging,
|
||||
place a unique label on the pod and create a new service which selects this label.
|
||||
- In most cases, it should not be necessary for application developer to directly access
|
||||
nodes via their nodeIPs.
|
||||
- Access services, nodes, or pods using the Proxy Verb.
|
||||
- Does apiserver authentication and authorization prior to accessing the remote service.
|
||||
Use this if the services are not secure enough to expose to the internet, or to gain
|
||||
access to ports on the node IP, or for debugging.
|
||||
- Proxies may cause problems for some web applications.
|
||||
- Only works for HTTP/HTTPS.
|
||||
- Described [here](#manually-constructing-apiserver-proxy-urls).
|
||||
- Access from a node or pod in the cluster.
|
||||
- Run a pod, and then connect to a shell in it using [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).
|
||||
Connect to other nodes, pods, and services from that shell.
|
||||
- Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
|
||||
access cluster services. This is a non-standard method, and will work on some clusters but
|
||||
not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.
|
||||
-->
|
||||
### 连接的方法
|
||||
|
||||
有多种方式可以从集群外部连接节点、pod 和服务：
|
||||
|
||||
- 通过公共 IP 访问服务。
|
||||
- 类型为 `NodePort` 或 `LoadBalancer` 的服务，集群外部可以访问。
|
||||
请参阅 [服务](/docs/user-guide/services) 和 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 文档。
|
||||
- 取决于您的集群环境，该服务可能仅暴露给您的公司网络，或者也可能暴露给整个互联网。
|
||||
请考虑公开该服务是否安全。它是否进行自己的身份验证？
|
||||
- 在服务后端放置 pod。要从一组副本中访问一个特定的 pod，例如进行调试，请在 pod 上放置一个唯一的标签，然后创建一个选择此标签的新服务。
|
||||
- 在大多数情况下，应用程序开发人员不应该通过其 nodeIP 直接访问节点。
|
||||
- 使用 Proxy Verb 访问服务、node 或者 pod。
|
||||
- 在访问远程服务之前进行 apiserver 身份验证和授权。
|
||||
如果服务不能够安全地暴露到互联网，或者服务不能获得节点 IP 端口的访问权限，或者是为了 debug，那么请使用此选项。
|
||||
- 代理可能会给一些 web 应用带来问题。
|
||||
- 只适用于 HTTP/HTTPS。
|
||||
- 更多详细信息在 [这里]。
|
||||
- 从集群中的 node 或者 pod 中访问。
|
||||
- 运行一个 pod，然后使用 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) 来连接 pod 里的 shell。
|
||||
然后从 shell 中连接其它的节点、pod 和服务。
|
||||
- 有些集群可能允许您通过 ssh 连接到 node，从那您可能可以访问集群的服务。
|
||||
这是一个非正式的方式，可能可以运行在个别的集群上。
|
||||
浏览器和其它一些工具可能没有被安装。集群的 DNS 可能无法使用。
|
||||
|
||||
<!--
|
||||
### Discovering builtin services
|
||||
|
||||
Typically, there are several services which are started on a cluster by kube-system. Get a list of these
|
||||
with the `kubectl cluster-info` command:
|
||||
-->
|
||||
### 发现内建服务
|
||||
|
||||
通常来说，集群中会有 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
|
||||
```
|
||||
|
||||
<!--
|
||||
This shows the proxy-verb URL for accessing each service.
|
||||
For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
|
||||
at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at:
|
||||
`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
|
||||
(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl 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 代理来传递凭证）
|
||||
|
||||
<!--
|
||||
#### Manually constructing apiserver proxy URLs
|
||||
|
||||
As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you simply append to the service's proxy URL:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
|
||||
|
||||
If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
|
||||
|
||||
By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
|
||||
|
||||
The supported formats for the name segment of the URL are:
|
||||
|
||||
* `<service_name>` - proxies to the default or unnamed port using http
|
||||
* `<service_name>:<port_name>` - proxies to the specified port using http
|
||||
* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
|
||||
* `https:<service_name>:<port_name>` - proxies to the specified port using https
|
||||
-->
|
||||
#### 手动构建 apiserver 代理 URL
|
||||
|
||||
如上所述，您可以使用 `kubectl cluster-info` 命令来获得服务的代理 URL。要创建包含服务端点、后缀和参数的代理 URL，只需添加到服务的代理 URL：
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
|
||||
|
||||
如果尚未为端口指定名称，则不必在 URL 中指定 *port_name*。
|
||||
|
||||
默认情况下，API server 使用 http 代理您的服务。要使用 https，请在服务名称前加上 `https:`：
|
||||
`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
|
||||
|
||||
URL 名称段支持的格式为：
|
||||
|
||||
* `<service_name>` - 使用 http 代理到默认或未命名的端口
|
||||
* `<service_name>:<port_name>` - 使用 http 代理到指定的端口
|
||||
* `https:<service_name>:` - 使用 https 代理到默认或未命名的端口（注意后面的冒号）
|
||||
* `https:<service_name>:<port_name>` - 使用 https 代理到指定的端口
|
||||
|
||||
<!--
|
||||
##### Examples
|
||||
|
||||
* To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
* To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
-->
|
||||
##### 示例
|
||||
|
||||
* 要访问 Elasticsearch 服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
* 要访问 Elasticsearch 集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_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
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
### Using web browsers to access services running on the cluster
|
||||
|
||||
You may be able to put an apiserver proxy url into the address bar of a browser. However:
|
||||
|
||||
- Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
|
||||
but your cluster may not be configured to accept basic auth.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct urls in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
-->
|
||||
### 使用 web 浏览器访问运行在集群上的服务
|
||||
|
||||
您可以在浏览器地址栏中输入 apiserver 代理 URL。但是：
|
||||
|
||||
- Web 浏览器通常不能传递 token，因此您可能需要使用基本（密码）身份验证。Apiserver 可以配置为接受基本身份验证，但您的集群可能未进行配置。
|
||||
- 某些 Web 应用程序可能无法运行，尤其是那些使用客户端 javascript 以不知道代理路径前缀的方式构建 URL 的应用程序。
|
||||
|
||||
<!--
|
||||
## Requesting redirects
|
||||
|
||||
The redirect capabilities have been deprecated and removed. Please use a proxy (see below) instead.
|
||||
-->
|
||||
## 请求重定向
|
||||
|
||||
已弃用并删除了重定向功能。请改用代理（见下文）。
|
||||
|
||||
<!--
|
||||
## So Many Proxies
|
||||
|
||||
There are several different proxies you may encounter when using Kubernetes:
|
||||
|
||||
1. The [kubectl proxy](#directly-accessing-the-rest-api):
|
||||
|
||||
- runs on a user's desktop or in a pod
|
||||
- proxies from a localhost address to the Kubernetes apiserver
|
||||
- client to proxy uses HTTP
|
||||
- proxy to apiserver uses HTTPS
|
||||
- locates apiserver
|
||||
- adds authentication headers
|
||||
|
||||
-->
|
||||
## 多种代理
|
||||
|
||||
使用 Kubernetes 时可能会遇到几种不同的代理：
|
||||
|
||||
1. [kubectl 代理](#directly-accessing-the-rest-api)：
|
||||
|
||||
- 在用户的桌面或 pod 中运行
|
||||
- 代理从本地主机地址到 Kubernetes apiserver
|
||||
- 客户端到代理将使用 HTTP
|
||||
- 代理到 apiserver 使用 HTTPS
|
||||
- 定位 apiserver
|
||||
- 添加身份验证 header
|
||||
|
||||
<!--
|
||||
1. The [apiserver proxy](#discovering-builtin-services):
|
||||
|
||||
- is a bastion built into the apiserver
|
||||
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
|
||||
- runs in the apiserver processes
|
||||
- client to proxy uses HTTPS (or http if apiserver so configured)
|
||||
- proxy to target may use HTTP or HTTPS as chosen by proxy using available information
|
||||
- can be used to reach a Node, Pod, or Service
|
||||
- does load balancing when used to reach a Service
|
||||
-->
|
||||
1. [apiserver 代理](#discovering-builtin-services)：
|
||||
|
||||
- 内置于 apiserver 中
|
||||
- 将集群外部的用户连接到集群 IP，否则这些 IP 可能无法访问
|
||||
- 运行在 apiserver 进程中
|
||||
- 客户端代理使用 HTTPS（也可配置为 http）
|
||||
- 代理将根据可用的信息决定使用 HTTP 或者 HTTPS 代理到目标
|
||||
- 可用于访问节点、Pod 或服务
|
||||
- 在访问服务时进行负载平衡
|
||||
|
||||
<!--
|
||||
1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
|
||||
|
||||
- runs on each node
|
||||
- proxies UDP and TCP
|
||||
- does not understand HTTP
|
||||
- provides load balancing
|
||||
- is just used to reach services
|
||||
-->
|
||||
1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
|
||||
|
||||
- 运行在每个节点上
|
||||
- 代理 UDP 和 TCP
|
||||
- 不能代理 HTTP
|
||||
- 提供负载均衡
|
||||
- 只能用来访问服务
|
||||
|
||||
<!--
|
||||
1. A Proxy/Load-balancer in front of apiserver(s):
|
||||
|
||||
- existence and implementation varies from cluster to cluster (e.g. nginx)
|
||||
- sits between all clients and one or more apiservers
|
||||
- acts as load balancer if there are several apiservers.
|
||||
-->
|
||||
1. 位于 apiserver 之前的 Proxy/Load-balancer：
|
||||
|
||||
- 存在和实现因集群而异（例如 nginx）
|
||||
- 位于所有客户和一个或多个 apiserver 之间
|
||||
- 如果有多个 apiserver，则充当负载均衡器
|
||||
|
||||
<!--
|
||||
1. Cloud Load Balancers on external services:
|
||||
|
||||
- are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
|
||||
- are created automatically when the Kubernetes service has type `LoadBalancer`
|
||||
- use UDP/TCP only
|
||||
- implementation varies by cloud provider.
|
||||
|
||||
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
|
||||
will typically ensure that the latter types are setup correctly.
|
||||
-->
|
||||
1. 外部服务上的云负载均衡器：
|
||||
|
||||
- 由一些云提供商提供（例如 AWS ELB，Google Cloud Load Balancer）
|
||||
- 当 Kubernetes 服务类型为 `LoadBalancer` 时自动创建
|
||||
- 只使用 UDP/TCP
|
||||
- 具体实现因云提供商而异。
|
||||
|
||||
除了前两种类型之外，Kubernetes 用户通常不需要担心任何其他问题。集群管理员通常会确保后者的正确配置。
|
||||
|
||||
{{% /capture %}}
|
||||
+187
@@ -0,0 +1,187 @@
|
||||
---
|
||||
title: 同 Pod 内的容器使用共享卷通信
|
||||
redirect_from:
|
||||
- "/docs/user-guide/pods/multi-container/"
|
||||
- "/docs/user-guide/pods/multi-container.html"
|
||||
- "/docs/tasks/configure-pod-container/communicate-containers-same-pod/"
|
||||
- "/docs/tasks/configure-pod-container/communicate-containers-same-pod.html"
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
|
||||
本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
## 创建一个包含两个容器的 Pod
|
||||
|
||||
|
||||
|
||||
|
||||
在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。
|
||||
Pod 的配置文件如下：
|
||||
|
||||
{{< code file="two-container-pod.yaml" >}}
|
||||
|
||||
|
||||
|
||||
在配置文件中，你可以看到 Pod 有一个共享卷，名为 `shared-data`。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
配置文件中的第一个容器运行了一个 nginx 服务器。共享卷的挂载路径是 `/usr/share/nginx/html`。
|
||||
第二个容器是基于 debian 镜像的，有一个 `/pod-data` 的挂载路径。第二个容器运行了下面的命令然后终止。
|
||||
|
||||
echo Hello from the debian container > /pod-data/index.html
|
||||
|
||||
|
||||
|
||||
注意，第二个容器在 nginx 服务器的根目录下写了 `index.html` 文件。
|
||||
|
||||
|
||||
创建一个包含两个容器的 Pod：
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/two-container-pod.yaml
|
||||
|
||||
|
||||
查看 Pod 和容器的信息：
|
||||
|
||||
kubectl get pod two-containers --output=yaml
|
||||
|
||||
|
||||
这是输出的一部分：
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
name: two-containers
|
||||
namespace: default
|
||||
...
|
||||
spec:
|
||||
...
|
||||
containerStatuses:
|
||||
|
||||
- containerID: docker://c1d8abd1 ...
|
||||
image: debian
|
||||
...
|
||||
lastState:
|
||||
terminated:
|
||||
...
|
||||
name: debian-container
|
||||
...
|
||||
|
||||
- containerID: docker://96c1ff2c5bb ...
|
||||
image: nginx
|
||||
...
|
||||
name: nginx-container
|
||||
...
|
||||
state:
|
||||
running:
|
||||
...
|
||||
|
||||
|
||||
|
||||
你可以看到 debian 容器已经被终止了，而 nginx 服务器依然在运行。
|
||||
|
||||
|
||||
进入 nginx 容器的 shell：
|
||||
|
||||
kubectl exec -it two-containers -c nginx-container -- /bin/bash
|
||||
|
||||
|
||||
在 shell 中，确认 nginx 还在运行。
|
||||
|
||||
root@two-containers:/# ps aux
|
||||
|
||||
|
||||
输出类似于这样：
|
||||
|
||||
USER PID ... STAT START TIME COMMAND
|
||||
root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
|
||||
|
||||
|
||||
|
||||
回忆一下，debian 容器在 nginx 的根目录下创建了 `index.html` 文件。
|
||||
使用 `curl` 向 nginx 服务器发送一个 GET 请求：
|
||||
|
||||
root@two-containers:/# apt-get update
|
||||
root@two-containers:/# apt-get install curl
|
||||
root@two-containers:/# curl localhost
|
||||
|
||||
|
||||
输出表示 nginx 提供了 debian 容器写的页面：
|
||||
|
||||
Hello from the debian container
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
|
||||
## 讨论
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。
|
||||
辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。
|
||||
就如这个练习所示，通信通常是通过共享文件系统完成的，或者，也通过回环网络接口 localhost 完成。
|
||||
举个网络接口的例子，web 服务器带有一个协助程序用于拉取 Git 仓库的更新。
|
||||
|
||||
|
||||
|
||||
|
||||
在本练习中的卷为 Pod 生命周期中的容器相互通信提供了一种方法。如果 Pod 被删除或者重建了，
|
||||
任何共享卷中的数据都会丢失。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
|
||||
* 更多学习内容
|
||||
[混合容器的方式](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)。
|
||||
|
||||
|
||||
|
||||
* 学习 [模块化架构的混合容器](http://www.slideshare.net/Docker/slideshare-burns)。
|
||||
|
||||
|
||||
|
||||
* 参见 [配置一个使用存储卷的 Pod](/docs/tasks/configure-pod-container/configure-volume-storage/)。
|
||||
|
||||
|
||||
* 参见 [卷](/docs/api-reference/{{< param "version" >}}/#volume-v1-core)。
|
||||
|
||||
|
||||
* 参见 [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
+318
@@ -0,0 +1,318 @@
|
||||
---
|
||||
title: 配置对多集群的访问
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
本文展示如何使用配置文件来配置对多个集群的访问。 在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用 `kubectl config use-context` 命令快速地在集群之间进行切换。
|
||||
|
||||
{{< note >}}
|
||||
**注意：** 用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
需要安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 定义集群、用户和上下文
|
||||
|
||||
假设用户有两个集群，一个用于正式开发工作，一个用于其它临时用途（scratch）。
|
||||
在 `development` 集群中，前端开发者在名为 `frontend` 的名字空间下工作，
|
||||
存储开发者在名为 `storage` 的名字空间下工作。 在 `scratch` 集群中，
|
||||
开发人员可能在默认名字空间下工作，也可能视情况创建附加的名字空间。 访问开发集群需要通过证书进行认证。 访问其它临时用途的集群需要通过用户名和密码进行认证。
|
||||
|
||||
创建名为 `config-exercise` 的目录。 在
|
||||
`config-exercise` 目录中，创建名为 `config-demo` 的文件，其内容为：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
clusters:
|
||||
- cluster:
|
||||
name: development
|
||||
- cluster:
|
||||
name: scratch
|
||||
|
||||
users:
|
||||
- name: developer
|
||||
- name: experimenter
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
name: dev-frontend
|
||||
- context:
|
||||
name: dev-storage
|
||||
- context:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
配置文件描述了集群、用户名和上下文。 `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。
|
||||
|
||||
进入 `config-exercise` 目录。 输入以下命令，将群集详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
将用户详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
将上下文详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
输出展示了两个集群、两个用户和三个上下文：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://5.6.7.8
|
||||
name: scratch
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
current-context: ""
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
- name: experimenter
|
||||
user:
|
||||
password: some-password
|
||||
username: exp
|
||||
```
|
||||
|
||||
每个上下文包含三部分（集群、用户和名字空间），例如，
|
||||
`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的 `frontend` 名字空间。
|
||||
|
||||
设置当前上下文：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间，同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
|
||||
使用 `--minify` 参数，来查看与当前上下文相关联的配置信息。
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
输出结果展示了 `dev-frontend` 上下文相关的配置信息：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
current-context: dev-frontend
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
现在假设用户希望在其它临时用途集群中工作一段时间。
|
||||
|
||||
将当前上下文更改为 `exp-scratch`：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
现在用户 `kubectl` 下达的任何命令都将应用于 `scratch` 集群的默认名字空间。 同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
|
||||
查看更新后的当前上下文 `exp-scratch` 相关的配置：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
最后，假设用户希望在 `development` 集群中的 `storage` 名字空间下工作一段时间。
|
||||
|
||||
将当前上下文更改为 `dev-storage`：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
查看更新后的当前上下文 `dev-storage` 相关的配置：
|
||||
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
## 创建第二个配置文件
|
||||
|
||||
在 `config-exercise` 目录中，创建名为 `config-demo-2` 的文件，其中包含以下内容：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
上述配置文件定义了一个新的上下文，名为 `dev-ramp-up`。
|
||||
|
||||
## 设置 KUBECONFIG 环境变量
|
||||
|
||||
查看是否有名为 `KUBECONFIG` 的环境变量。 如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。
|
||||
例如，在 Linux 中：
|
||||
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔，在 Windows 中以分号分隔。 如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如，在 Linux 中：
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
|
||||
在 `config-exercise` 目录中输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。 特别地， 注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自 `config-demo` 文件的三个上下文：
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
更多关于 kubeconfig 文件如何合并的信息，请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
|
||||
## 探索 $HOME/.kube 目录
|
||||
|
||||
如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互。 那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
|
||||
进入 `$HOME/.kube` 目录， 看看那里有什么文件。 通常会有一个名为
|
||||
`config` 的文件，目录中可能还有其他配置文件。 请简单地熟悉这些文件的内容。
|
||||
|
||||
## 将 $HOME/.kube/config 追加到 KUBECONFIG 环境变量中
|
||||
|
||||
如果有 `$HOME/.kube/config` 文件，并且还未列在 `KUBECONFIG` 环境变量中，
|
||||
那么现在将它追加到 `KUBECONFIG` 环境变量中。
|
||||
例如，在 Linux 中：
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
|
||||
在配置练习目录中输入以下命令，来查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
## 清理
|
||||
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。 例如，在 Linux 中：
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl 配置](/docs/user-guide/kubectl/{{< param "version" >}}/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
approvers:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
title: 配置你的云平台防火墙
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
许多云服务商（比如 Google Compute Engine）定义防火墙以防止服务无意间暴露到 internet 上。
|
||||
当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。
|
||||
本文描述了这个过程，以及其他云服务商的具体信息。
|
||||
|
||||
|
||||
## 负载均衡（LoadBalancer）服务的访问限制
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。
|
||||
这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Kubernetes Engine 和 AWS。
|
||||
如果云服务商不支持这个功能，这个字段会被忽略。
|
||||
|
||||
|
||||
|
||||
假设 10.0.0.0/8 是内部的子网。在下面这个例子中，会创建一个只有集群内部 ip 可以访问的负载均衡器。
|
||||
集群外部的客户端是无法访问这个负载均衡器的。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
loadBalancerSourceRanges:
|
||||
- 10.0.0.0/8
|
||||
```
|
||||
|
||||
|
||||
这个例子中，会创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
ports:
|
||||
- port: 8765
|
||||
targetPort: 9376
|
||||
selector:
|
||||
app: example
|
||||
type: LoadBalancer
|
||||
loadBalancerSourceRanges:
|
||||
- 130.211.204.1/32
|
||||
- 130.211.204.2/32
|
||||
```
|
||||
|
||||
|
||||
### 谷歌计算引擎（Google Compute Engine）
|
||||
|
||||
|
||||
|
||||
|
||||
当以 `spec.type: LoadBalancer` 使用服务时，防火墙会被自动打开。
|
||||
然而，当以 `spec.type: NodePort` 使用服务时，防火墙默认 *不会* 被打开。
|
||||
|
||||
|
||||
Google Compute Engine 的防火墙文档在[别处](https://cloud.google.com/compute/docs/networking#firewalls_1)。
|
||||
|
||||
|
||||
你可以使用 `gcloud` 命令行工具添加一个防火墙：
|
||||
|
||||
```shell
|
||||
$ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
|
||||
```
|
||||
|
||||
|
||||
|
||||
**注意**
|
||||
使用 Google Compute Engine 平台的防火墙时有一个重要的关于安全的注意点：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在 Kubernetes v1.0.0 版本，GCE 防火墙是定义按虚拟机（VM）来的，而不是按 ip 来的。
|
||||
这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务
|
||||
都有被外部访问的潜在可能。注意，这对于其他 Kubernetes 服务来说不是问题，因为他们监
|
||||
听的 IP 地址与主机节点的外部 IP 地址不同。
|
||||
|
||||
|
||||
考虑一下:
|
||||
|
||||
* 你创建了一个服务，使用了外部服务均衡 (IP 地址为 1.2.3.4) 和 80 端口。
|
||||
* 你在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
|
||||
服务发送数据包。
|
||||
* 你又在虚拟机（IP 为2.3.4.5）上使用 80 端口启动了一台 nginx 服务器.
|
||||
这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了 internet 上。
|
||||
|
||||
|
||||
|
||||
|
||||
因此，在 Google Compute Engine 或者 Google Kubernetes Engine 上开启防火墙端口时请
|
||||
小心。你可能无意间把其他服务也暴露给了 internet。
|
||||
|
||||
|
||||
这个问题会在 Kubernetes 后续版本中被修复。
|
||||
|
||||
|
||||
### 其他云服务商
|
||||
|
||||
|
||||
即将更新
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
<!--
|
||||
---
|
||||
title: Configure DNS for a Cluster
|
||||
weight: 120
|
||||
content_template: templates/concept
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 为集群配置 DNS
|
||||
weight: 120
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default.
|
||||
-->
|
||||
Kubernetes 提供 DNS 集群插件，大多数支持的环境默认情况下都会启用。
|
||||
{{% /capture %}}
|
||||
{{% capture body %}}
|
||||
<!--
|
||||
For more information on how to configure DNS for a Kubernetes cluster, see the [Kubernetes DNS sample plugin.](https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns)
|
||||
-->
|
||||
有关如何为 Kubernetes 集群配置 DNS 的详细信息，请参阅 [Kubernetes DNS 插件示例.](https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: 使用 Service 把前端连接到后端
|
||||
content_template: templates/tutorial
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
|
||||
|
||||
|
||||
本任务会描述如何创建前端微服务和后端微服务。后端微服务是一个 hello 欢迎程序。
|
||||
前端和后端的连接是通过 Kubernetes 服务对象（Service object）完成的。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
|
||||
|
||||
|
||||
* 使用部署对象（Deployment object）创建并运行一个微服务
|
||||
* 从后端将流量路由到前端
|
||||
* 使用服务对象把前端应用连接到后端应用
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
* 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)，
|
||||
所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
|
||||
[NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
|
||||
### 使用部署对象（Deployment）创建后端
|
||||
|
||||
|
||||
|
||||
后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件：
|
||||
|
||||
{{< code file="hello.yaml" >}}
|
||||
|
||||
|
||||
创建后端 Deployment：
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello.yaml
|
||||
```
|
||||
|
||||
|
||||
查看后端的 Deployment 信息：
|
||||
|
||||
```
|
||||
kubectl describe deployment hello
|
||||
```
|
||||
|
||||
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Name: hello
|
||||
Namespace: default
|
||||
CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
|
||||
Labels: app=hello
|
||||
tier=backend
|
||||
track=stable
|
||||
Selector: app=hello,tier=backend,track=stable
|
||||
Replicas: 7 updated | 7 total | 7 available | 0 unavailable
|
||||
StrategyType: RollingUpdate
|
||||
MinReadySeconds: 0
|
||||
RollingUpdateStrategy: 1 max unavailable, 1 max surge
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: hello-3621623197 (7/7 replicas created)
|
||||
Events:
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
### 创建后端服务对象（Service object）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
前端连接到后端的关键是 Service。Service 创建一个固定 IP 和 DNS 解析名入口，
|
||||
使得后端微服务可达。Service 使用 selector 标签来寻找目标 Pod。
|
||||
|
||||
|
||||
首先，浏览 Service 的配置文件：
|
||||
|
||||
{{< code file="hello-service.yaml" >}}
|
||||
|
||||
|
||||
|
||||
配置文件中，你可以看到 Service 将流量路由到包含 `app: hello` 和 `tier: backend` 标签的 Pod。
|
||||
|
||||
|
||||
创建 `hello` Service：
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello-service.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
此时，你已经有了一个在运行的后端 Deployment，你也有了一个 Service 用于路由网络流量。
|
||||
|
||||
|
||||
### 创建前端应用
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
既然你已经有了后端应用，你可以创建一个前端应用连接到后端。前端应用通过 DNS 名连接到后端的工作 Pods。
|
||||
DNS 名是 "hello"，也就是 Service 配置文件中 `name` 字段的值。
|
||||
|
||||
|
||||
|
||||
前端 Deployment 中的 Pods 运行一个 nginx 镜像，这个已经配置好镜像去寻找后端的 hello Service。
|
||||
只是 nginx 的配置文件：
|
||||
|
||||
{{< code file="frontend/frontend.conf" >}}
|
||||
|
||||
|
||||
|
||||
|
||||
与后端类似，前端用包含一个 Deployment 和一个 Service。Service 的配置文件包含了 `type: LoadBalancer`，
|
||||
也就是说，Service 会使用你的云服务商的默认负载均衡设备。
|
||||
|
||||
{{< code file="frontend.yaml" >}}
|
||||
|
||||
|
||||
创建前端 Deployment 和 Service：
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/frontend.yaml
|
||||
```
|
||||
|
||||
|
||||
通过输出确认两个资源都已经被创建：
|
||||
|
||||
```
|
||||
deployment "frontend" created
|
||||
service "frontend" created
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**注意**：这个 nginx 配置文件是被打包在 [容器镜像](/docs/tasks/access-application-cluster/frontend/Dockerfile) 里的。
|
||||
更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)，这样的话你可以更轻易地更改配置。
|
||||
|
||||
|
||||
### 与前端 Service 交互
|
||||
|
||||
|
||||
|
||||
一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP：
|
||||
|
||||
```
|
||||
kubectl get service frontend
|
||||
```
|
||||
|
||||
|
||||
|
||||
外部 IP 字段的生成可能需要一些时间。如果是这种情况，外部 IP 会显示为 `<pending>`。
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend 10.51.252.116 <pending> 80/TCP 10s
|
||||
```
|
||||
|
||||
|
||||
使用相同的命令直到它显示外部 IP 地址：
|
||||
|
||||
```
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
frontend 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
|
||||
```
|
||||
|
||||
|
||||
### 通过前端发送流量
|
||||
|
||||
|
||||
|
||||
前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部 IP 访问服务端点。
|
||||
|
||||
```
|
||||
curl http://<EXTERNAL-IP>
|
||||
```
|
||||
|
||||
|
||||
后端生成的消息输出如下：
|
||||
|
||||
```
|
||||
{"message":"Hello"}
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
|
||||
|
||||
* 了解更多 [Services](/docs/concepts/services-networking/service/)
|
||||
* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,322 @@
|
||||
<!--
|
||||
---
|
||||
title: Create an External Load Balancer
|
||||
content_template: templates/task
|
||||
weight: 80
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 创建一个外部负载均衡器
|
||||
content_template: templates/task
|
||||
weight: 80
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to create an External Load Balancer.
|
||||
|
||||
When creating a service, you have the option of automatically creating a
|
||||
cloud network load balancer. This provides an externally-accessible IP address
|
||||
that sends traffic to the correct port on your cluster nodes
|
||||
_provided your cluster runs in a supported environment and is configured with
|
||||
the correct cloud load balancer provider package_.
|
||||
|
||||
For information on provisioning and using an Ingress resource that can give
|
||||
services externally-reachable URLs, load balance the traffic, terminate SSL etc.,
|
||||
please check the [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
documentation.
|
||||
-->
|
||||
本文展示如何创建一个外部负载均衡器。
|
||||
|
||||
创建服务时，您可以选择自动创建云网络负载均衡器。这提供了一个外部可访问的 IP 地址，可将流量分配到集群节点上的正确端口上 _假设集群在支持的环境中运行，并配置了正确的云负载平衡器提供商包_。
|
||||
|
||||
有关如何配置和使用 Ingress 资源以为服务提供外部可访问的 URL、负载均衡流量、终止 SSL 等功能，请查看 [Ingress](/docs/concepts/services-networking/ingress/) 文档。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Configuration file
|
||||
|
||||
To create an external load balancer, add the following line to your
|
||||
[service configuration file](/docs/concepts/services-networking/service/#type-loadbalancer):
|
||||
-->
|
||||
## 配置文件
|
||||
|
||||
要创建外部负载均衡器，请将以下内容添加到 [服务配置文件](/docs/concepts/services-networking/service/#type-loadbalancer)：
|
||||
|
||||
```json
|
||||
"type": "LoadBalancer"
|
||||
```
|
||||
|
||||
<!--
|
||||
Your configuration file might look like:
|
||||
-->
|
||||
您的配置文件可能会如下所示：
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "example-service"
|
||||
},
|
||||
"spec": {
|
||||
"ports": [{
|
||||
"port": 8765,
|
||||
"targetPort": 9376
|
||||
}],
|
||||
"selector": {
|
||||
"app": "example"
|
||||
},
|
||||
"type": "LoadBalancer"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
## Using kubectl
|
||||
|
||||
You can alternatively create the service with the `kubectl expose` command and
|
||||
its `--type=LoadBalancer` flag:
|
||||
-->
|
||||
## 使用 kubectl
|
||||
|
||||
您也可以使用 `kubectl expose` 命令及其 `--type=LoadBalancer` 参数创建服务：
|
||||
|
||||
```bash
|
||||
kubectl expose rc example --port=8765 --target-port=9376 \
|
||||
--name=example-service --type=LoadBalancer
|
||||
```
|
||||
|
||||
<!--
|
||||
This command creates a new service using the same selectors as the referenced
|
||||
resource (in the case of the example above, a replication controller named
|
||||
`example`).
|
||||
|
||||
For more information, including optional flags, refer to the
|
||||
[`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
-->
|
||||
此命令通过使用与引用资源（在上面的示例的情况下，名为 `example` 的 replication controller）相同的选择器来创建一个新的服务。
|
||||
|
||||
更多信息（包括更多的可选参数），请参阅 [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose)。
|
||||
|
||||
<!--
|
||||
## Finding your IP address
|
||||
|
||||
You can find the IP address created for your service by getting the service
|
||||
information through `kubectl`:
|
||||
-->
|
||||
## 找到您的 IP 地址
|
||||
|
||||
您可以通过 `kubectl` 获取服务信息，找到为您的服务创建的 IP 地址：
|
||||
|
||||
```bash
|
||||
kubectl describe services example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
which should produce output like this:
|
||||
-->
|
||||
这将获得如下输出：
|
||||
|
||||
```bash
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
Selector: app=example
|
||||
Type: LoadBalancer
|
||||
IP: 10.67.252.103
|
||||
LoadBalancer Ingress: 123.45.678.9
|
||||
Port: <unnamed> 80/TCP
|
||||
NodePort: <unnamed> 32445/TCP
|
||||
Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
<!--
|
||||
The IP address is listed next to `LoadBalancer Ingress`.
|
||||
-->
|
||||
IP 地址列在 `LoadBalancer Ingress` 旁边。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
|
||||
-->
|
||||
**注意：** 如果您在 Minikube 上运行服务，您可以通过以下命令找到分配的 IP 地址和端口：
|
||||
{{< /note >}}
|
||||
```bash
|
||||
minikube service example-service --url
|
||||
```
|
||||
|
||||
<!--
|
||||
## Preserving the client source IP
|
||||
|
||||
Due to the implementation of this feature, the source IP seen in the target
|
||||
container will *not be the original source IP* of the client. To enable
|
||||
preservation of the client IP, the following fields can be configured in the
|
||||
service spec (supported in GCE/Google Kubernetes Engine environments):
|
||||
|
||||
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
|
||||
external traffic to node-local or cluster-wide endpoints. There are two available
|
||||
options: "Cluster" (default) and "Local". "Cluster" obscures the client source
|
||||
IP and may cause a second hop to another node, but should have good overall
|
||||
load-spreading. "Local" preserves the client source IP and avoids a second hop
|
||||
for LoadBalancer and NodePort type services, but risks potentially imbalanced
|
||||
traffic spreading.
|
||||
* `service.spec.healthCheckNodePort` - specifies the healthcheck nodePort
|
||||
(numeric port number) for the service. If not specified, healthCheckNodePort is
|
||||
created by the service API backend with the allocated nodePort. It will use the
|
||||
user-specified nodePort value if specified by the client. It only has an
|
||||
effect when type is set to "LoadBalancer" and externalTrafficPolicy is set
|
||||
to "Local".
|
||||
|
||||
This feature can be activated by setting `externalTrafficPolicy` to "Local" in the
|
||||
Service Configuration file.
|
||||
-->
|
||||
## 保留客户端源 IP
|
||||
|
||||
由于此功能的实现，目标容器中看到的源 IP 将 *不是客户端的原始源 IP*。要启用保留客户端 IP，可以在服务的 spec 中配置以下字段（支持 GCE/Google Kubernetes Engine 环境）：
|
||||
|
||||
* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项："Cluster"（默认）和 "Local"。"Cluster" 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。 "Local" 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，但存在潜在的不均衡流量传播风险。
|
||||
* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定，则 serviceCheckNodePort 由服务 API 后端使用已分配的 nodePort 创建。如果客户端指定，它将使用客户端指定的 nodePort 值。仅当 type 设置为 "LoadBalancer" 并且 externalTrafficPolicy 设置为 "Local" 时才生效。
|
||||
|
||||
可以通过在服务的配置文件中将 `externalTrafficPolicy` 设置为 "Local" 来激活此功能。
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "example-service"
|
||||
},
|
||||
"spec": {
|
||||
"ports": [{
|
||||
"port": 8765,
|
||||
"targetPort": 9376
|
||||
}],
|
||||
"selector": {
|
||||
"app": "example"
|
||||
},
|
||||
"type": "LoadBalancer",
|
||||
"externalTrafficPolicy": "Local"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
### Feature availability
|
||||
|
||||
| k8s version | Feature support |
|
||||
| :---------: |:-----------:|
|
||||
| 1.7+ | Supports the full API fields |
|
||||
| 1.5 - 1.6 | Supports Beta Annotations |
|
||||
| <1.5 | Unsupported |
|
||||
|
||||
Below you could find the deprecated Beta annotations used to enable this feature
|
||||
prior to its stable version. Newer Kubernetes versions may stop supporting these
|
||||
after v1.7. Please update existing applications to use the fields directly.
|
||||
|
||||
* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` field
|
||||
* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` field
|
||||
|
||||
`service.beta.kubernetes.io/external-traffic` annotation has a different set of values
|
||||
compared to the `service.spec.externalTrafficPolicy` field. The values match as follows:
|
||||
|
||||
* "OnlyLocal" for annotation <-> "Local" for field
|
||||
* "Global" for annotation <-> "Cluster" for field
|
||||
|
||||
**Note that this feature is not currently implemented for all cloudproviders/environments.**
|
||||
-->
|
||||
### 特性可用性
|
||||
|
||||
| k8s 版本 | 特性支持 |
|
||||
| :---------: |:-----------:|
|
||||
| 1.7+ | 支持完整的 API 字段 |
|
||||
| 1.5 - 1.6 | 支持 Beta Annotation |
|
||||
| <1.5 | 不支持 |
|
||||
|
||||
您可以在下面找到已弃用的 Beta annotation，在稳定版本前使用它来使用该功能。较新的 Kubernetes 版本可能会在 v1.7 之后停止支持这些功能。
|
||||
请更新现有应用程序以直接使用这些字段。
|
||||
|
||||
* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` 字段
|
||||
* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` 字段
|
||||
|
||||
`service.beta.kubernetes.io/external-traffic` annotation 与 `service.spec.externalTrafficPolicy` 字段相比拥有一组不同的值。值匹配如下：
|
||||
|
||||
* "OnlyLocal" annotation <-> "Local" 字段
|
||||
* "Global" annotation <-> "Cluster" 字段
|
||||
|
||||
**请注意，此功能目前尚未实现在所有云提供商/环境中。**
|
||||
|
||||
<!--
|
||||
Known issues:
|
||||
-->
|
||||
已知的问题：
|
||||
|
||||
* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
|
||||
* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!--
|
||||
## External Load Balancer Providers
|
||||
|
||||
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
|
||||
|
||||
When the service type is set to `LoadBalancer`, Kubernetes provides functionality equivalent to `type=<ClusterIP>` to pods within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object.
|
||||
-->
|
||||
## 外部负载均衡器提供商
|
||||
|
||||
请务必注意，此功能的数据路径由 Kubernetes 集群外部的负载均衡器提供。
|
||||
|
||||
当服务类型设置为 `LoadBalancer` 时，Kubernetes 向集群中的 pod 提供与 `type=<ClusterIP>` 等效的功能，并通过使用 Kubernetes pod 的条目对负载均衡器（从外部到 Kubernetes）进行编程来扩展它。 Kubernetes 服务控制器自动创建外部负载均衡器，健康检查（如果需要），防火墙规则（如果需要），并获取云提供商分配的外部 IP 并将其填充到服务对象中。
|
||||
|
||||
<!--
|
||||
## Caveats and Limitations when preserving source IPs
|
||||
|
||||
GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB
|
||||
kube-proxy rules which would correctly balance across all endpoints.
|
||||
|
||||
With the new functionality, the external traffic will not be equally load balanced across pods, but rather
|
||||
equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability
|
||||
for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
|
||||
pods on each node).
|
||||
|
||||
We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal
|
||||
distribution will be seen, even without weights.
|
||||
|
||||
Once the external load balancers provide weights, this functionality can be added to the LB programming path.
|
||||
*Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date*
|
||||
|
||||
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
|
||||
-->
|
||||
## 保留源 IP 时的注意事项和限制
|
||||
|
||||
GCE/AWS 负载均衡器不为其目标池提供权重。对于旧的 LB kube-proxy 规则来说，这不是一个问题，它可以在所有端点之间正确平衡。
|
||||
|
||||
使用新功能，外部流量不会在 pod 之间平均负载，而是在节点级别平均负载（因为 GCE/AWS 和其他外部 LB 实现无法指定每个节点的权重，因此它们的平衡跨所有目标节点，并忽略每个节点上的 pod 数量）。
|
||||
|
||||
但是，我们可以声明，对于 NumServicePods << NumNodes 或 NumServicePods >> NumNodes 时，即使没有权重，也会看到接近相等的分布。
|
||||
|
||||
一旦外部负载平衡器提供权重，就可以将此功能添加到 LB 编程路径中。
|
||||
*未来工作：1.4 版本不提供权重支持，但可能会在将来版本中添加*
|
||||
|
||||
内部 pod 到 pod 的流量应该与 ClusterIP 服务类似，所有 pod 的概率相同。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: frontend
|
||||
ports:
|
||||
- protocol: "TCP"
|
||||
port: 80
|
||||
targetPort: 80
|
||||
type: LoadBalancer
|
||||
---
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: frontend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: "gcr.io/google-samples/hello-frontend:1.0"
|
||||
lifecycle:
|
||||
preStop:
|
||||
exec:
|
||||
command: ["/usr/sbin/nginx","-s","quit"]
|
||||
@@ -0,0 +1,11 @@
|
||||
upstream hello {
|
||||
server hello;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
|
||||
location / {
|
||||
proxy_pass http://hello;
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,12 @@
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
selector:
|
||||
app: hello
|
||||
tier: backend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
targetPort: http
|
||||
@@ -0,0 +1,19 @@
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: hello
|
||||
spec:
|
||||
replicas: 7
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: hello
|
||||
tier: backend
|
||||
track: stable
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: "gcr.io/google-samples/hello-go-gke:1.0"
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 80
|
||||
+193
@@ -0,0 +1,193 @@
|
||||
<!--
|
||||
---
|
||||
title: List All Container Images Running in a Cluster
|
||||
content_template: templates/task
|
||||
weight: 100
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 列出集群中所有运行容器的镜像
|
||||
content_template: templates/task
|
||||
weight: 100
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to use kubectl to list all of the Container images
|
||||
for Pods running in a cluster.
|
||||
-->
|
||||
本文展示如何使用 kubectl 来列出集群中所有运行 pod 的容器的镜像
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
In this exercise you will use kubectl to fetch all of the Pods
|
||||
running in a cluster, and format the output to pull out the list
|
||||
of Containers for each.
|
||||
-->
|
||||
在本练习中，您将使用 kubectl 来获取集群中运行的所有 Pod，并格式化输出来提取每个 pod 中的容器列表。
|
||||
|
||||
<!--
|
||||
## List all Containers in all namespaces
|
||||
|
||||
- Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces`
|
||||
- Format the output to include only the list of Container image names
|
||||
using `-o jsonpath={..image}`. This will recursively parse out the
|
||||
`image` field from the returned json.
|
||||
- See the [jsonpath reference](/docs/user-guide/jsonpath/)
|
||||
for further information on how to use jsonpath.
|
||||
- Format the output using standard tools: `tr`, `sort`, `uniq`
|
||||
- Use `tr` to replace spaces with newlines
|
||||
- Use `sort` to sort the results
|
||||
- Use `uniq` to aggregate image counts
|
||||
-->
|
||||
## 列出所有命名空间下的所有容器
|
||||
|
||||
- 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
|
||||
- 使用 `-o jsonpath={..image}` 来格式化输出，以仅包含容器镜像名称。
|
||||
这将以递归方式从返回的 json 中解析出 `image` 字段。
|
||||
- 参阅 [jsonpath reference](/docs/user-guide/jsonpath/) 来获取更多关于如何使用 jsonpath 的信息。
|
||||
- 使用标准化工具来格式化输出：`tr`, `sort`, `uniq`
|
||||
- 使用 `tr` 以用换行符替换空格
|
||||
- 使用 `sort` 来对结果进行排序
|
||||
- 使用 `uniq` 来聚合镜像计数
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
uniq -c
|
||||
```
|
||||
|
||||
<!--
|
||||
The above command will recursively return all fields named `image`
|
||||
for all items returned.
|
||||
|
||||
As an alternative, it is possible to use the absolute path to the image
|
||||
field within the Pod. This ensures the correct field is retrieved
|
||||
even when the field name is repeated,
|
||||
e.g. many fields are called `name` within a given item:
|
||||
-->
|
||||
上面的命令将递归获取所有返回项目的名为 `image` 的字段。
|
||||
|
||||
作为替代方案，可以使用 Pod 的镜像字段的绝对路径。这确保即使字段名称重复的情况下也能检索到正确的字段，例如，特定项目中的许多字段都称为 `name`：
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
|
||||
```
|
||||
|
||||
<!--
|
||||
The jsonpath is interpreted as follows:
|
||||
|
||||
- `.items[*]`: for each returned value
|
||||
- `.spec`: get the spec
|
||||
- `.containers[*]`: for each container
|
||||
- `.image`: get the image
|
||||
-->
|
||||
jsonpath 解释如下：
|
||||
|
||||
- `.items[*]`: 对于每个返回的值
|
||||
- `.spec`: 获取 spec
|
||||
- `.containers[*]`: 对于每个容器
|
||||
- `.image`: 获取镜像
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
the `.items[*]` portion of the path should be omitted because a single
|
||||
Pod is returned instead of a list of items.
|
||||
-->
|
||||
**注意：** 按名字获取单个 Pod 时，例如 `kubectl get pod nginx`，路径的 `.items[*]` 部分应该省略，因为返回的是一个 Pod 而不是一个项目列表。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## List Containers by Pod
|
||||
|
||||
The formatting can be controlled further by using the `range` operation to
|
||||
iterate over elements individually.
|
||||
-->
|
||||
## 列出 Pod 中的容器
|
||||
|
||||
可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
|
||||
sort
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers filtering by Pod label
|
||||
|
||||
To target only Pods matching a specific label, use the -l flag. The
|
||||
following matches only Pods with labels matching `app=nginx`.
|
||||
-->
|
||||
## 列出以 label 过滤后的 Pod 的所有容器
|
||||
|
||||
要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers filtering by Pod namespace
|
||||
|
||||
To target only pods in a specific namespace, use the namespace flag. The
|
||||
following matches only Pods in the `kube-system` namespace.
|
||||
-->
|
||||
## 列出以命名空间过滤后的 Pod 的所有容器
|
||||
|
||||
要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
|
||||
|
||||
```sh
|
||||
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
|
||||
```
|
||||
|
||||
<!--
|
||||
## List Containers using a go-template instead of jsonpath
|
||||
|
||||
As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/)
|
||||
for formatting the output:
|
||||
-->
|
||||
## 使用 go-template 代替 jsonpath 来获取容器
|
||||
|
||||
作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://golang.org/pkg/text/template/) 来格式化输出：
|
||||
|
||||
|
||||
```sh
|
||||
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
|
||||
```
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
### Reference
|
||||
|
||||
* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
|
||||
* [Go template](https://golang.org/pkg/text/template/) reference guide
|
||||
-->
|
||||
### 参考
|
||||
|
||||
* [Jsonpath](/docs/user-guide/jsonpath/) 参考指南
|
||||
* [Go template](https://golang.org/pkg/text/template/) 参考指南
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
+190
@@ -0,0 +1,190 @@
|
||||
<!--
|
||||
---
|
||||
title: Provide Load-Balanced Access to an Application in a Cluster
|
||||
content_template: templates/tutorial
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 提供对集群中应用程序的负载均衡访问
|
||||
content_template: templates/tutorial
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to create a Kubernetes Service object that provides
|
||||
load-balanced access to an application running in a cluster.
|
||||
-->
|
||||
本文展示如何创建一个 Kubernetes 服务对象，来提供负载均衡入口以访问集群内正在运行的应用程序。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
<!--
|
||||
* Run two instances of a Hello World application
|
||||
* Create a Service object
|
||||
* Use the Service object to access the running application
|
||||
-->
|
||||
* 运行两个 Hello World 应用示例
|
||||
* 创建一个服务对象
|
||||
* 使用这个服务对象来访问正在运行的应用
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
<!--
|
||||
## Creating a Service for an application running in two pods
|
||||
|
||||
1. Run a Hello World application in your cluster:
|
||||
-->
|
||||
## 为在两个 pod 中运行的应用程序创建服务
|
||||
|
||||
1. 在您的集群中运行一个 Hello World 应用：
|
||||
|
||||
```
|
||||
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
|
||||
<!--
|
||||
1. List the pods that are running the Hello World application:
|
||||
-->
|
||||
1. 列出运行 Hello World 应用的 pod：
|
||||
|
||||
```
|
||||
kubectl get pods --selector="run=load-balancer-example"
|
||||
```
|
||||
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出应类似于：
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hello-world-2189936611-8fyp0 1/1 Running 0 6m
|
||||
hello-world-2189936611-9isq8 1/1 Running 0 6m
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Create a Service object that exposes the deployment:
|
||||
-->
|
||||
1. 创建一个服务对象来暴露这个 deployment：
|
||||
|
||||
```
|
||||
kubectl expose deployment <your-deployment-name> --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
where `<your-deployment-name>` is the name of your deployment.
|
||||
|
||||
1. Display the IP addresses for your service:
|
||||
-->
|
||||
这里的 `<your-deployment-name>` 是您的 deployment 的名称。
|
||||
|
||||
1. 显示您服务的 IP 地址：
|
||||
|
||||
```
|
||||
kubectl get services example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows the internal IP address and the external IP address of
|
||||
your service. If the external IP address shows as `<pending>`, repeat the
|
||||
command.
|
||||
-->
|
||||
输出展示了您服务的内部和外部 IP 地址。如果外部 IP 地址显示 `<pending>`，那么您需要重复运行以上命令。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** If you are using Minikube, you don't get an external IP address. The
|
||||
external IP address remains in the pending state.
|
||||
-->
|
||||
**注意：** 如果您使用 Minikube，那么您将不会获得外部 IP 地址。外部 IP 地址将保持 pending 状态。
|
||||
{{< /note >}}
|
||||
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
example-service 10.0.0.160 <pending> 8080/TCP 40s
|
||||
|
||||
<!--
|
||||
1. Use your Service object to access the Hello World application:
|
||||
-->
|
||||
1. 使用您的服务对象来访问这个 Hello World 应用：
|
||||
|
||||
curl <your-external-ip-address>:8080
|
||||
|
||||
<!--
|
||||
where `<your-external-ip-address>` is the external IP address of your
|
||||
service.
|
||||
|
||||
The output is a hello message from the application:
|
||||
-->
|
||||
这里的 `<your-external-ip-address>` 是您服务的外部 IP 地址。
|
||||
|
||||
输出是来自应用的 hello 消息：
|
||||
|
||||
Hello Kubernetes!
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** If you are using Minikube, enter these commands:
|
||||
-->
|
||||
**注意：** 如果您使用 Minikube，输入以下命令：
|
||||
{{< /note >}}
|
||||
|
||||
kubectl cluster-info
|
||||
kubectl describe services example-service
|
||||
|
||||
<!--
|
||||
The output displays the IP address of your Minikube node and the NodePort
|
||||
value for your service. Then enter this command to access the Hello World
|
||||
application:
|
||||
-->
|
||||
输出将展示您的 Minikube 节点的 IP 地址和您服务的 NodePort 值。然后输入以下命令来访问这个 Hello World 应用：
|
||||
|
||||
curl <minikube-node-ip-address>:<service-node-port>
|
||||
|
||||
<!--
|
||||
where `<minikube-node-ip-address>` us the IP address of your Minikube node,
|
||||
and `<service-node-port>` is the NodePort value for your service.
|
||||
-->
|
||||
这里的 `<minikube-node-ip-address>` 是您的 Minikube 节点的 IP 地址，`<service-node-port>` 是您服务的 NodePort 值。
|
||||
|
||||
<!--
|
||||
## Using a service configuration file
|
||||
|
||||
As an alternative to using `kubectl expose`, you can use a
|
||||
[service configuration file](/docs/concepts/services-networking/service/)
|
||||
to create a Service.
|
||||
-->
|
||||
## 使用服务配置文件
|
||||
|
||||
作为 `kubectl expose` 的替代方法，您可以使用 [服务配置文件](/docs/concepts/services-networking/service/) 来创建服务。
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
Learn more about
|
||||
[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
|
||||
-->
|
||||
学习更多关于如何 [通过服务连接应用](/docs/concepts/services-networking/connect-applications-service/)。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
+222
@@ -0,0 +1,222 @@
|
||||
<!--
|
||||
---
|
||||
title: Use Port Forwarding to Access Applications in a Cluster
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 使用端口转发来访问集群中的应用
|
||||
content_template: templates/task
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to use `kubectl port-forward` to connect to a Redis
|
||||
server running in a Kubernetes cluster. This type of connection can be useful
|
||||
for database debugging.
|
||||
-->
|
||||
本文展示如何使用 `kubectl port-forward` 连接到在 Kubernetes 集群中运行的 Redis 服务。这种类型的连接对数据库调试很有用。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!--
|
||||
* Install [redis-cli](http://redis.io/topics/rediscli).
|
||||
-->
|
||||
* 安装 [redis-cli](http://redis.io/topics/rediscli)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Creating Redis deployment and service
|
||||
|
||||
1. Create a Redis deployment:
|
||||
-->
|
||||
## 创建 Redis deployment 和服务
|
||||
|
||||
1. 创建一个 Redis deployment：
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tutorials/stateless-application/guestbook/redis-master-deployment.yaml
|
||||
|
||||
<!--
|
||||
The output of a successful command verifies that the deployment was created:
|
||||
-->
|
||||
查看输出是否成功，以验证是否成功创建 deployment：
|
||||
|
||||
deployment "redis-master" created
|
||||
|
||||
<!--
|
||||
When the pod is ready, you can get:
|
||||
-->
|
||||
当 pod 是 ready 时，您将得到：
|
||||
|
||||
kubectl get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
redis-master-765d459796-258hz 1/1 Running 0 50s
|
||||
|
||||
kubectl get deployment
|
||||
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
redis-master 1 1 1 1 55s
|
||||
|
||||
kubectl get rs
|
||||
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
redis-master-765d459796 1 1 1 1m
|
||||
|
||||
|
||||
<!--
|
||||
2. Create a Redis service:
|
||||
-->
|
||||
2. 创建一个 Redis 服务：
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tutorials/stateless-application/guestbook/redis-master-service.yaml
|
||||
|
||||
<!--
|
||||
The output of a successful command verifies that the service was created:
|
||||
-->
|
||||
查看输出是否成功，以验证是否成功创建服务：
|
||||
|
||||
service "redis-master" created
|
||||
|
||||
<!--
|
||||
Check the service created:
|
||||
-->
|
||||
检查服务是否创建：
|
||||
|
||||
kubectl get svc | grep redis
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
redis-master ClusterIP 10.0.0.213 <none> 6379/TCP 27s
|
||||
|
||||
<!--
|
||||
3. Verify that the Redis server is running in the pod and listening on port 6379:
|
||||
-->
|
||||
3. 验证 Redis 服务是否运行在 pod 中并且监听 6379 端口：
|
||||
|
||||
|
||||
kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
|
||||
|
||||
<!--
|
||||
The output displays the port:
|
||||
-->
|
||||
输出应该显示端口：
|
||||
|
||||
6379
|
||||
|
||||
|
||||
<!--
|
||||
## Forward a local port to a port on the pod
|
||||
|
||||
1. `kubectl port-forward` allows using resource name, such as a service name, to select a matching pod to port forward to since Kubernetes v1.10.
|
||||
-->
|
||||
## 转发一个本地端口到 pod 端口
|
||||
|
||||
1. 从 Kubernetes v1.10 开始，`kubectl port-forward` 允许使用资源名称（例如服务名称）来选择匹配的 pod 来进行端口转发。
|
||||
|
||||
kubectl port-forward redis-master-765d459796-258hz 6379:6379
|
||||
|
||||
<!--
|
||||
which is the same as
|
||||
-->
|
||||
这相当于
|
||||
|
||||
kubectl port-forward pods/redis-master-765d459796-258hz 6379:6379
|
||||
|
||||
<!--
|
||||
or
|
||||
-->
|
||||
或者
|
||||
|
||||
kubectl port-forward deployment/redis-master 6379:6379
|
||||
|
||||
<!--
|
||||
or
|
||||
-->
|
||||
或者
|
||||
|
||||
kubectl port-forward rs/redis-master 6379:6379
|
||||
|
||||
<!--
|
||||
or
|
||||
-->
|
||||
或者
|
||||
|
||||
kubectl port-forward svc/redis-master 6379:6379
|
||||
|
||||
<!--
|
||||
Any of the above commands works. The output is similar to this:
|
||||
-->
|
||||
以上所有命令都应该有效。输出应该类似于：
|
||||
|
||||
I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
|
||||
I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379
|
||||
|
||||
<!--
|
||||
2. Start the Redis command line interface:
|
||||
-->
|
||||
2. 启动 Redis 命令行接口：
|
||||
|
||||
redis-cli
|
||||
|
||||
<!--
|
||||
3. At the Redis command line prompt, enter the `ping` command:
|
||||
-->
|
||||
3. 在 Redis 命令行提示符下，输入 `ping` 命令：
|
||||
|
||||
127.0.0.1:6379>ping
|
||||
|
||||
<!--
|
||||
A successful ping request returns PONG.
|
||||
-->
|
||||
成功的 ping 请求应该返回 PONG。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
<!--
|
||||
## Discussion
|
||||
|
||||
Connections made to local port 6379 are forwarded to port 6379 of the pod that
|
||||
is running the Redis server. With this connection in place you can use your
|
||||
local workstation to debug the database that is running in the pod.
|
||||
-->
|
||||
## 讨论
|
||||
|
||||
与本地 6379 端口建立的连接将转发到运行 Redis 服务器的 pod 的 6379 端口。通过此连接，您可以使用本地工作站来调试在 pod 中运行的数据库。
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
**Warning**: Due to known limitations, port forward today only works for TCP protocol.
|
||||
The support to UDP protocol is being tracked in
|
||||
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
|
||||
-->
|
||||
**警告：** 由于已知的限制，目前的端口转发仅适用于 TCP 协议。
|
||||
在 [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862) 中正在跟踪对 UDP 协议的支持。
|
||||
{{< /warning >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward).
|
||||
-->
|
||||
学习更多关于 [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)。
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
labels:
|
||||
name: redis
|
||||
redis-sentinel: "true"
|
||||
role: master
|
||||
name: redis-master
|
||||
spec:
|
||||
containers:
|
||||
- name: master
|
||||
image: k8s.gcr.io/redis:v1
|
||||
env:
|
||||
- name: MASTER
|
||||
value: "true"
|
||||
ports:
|
||||
- containerPort: 6379
|
||||
resources:
|
||||
limits:
|
||||
cpu: "0.1"
|
||||
volumeMounts:
|
||||
- mountPath: /redis-master-data
|
||||
name: data
|
||||
- name: sentinel
|
||||
image: kubernetes/redis:v1
|
||||
env:
|
||||
- name: SENTINEL
|
||||
value: "true"
|
||||
ports:
|
||||
- containerPort: 26379
|
||||
volumes:
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
+225
@@ -0,0 +1,225 @@
|
||||
<!--
|
||||
---
|
||||
title: Use a Service to Access an Application in a Cluster
|
||||
content_template: templates/tutorial
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
---
|
||||
title: 使用服务来访问集群中的应用
|
||||
content_template: templates/tutorial
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to create a Kubernetes Service object that external
|
||||
clients can use to access an application running in a cluster. The Service
|
||||
provides load balancing for an application that has two running instances.
|
||||
-->
|
||||
本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。该服务为一个应用的两个运行实例提供负载均衡。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
<!--
|
||||
* Run two instances of a Hello World application.
|
||||
* Create a Service object that exposes a node port.
|
||||
* Use the Service object to access the running application.
|
||||
-->
|
||||
* 运行 Hello World 应用的两个实例。
|
||||
* 创建一个服务对象来暴露一个 node port。
|
||||
* 使用服务对象来访问正在运行的应用。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
<!--
|
||||
## Creating a service for an application running in two pods
|
||||
|
||||
1. Run a Hello World application in your cluster:
|
||||
-->
|
||||
## 为运行在两个 pod 中的应用创建一个服务：
|
||||
|
||||
1. 在您的集群中运行一个 Hello World 应用：
|
||||
```shell
|
||||
kubectl run hello-world --replicas=2 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
<!--
|
||||
The preceding command creates a
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
object and an associated
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
object. The ReplicaSet has two
|
||||
[Pods](/docs/concepts/workloads/pods/pod/),
|
||||
each of which runs the Hello World application.
|
||||
-->
|
||||
上面的命令创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) 对象和一个关联的 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 对象。这个 ReplicaSet 有两个 [Pod](/docs/concepts/workloads/pods/pod/)，每个 Pod 都运行着 Hello World 应用。
|
||||
|
||||
<!--
|
||||
1. Display information about the Deployment:
|
||||
-->
|
||||
1. 展示 Deployment 的信息：
|
||||
```shell
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Display information about your ReplicaSet objects:
|
||||
-->
|
||||
1. 展示您的 ReplicaSet 对象信息：
|
||||
```shell
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Create a Service object that exposes the deployment:
|
||||
-->
|
||||
1. 创建一个服务对象来暴露 deployment：
|
||||
```shell
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Display information about the Service:
|
||||
-->
|
||||
1. 展示服务信息：
|
||||
```shell
|
||||
kubectl describe services example-service
|
||||
```
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
```shell
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: run=load-balancer-example
|
||||
Annotations: <none>
|
||||
Selector: run=load-balancer-example
|
||||
Type: NodePort
|
||||
IP: 10.32.0.16
|
||||
Port: <unset> 8080/TCP
|
||||
TargetPort: 8080/TCP
|
||||
NodePort: <unset> 31496/TCP
|
||||
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
|
||||
Session Affinity: None
|
||||
Events: <none>
|
||||
```
|
||||
<!--
|
||||
Make a note of the NodePort value for the service. For example,
|
||||
in the preceding output, the NodePort value is 31496.
|
||||
-->
|
||||
注意服务中的 NodePort 值。例如在上面的输出中，NodePort 是 31496。
|
||||
|
||||
<!--
|
||||
1. List the pods that are running the Hello World application:
|
||||
-->
|
||||
1. 列出运行 Hello World 应用的 pod：
|
||||
```shell
|
||||
kubectl get pods --selector="run=load-balancer-example" --output=wide
|
||||
```
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
```shell
|
||||
NAME READY STATUS ... IP NODE
|
||||
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
|
||||
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
|
||||
```
|
||||
<!--
|
||||
1. Get the public IP address of one of your nodes that is running
|
||||
a Hello World pod. How you get this address depends on how you set
|
||||
up your cluster. For example, if you are using Minikube, you can
|
||||
see the node address by running `kubectl cluster-info`. If you are
|
||||
using Google Compute Engine instances, you can use the
|
||||
`gcloud compute instances list` command to see the public addresses of your
|
||||
nodes.
|
||||
|
||||
1. On your chosen node, create a firewall rule that allows TCP traffic
|
||||
on your node port. For example, if your Service has a NodePort value of
|
||||
31568, create a firewall rule that allows TCP traffic on port 31568. Different
|
||||
cloud providers offer different ways of configuring firewall rules.
|
||||
|
||||
1. Use the node address and node port to access the Hello World application:
|
||||
-->
|
||||
1. 获取运行 Hello World 的 pod 的其中一个节点的公共 IP 地址。如何获得此地址取决于您设置集群的方式。
|
||||
例如，如果您使用的是 Minikube，则可以通过运行 `kubectl cluster-info` 来查看节点地址。
|
||||
如果您使用的是 Google Compute Engine 实例，则可以使用 `gcloud compute instances list` 命令查看节点的公共地址。
|
||||
|
||||
1. 在您选择的节点上，创建一个防火墙规则以开放 node port 上的 TCP 流量。
|
||||
例如，如果您的服务的 NodePort 值为 31568，请创建一个防火墙规则以允许 31568 端口上的 TCP 流量。
|
||||
不同的云提供商提供了不同方法来配置防火墙规则。
|
||||
|
||||
1. 使用节点地址和 node port 来访问 Hello World 应用：
|
||||
```shell
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
```
|
||||
<!--
|
||||
where `<public-node-ip>` is the public IP address of your node,
|
||||
and `<node-port>` is the NodePort value for your service. The
|
||||
response to a successful request is a hello message:
|
||||
-->
|
||||
这里的 `<public-node-ip>` 是您节点的公共 IP 地址，`<node-port>` 是您服务的 NodePort 值。
|
||||
对于请求成功的响应是一个 hello 消息：
|
||||
```shell
|
||||
Hello Kubernetes!
|
||||
```
|
||||
|
||||
<!--
|
||||
## Using a service configuration file
|
||||
|
||||
As an alternative to using `kubectl expose`, you can use a
|
||||
[service configuration file](/docs/concepts/services-networking/service/)
|
||||
to create a Service.
|
||||
-->
|
||||
## 使用服务配置文件
|
||||
|
||||
作为 `kubectl expose` 的替代方法，您可以使用 [服务配置文件](/docs/concepts/services-networking/service/) 来创建服务。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture cleanup %}}
|
||||
|
||||
<!--
|
||||
To delete the Service, enter this command:
|
||||
-->
|
||||
想要删除服务，输入以下命令：
|
||||
|
||||
kubectl delete services example-service
|
||||
|
||||
<!--
|
||||
To delete the Deployment, the ReplicaSet, and the Pods that are running
|
||||
the Hello World application, enter this command:
|
||||
-->
|
||||
想要删除运行 Hello World 应用的 Deployment、ReplicaSet 和 Pod，输入以下命令：
|
||||
|
||||
kubectl delete deployment hello-world
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
Learn more about
|
||||
[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
|
||||
-->
|
||||
学习更多关于如何 [通过服务连接应用](/docs/concepts/services-networking/connect-applications-service/)。
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,27 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: two-containers
|
||||
spec:
|
||||
|
||||
restartPolicy: Never
|
||||
|
||||
volumes:
|
||||
- name: shared-data
|
||||
emptyDir: {}
|
||||
|
||||
containers:
|
||||
|
||||
- name: nginx-container
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- name: shared-data
|
||||
mountPath: /usr/share/nginx/html
|
||||
|
||||
- name: debian-container
|
||||
image: debian
|
||||
volumeMounts:
|
||||
- name: shared-data
|
||||
mountPath: /pod-data
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]
|
||||
Reference in New Issue
Block a user