From 4344516509bc34af0b373645e39ddb436e3bbc7f Mon Sep 17 00:00:00 2001 From: lovejoy Date: Fri, 8 Jun 2018 02:45:23 +0800 Subject: [PATCH] fix again (#8941) --- .../cluster-administration/networking.md | 2 +- .../en/docs/concepts/configuration/secret.md | 12 +++++----- .../docs/concepts/policy/resource-quotas.md | 6 ++--- .../concepts/services-networking/service.md | 24 +++++++++---------- content/en/docs/concepts/storage/volumes.md | 4 ++-- .../workloads/controllers/deployment.md | 2 +- 6 files changed, 25 insertions(+), 25 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 18d5e1e518..d6c091302f 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -172,7 +172,7 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" ``` This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet` -flag) according to the `Node`'s `spec.podCIDR`. +flag) according to the `Node`'s `.spec.podCIDR`. Docker will now allocate IPs from the `cbr-cidr` block. Containers can reach each other and `Nodes` over the `cbr0` bridge. Those IPs are all routable diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index cc16460018..f87ca2c96f 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -174,8 +174,8 @@ systems on your behalf. To consume a Secret in a volume in a Pod: 1. Create a secret or use an existing one. Multiple pods can reference the same secret. -1. Modify your Pod definition to add a volume under `spec.volumes[]`. Name the volume anything, and have a `spec.volumes[].secret.secretName` field equal to the name of the secret object. -1. Add a `spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `spec.containers[].volumeMounts[].readOnly = true` and `spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear. +1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].secret.secretName` field equal to the name of the secret object. +1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear. 1. Modify your image and/or command line so that the program looks for files in that directory. Each key in the secret `data` map becomes the filename under `mountPath`. This is an example of a pod that mounts a secret in a volume: @@ -199,17 +199,17 @@ spec: secretName: mysecret ``` -Each secret you want to use needs to be referred to in `spec.volumes`. +Each secret you want to use needs to be referred to in `.spec.volumes`. If there are multiple containers in the pod, then each container needs its -own `volumeMounts` block, but only one `spec.volumes` is needed per secret. +own `volumeMounts` block, but only one `.spec.volumes` is needed per secret. You can package many files into one secret, or use many secrets, whichever is convenient. **Projection of secret keys to specific paths** We can also control the paths within the volume where Secret keys are projected. -You can use `spec.volumes[].secret.items` field to change target path of each key: +You can use `.spec.volumes[].secret.items` field to change target path of each key: ```yaml apiVersion: v1 @@ -238,7 +238,7 @@ What will happen: * `username` secret is stored under `/etc/foo/my-group/my-username` file instead of `/etc/foo/username`. * `password` secret is not projected -If `spec.volumes[].secret.items` is used, only keys specified in `items` are projected. +If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected. To consume all keys from the secret, all of them must be listed in the `items` field. All listed keys must exist in the corresponding secret. Otherwise, the volume is not created. diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 1d125e7430..2d69664bcb 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -143,7 +143,7 @@ The following types are supported: | ------------------------------- | ------------------------------------------------- | | `configmaps` | The total number of config maps that can exist in the namespace. | | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | -| `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `status.phase in (Failed, Succeeded)` is true. | +| `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true. | | `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. | | `resourcequotas` | The total number of [resource quotas](/docs/admin/admission-controllers/#resourcequota) that can exist in the namespace. | | `services` | The total number of services that can exist in the namespace. | @@ -166,8 +166,8 @@ Resources specified on the quota outside of the allowed set results in a validat | Scope | Description | | ----- | ----------- | -| `Terminating` | Match pods where `spec.activeDeadlineSeconds >= 0` | -| `NotTerminating` | Match pods where `spec.activeDeadlineSeconds is nil` | +| `Terminating` | Match pods where `.spec.activeDeadlineSeconds >= 0` | +| `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` | | `BestEffort` | Match pods that have best effort quality of service. | | `NotBestEffort` | Match pods that do not have best effort quality of service. | diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index b08a72210a..ab05f78c26 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -263,7 +263,7 @@ spec: ## Choosing your own IP address You can specify your own cluster IP address as part of a `Service` creation -request. To do this, set the `spec.clusterIP` field. For example, if you +request. To do this, set the `.spec.clusterIP` field. For example, if you already have an existing DNS entry that you wish to replace, or legacy systems that are configured for a specific IP address and difficult to re-configure. The IP address that a user chooses must be a valid IP address and within the @@ -345,7 +345,7 @@ The Kubernetes DNS server is the only way to access services of type Sometimes you don't need or want load-balancing and a single service IP. In this case, you can create "headless" services by specifying `"None"` for the -cluster IP (`spec.clusterIP`). +cluster IP (`.spec.clusterIP`). This option allows developers to reduce coupling to the Kubernetes system by allowing them freedom to do discovery their own way. Applications can still use @@ -404,7 +404,7 @@ The default is `ClusterIP`. If you set the `type` field to `NodePort`, the Kubernetes master will allocate a port from a flag-configured range (default: 30000-32767), and each Node will proxy that port (the same port number on every Node) into your `Service`. -That port will be reported in your `Service`'s `spec.ports[*].nodePort` field. +That port will be reported in your `Service`'s `.spec.ports[*].nodePort` field. If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s) (which is supported since Kubernetes v1.10). A comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 1.2.3.4/32) is used to filter addresses local to this node. For example, if you start kube-proxy with flag `--nodeport-addresses=127.0.0.0/8`, kube-proxy will select only the loopback interface for NodePort Services. The `--nodeport-addresses` is defaulted to empty (`[]`), which means select all available interfaces and is in compliance with current NodePort behaviors. @@ -418,7 +418,7 @@ configure environments that are not fully supported by Kubernetes, or even to just expose one or more nodes' IPs directly. Note that this Service will be visible as both `:spec.ports[*].nodePort` -and `spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, would be filtered NodeIP(s).) +and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, would be filtered NodeIP(s).) ### Type LoadBalancer @@ -426,7 +426,7 @@ On cloud providers which support external load balancers, setting the `type` field to `LoadBalancer` will provision a load balancer for your `Service`. The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer will be published in the `Service`'s -`status.loadBalancer` field. For example: +`.status.loadBalancer` field. For example: ```yaml kind: Service @@ -704,15 +704,15 @@ with the value set to `nlb`. ``` Unlike Classic Elastic Load Balancers, Network Load Balancers (NLBs) forward the -client's IP through to the node. If a service's `spec.externalTrafficPolicy` is +client's IP through to the node. If a service's `.spec.externalTrafficPolicy` is set to `Cluster`, the client's IP address will not be propagated to the end pods. -By setting `spec.externalTrafficPolicy` to `Local`, client IP addresses will be +By setting `.spec.externalTrafficPolicy` to `Local`, client IP addresses will be propagated to the end pods, but this could result in uneven distribution of traffic. Nodes without any pods for a particular LoadBalancer service will fail the NLB Target Group's health check on the auto-assigned -`spec.healthCheckNodePort` and not receive any traffic. +`.spec.healthCheckNodePort` and not receive any traffic. In order to achieve even traffic, either use a DaemonSet, or specify a [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) @@ -726,11 +726,11 @@ groups are modified with the following IP rules: | Rule | Protocol | Port(s) | IpRange(s) | IpRange Description | |------|----------|---------|------------|---------------------| -| Health Check | TCP | NodePort(s) (`spec.healthCheckNodePort` for `spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\ | -| Client Traffic | TCP | NodePort(s) | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\ | -| MTU Discovery | ICMP | 3,4 | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\ | +| Health Check | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\ | +| Client Traffic | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\ | +| MTU Discovery | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\ | -Be aware that if `spec.loadBalancerSourceRanges` is not set, Kubernetes will +Be aware that if `.spec.loadBalancerSourceRanges` is not set, Kubernetes will allow traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have public IP addresses, be aware that non-NLB traffic can also reach all instances in those modified security groups. diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 8fb4afcb52..6c6499fcc2 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -50,9 +50,9 @@ medium that backs it, and the contents of it are determined by the particular volume type used. To use a volume, a Pod specifies what volumes to provide for the Pod (the -`spec.volumes` +`.spec.volumes` field) and where to mount those into Containers (the -`spec.containers.volumeMounts` +`.spec.containers.volumeMounts` field). A process in a container sees a filesystem view composed from their Docker diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index ce6405b87e..70fa58b4db 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -715,7 +715,7 @@ $ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSecond deployment "nginx-deployment" patched ``` Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following -attributes to the Deployment's `status.conditions`: +attributes to the Deployment's `.status.conditions`: * Type=Progressing * Status=False