Modify the terms by document style (#7026)
Bin Liu
k8s-ci-robot
parent
fb3f73e6f6
commit
1a7f7a869e
|
|
@ -125,7 +125,7 @@ The traffic will be routed to endpoints defined by the user (`1.2.3.4:9376` in
|
|||
this example).
|
||||
|
||||
An ExternalName service is a special case of service that does not have
|
||||
selectors. It does not define any ports or endpoints. Rather, it serves as a
|
||||
selectors. It does not define any ports or Endpoints. Rather, it serves as a
|
||||
way to return an alias to an external service residing outside the cluster.
|
||||
|
||||
```yaml
|
||||
|
|
@ -196,11 +196,11 @@ Note that in the above diagram, `clusterIP` is shown as `ServiceIP`.
|
|||
|
||||
{% assign for_k8s_version="v1.9" %}{% include feature-state-beta.md %}
|
||||
|
||||
In this mode, kube-proxy watches Kubernetes `services` and `endpoints`,
|
||||
In this mode, kube-proxy watches Kubernetes Services and Endpoints,
|
||||
calls `netlink` interface to create ipvs rules accordingly and syncs ipvs rules with Kubernetes
|
||||
`services` and `endpoints` periodically, to make sure ipvs status is
|
||||
consistent with the expectation. When `service` is accessed, traffic will
|
||||
be redirected to one of the backend `pod`s.
|
||||
Services and Endpoints periodically, to make sure ipvs status is
|
||||
consistent with the expectation. When Service is accessed, traffic will
|
||||
be redirected to one of the backend Pods.
|
||||
|
||||
Similar to iptables, Ipvs is based on netfilter hook function, but uses hash
|
||||
table as the underlying data structure and works in the kernel space.
|
||||
|
|
@ -208,12 +208,12 @@ That means ipvs redirects traffic much faster, and has much
|
|||
better performance when syncing proxy rules. Furthermore, ipvs provides more
|
||||
options for load balancing algorithm, such as:
|
||||
|
||||
- rr: round-robin
|
||||
- lc: least connection
|
||||
- dh: destination hashing
|
||||
- sh: source hashing
|
||||
- sed: shortest expected delay
|
||||
- nq: never queue
|
||||
- `rr`: round-robin
|
||||
- `lc`: least connection
|
||||
- `dh`: destination hashing
|
||||
- `sh`: source hashing
|
||||
- `sed`: shortest expected delay
|
||||
- `nq`: never queue
|
||||
|
||||
**Note:** ipvs mode assumes IPVS kernel modules are installed on the node
|
||||
before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
|
||||
|
|
@ -385,7 +385,7 @@ The default is `ClusterIP`.
|
|||
makes the service only reachable from within the cluster. This is the
|
||||
default `ServiceType`.
|
||||
* `NodePort`: Exposes the service on each Node's IP at a static port (the `NodePort`).
|
||||
A `ClusterIP` service, to which the NodePort service will route, is automatically
|
||||
A `ClusterIP` service, to which the `NodePort` service will route, is automatically
|
||||
created. You'll be able to contact the `NodePort` service, from outside the cluster,
|
||||
by requesting `<NodeIP>:<NodePort>`.
|
||||
* `LoadBalancer`: Exposes the service externally using a cloud provider's load balancer.
|
||||
|
|
@ -451,7 +451,7 @@ with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not s
|
|||
an ephemeral IP will be assigned to the loadBalancer. If the `loadBalancerIP` is specified, but the
|
||||
cloud provider does not support the feature, the field will be ignored.
|
||||
|
||||
Special notes for Azure: To use user-specified public type `loadBalancerIP`, a static type
|
||||
**Special notes for Azure**: To use user-specified public type `loadBalancerIP`, a static type
|
||||
public IP address resource needs to be created first, and it should be in the same resource
|
||||
group of the cluster. Then you could specify the assigned IP address as `loadBalancerIP`.
|
||||
|
||||
|
|
@ -667,8 +667,8 @@ If there are external IPs that route to one or more cluster nodes, Kubernetes se
|
|||
will be routed to one of the service endpoints. `externalIPs` are not managed by Kubernetes and are the responsibility
|
||||
of the cluster administrator.
|
||||
|
||||
In the ServiceSpec, `externalIPs` can be specified along with any of the `ServiceTypes`.
|
||||
In the example below, my-service can be accessed by clients on 80.11.12.10:80 (externalIP:port)
|
||||
In the `ServiceSpec`, `externalIPs` can be specified along with any of the `ServiceTypes`.
|
||||
In the example below, "`my-service`" can be accessed by clients on "`80.11.12.10:80`"" (`externalIP:port`)
|
||||
|
||||
```yaml
|
||||
kind: Service
|
||||
|
|
|
|||
|
|
@ -68,13 +68,14 @@ Claims will remain unbound indefinitely if a matching volume does not exist. Cla
|
|||
|
||||
Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For volumes which support multiple access modes, the user specifies which mode desired when using their claim as a volume in a pod.
|
||||
|
||||
Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a persistentVolumeClaim in their Pod's volumes block. [See below for syntax details](#claims-as-volumes).
|
||||
Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it. Users schedule Pods and access their claimed PVs by including a `persistentVolumeClaim` in their Pod's volumes block. [See below for syntax details](#claims-as-volumes).
|
||||
|
||||
### Persistent Volume Claim Protection
|
||||
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
|
||||
The purpose of the PVC protection is to ensure that PVCs in active use by a pod are not removed from the system as this may result in data loss.
|
||||
|
||||
Note: PVC is in active use by a pod when the the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
|
||||
**Note:** PVC is in active use by a pod when the the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
|
||||
{: .note}
|
||||
|
||||
When the [PVC protection alpha feature](/docs/tasks/administer-cluster/pvc-protection/) is enabled, if a user deletes a PVC in active use by a pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any pods.
|
||||
|
||||
|
|
@ -211,7 +212,7 @@ resizing to take place. Also, file system resizing is only supported for followi
|
|||
* ScaleIO Volumes
|
||||
* StorageOS
|
||||
|
||||
** Raw Block Support exists for these plugins only.
|
||||
Raw Block Support exists for these plugins only.
|
||||
|
||||
## Persistent Volumes
|
||||
|
||||
|
|
@ -246,7 +247,7 @@ Currently, storage size is the only resource that can be set or requested. Futu
|
|||
|
||||
### Volume Mode
|
||||
|
||||
Prior to v1.9, the default behavior for all volume plugins was to create a filesystem on the persistent volume. With v1.9, the user can specify a volumeMode which will now support raw block devices in addition to file systems. Valid values for volumeMode are "Filesystem" or "Block". If left unspecified, volumeMode defaults to "Filesystem" internally. This is an optional API parameter.
|
||||
Prior to v1.9, the default behavior for all volume plugins was to create a filesystem on the persistent volume. With v1.9, the user can specify a `volumeMode` which will now support raw block devices in addition to file systems. Valid values for `volumeMode` are "Filesystem" or "Block". If left unspecified, `volumeMode` defaults to "Filesystem" internally. This is an optional API parameter.
|
||||
|
||||
**Note:** This feature is alpha in v1.9 and may change in the future.
|
||||
{: .note}
|
||||
|
|
@ -396,8 +397,8 @@ Claims, like pods, can request specific quantities of a resource. In this case,
|
|||
|
||||
Claims can specify a [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) to further filter the set of volumes. Only the volumes whose labels match the selector can be bound to the claim. The selector can consist of two fields:
|
||||
|
||||
* matchLabels - the volume must have a label with this value
|
||||
* matchExpressions - a list of requirements made by specifying key, list of values, and operator that relates the key and values. Valid operators include In, NotIn, Exists, and DoesNotExist.
|
||||
* `matchLabels` - the volume must have a label with this value
|
||||
* `matchExpressions` - a list of requirements made by specifying key, list of values, and operator that relates the key and values. Valid operators include In, NotIn, Exists, and DoesNotExist.
|
||||
|
||||
All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together – they must all be satisfied in order to match.
|
||||
|
||||
|
|
@ -532,7 +533,7 @@ spec:
|
|||
|
||||
### Binding Block Volumes
|
||||
|
||||
If a user requests a raw block volume by indicating this using the volumeMode field in the PersistentVolumeClaim spec, the binding rules differ slighty from previous releases that didn't consider this mode as part of the spec.
|
||||
If a user requests a raw block volume by indicating this using the `volumeMode` field in the `PersistentVolumeClaim` spec, the binding rules differ slighty from previous releases that didn't consider this mode as part of the spec.
|
||||
Listed is a table of possible combinations the user and admin might specify for requesting a raw block device. The table indicates if the volume will be bound or not given the combinations:
|
||||
Volume binding matrix for statically provisioned volumes:
|
||||
|
||||
|
|
|
|||
|
|
@ -205,9 +205,9 @@ parameters:
|
|||
a mandatory parameter for GlusterFS dynamic provisioner. If Heketi service is
|
||||
exposed as a routable service in openshift/kubernetes setup, this can have a
|
||||
format similar to `http://heketi-storage-project.cloudapps.mystorage.com`
|
||||
where the fqdn is a resolvable heketi service url.
|
||||
where the fqdn is a resolvable Heketi service url.
|
||||
* `restauthenabled` : Gluster REST service authentication boolean that enables
|
||||
authentication to the REST server. If this value is 'true', `restuser` and
|
||||
authentication to the REST server. If this value is `"true"`, `restuser` and
|
||||
`restuserkey` or `secretNamespace` + `secretName` have to be filled. This
|
||||
option is deprecated, authentication is enabled when any of `restuser`,
|
||||
`restuserkey`, `secretName` or `secretNamespace` is specified.
|
||||
|
|
@ -220,7 +220,7 @@ parameters:
|
|||
contains user password to use when talking to Gluster REST service. These
|
||||
parameters are optional, empty password will be used when both
|
||||
`secretNamespace` and `secretName` are omitted. The provided secret must have
|
||||
type "kubernetes.io/glusterfs", e.g. created in this way:
|
||||
type `"kubernetes.io/glusterfs"`, e.g. created in this way:
|
||||
```
|
||||
kubectl create secret generic heketi-secret \
|
||||
--type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ between pods.
|
|||
**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
|
||||
{: .caution}
|
||||
|
||||
There are some restrictions when using an awsElasticBlockStore volume:
|
||||
There are some restrictions when using an `awsElasticBlockStore` volume:
|
||||
|
||||
* the nodes on which pods are running must be AWS EC2 instances
|
||||
* those instances need to be in the same region and availability-zone as the EBS volume
|
||||
|
|
@ -432,8 +432,8 @@ For example, some uses for a `hostPath` are:
|
|||
|
||||
* running a container that needs access to Docker internals; use a `hostPath`
|
||||
of `/var/lib/docker`
|
||||
* running cAdvisor in a container; use a `hostPath` of `/dev/cgroups`
|
||||
* allowing a pod to specify whether a given hostPath should exist prior to the
|
||||
* running cAdvisor in a container; use a `hostPath` of `/sys`
|
||||
* allowing a pod to specify whether a given `hostPath` should exist prior to the
|
||||
pod running, whether it should be created, and what it should exist as
|
||||
|
||||
In addition to the required `path` property, user can optionally specify a `type` for a `hostPath` volume.
|
||||
|
|
@ -520,7 +520,7 @@ partition or directory.
|
|||
|
||||
Local volumes can only be used as a statically created PersistentVolume.
|
||||
|
||||
Compared to HostPath volumes, local volumes can be used in a durable manner
|
||||
Compared to `hostPath` volumes, local volumes can be used in a durable manner
|
||||
without manually scheduling pods to nodes, as the system is aware of the volume's
|
||||
node constraints by looking at the node affinity on the PersistentVolume.
|
||||
|
||||
|
|
@ -1020,8 +1020,8 @@ When enabled, the `volumeMounts` field of a Container has a new
|
|||
In addition, all volume mounts created by the Container will be propagated
|
||||
back to the host and to all Containers of all Pods that use the same volume.
|
||||
|
||||
A typical use case for this mode is a Pod with a Flex volume driver or
|
||||
a Pod that needs to mount something on the host using a HostPath volume.
|
||||
A typical use case for this mode is a Pod with a `FlexVolume` driver or
|
||||
a Pod that needs to mount something on the host using a `hostPath` volume.
|
||||
|
||||
This mode is equal to `rshared` mount propagation as described in the
|
||||
[Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
|
||||
|
|
|
|||
Loading…
Reference in New Issue