Merge branch 'fix-typos' into master
This commit is contained in:
@@ -75,7 +75,7 @@ apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: hello-world
|
||||
spec: # specification of the pod’s contents
|
||||
spec: # specification of the pod's contents
|
||||
restartPolicy: Never
|
||||
containers:
|
||||
- name: hello
|
||||
|
||||
@@ -181,7 +181,7 @@ default-token-il9rc kubernetes.io/service-account-token 1
|
||||
nginxsecret Opaque 2
|
||||
```
|
||||
|
||||
Now modify your nginx replicas to start a https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
|
||||
Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
|
||||
|
||||
{% include code.html language="yaml" file="nginx-secure-app.yaml" ghlink="/docs/user-guide/nginx-secure-app" %}
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ class RedisWQ(object):
|
||||
# Record that we (this session id) are working on a key. Expire that
|
||||
# note after the lease timeout.
|
||||
# Note: if we crash at this line of the program, then GC will see no lease
|
||||
# for this item an later return it to the main queue.
|
||||
# for this item a later return it to the main queue.
|
||||
itemkey = self._itemkey(item)
|
||||
self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session)
|
||||
return item
|
||||
|
||||
@@ -93,7 +93,7 @@ Due to the implementation of this feature, the source IP for sessions as seen in
|
||||
that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases.
|
||||
|
||||
## Annotation to modify the LoadBalancer behavior for preservation of Source IP
|
||||
In 1.5, an Beta feature has been added that changes the behavior of the external LoadBalancer feature.
|
||||
In 1.5, a Beta feature has been added that changes the behavior of the external LoadBalancer feature.
|
||||
|
||||
This feature can be activated by adding the beta annotation below to the metadata section of the Service Configuration file.
|
||||
|
||||
|
||||
@@ -396,7 +396,7 @@ spec:
|
||||
|
||||
The patch is specified using json.
|
||||
|
||||
The system ensures that you don’t clobber changes made by other users or components by confirming that the `resourceVersion` doesn’t differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don’t use your original configuration file as the source since additional fields most likely were set in the live state.
|
||||
The system ensures that you don't clobber changes made by other users or components by confirming that the `resourceVersion` doesn't differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don't use your original configuration file as the source since additional fields most likely were set in the live state.
|
||||
|
||||
For more information, please see [kubectl patch](/docs/user-guide/kubectl/kubectl_patch/) document.
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ Only use PetSet if your application requires some or all of these properties. Ma
|
||||
|
||||
Example workloads for PetSet:
|
||||
|
||||
* Databases like MySQL or PostgreSQL that require a single instance attached to a NFS persistent volume at any time
|
||||
* Databases like MySQL or PostgreSQL that require a single instance attached to an NFS persistent volume at any time
|
||||
* Clustered software like Zookeeper, Etcd, or Elasticsearch that require stable membership.
|
||||
|
||||
## Alpha limitations
|
||||
|
||||
@@ -26,7 +26,7 @@ administrator to control the following:
|
||||
1. The SELinux context of the container.
|
||||
1. The user ID.
|
||||
1. The use of host namespaces and networking.
|
||||
1. Allocating an FSGroup that owns the pod’s volumes
|
||||
1. Allocating an FSGroup that owns the pod's volumes
|
||||
1. Configuring allowable supplemental groups
|
||||
1. Requiring the use of a read only root file system
|
||||
1. Controlling the usage of volume types
|
||||
|
||||
@@ -105,7 +105,7 @@ If the pod is [restarted](#pod-restart-reasons) all init containers must
|
||||
execute again.
|
||||
|
||||
Changes to the init container spec are limited to the container image field.
|
||||
Altering a init container image field is equivalent to restarting the pod.
|
||||
Altering an init container image field is equivalent to restarting the pod.
|
||||
|
||||
Because init containers can be restarted, retried, or reexecuted, init container
|
||||
code should be idempotent. In particular, code that writes to files on EmptyDirs
|
||||
|
||||
@@ -5,7 +5,7 @@ assignees:
|
||||
title: Installing and Setting up kubectl
|
||||
---
|
||||
|
||||
To deploy and manage applications on Kubernetes, you’ll use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.
|
||||
To deploy and manage applications on Kubernetes, you'll use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.
|
||||
|
||||
## Install kubectl Binary Via curl
|
||||
|
||||
|
||||
@@ -37,6 +37,7 @@ their ReplicaSets.
|
||||
|
||||
A ReplicaSet ensures that a specified number of pod “replicas” are running at any given
|
||||
time. However, a Deployment is a higher-level concept that manages ReplicaSets and
|
||||
|
||||
provides declarative updates to pods along with a lot of other useful features.
|
||||
Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless
|
||||
you require custom update orchestration or don't require updates at all.
|
||||
|
||||
@@ -236,6 +236,7 @@ object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
|
||||
It’s mainly used by [`Deployment`](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates.
|
||||
Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.
|
||||
|
||||
|
||||
### Deployment (Recommended)
|
||||
|
||||
[`Deployment`](/docs/user-guide/deployments/) is a higher-level API object that updates its underlying Replica Sets and their Pods
|
||||
|
||||
@@ -20,7 +20,7 @@ metadata:
|
||||
name: hello-world
|
||||
spec:
|
||||
containers:
|
||||
# specification of the pod’s containers
|
||||
# specification of the pod's containers
|
||||
# ...
|
||||
securityContext:
|
||||
fsGroup: 1234
|
||||
@@ -85,4 +85,3 @@ Please refer to the
|
||||
[API documentation](/docs/api-reference/v1/definitions/#_v1_securitycontext)
|
||||
for a detailed listing and description of all the fields available
|
||||
within the container security context.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user