From 383e40f978334792e7ca30399845c9bf38ea813c Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 11:24:05 +0800 Subject: [PATCH 1/5] fix a series punctuation errors --- LICENSE | 2 +- case-studies/index.html | 4 ++-- case-studies/pearson.html | 10 +++++----- case-studies/wikimedia.html | 8 ++++---- docs/admin/admission-controllers.md | 4 ++-- docs/admin/rescheduler.md | 2 +- docs/getting-started-guides/windows/index.md | 6 +++--- docs/tutorials/kubernetes-basics/explore-intro.html | 2 +- docs/user-guide/replicasets.md | 2 +- 9 files changed, 20 insertions(+), 20 deletions(-) diff --git a/LICENSE b/LICENSE index 06c608dcf4..b6988e7edc 100644 --- a/LICENSE +++ b/LICENSE @@ -378,7 +378,7 @@ Section 8 -- Interpretation. Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances -will be considered the “Licensor.” The text of the Creative Commons +will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as diff --git a/case-studies/index.html b/case-studies/index.html index ce14542424..6d288a8bb2 100644 --- a/case-studies/index.html +++ b/case-studies/index.html @@ -17,13 +17,13 @@ title: Case Studies
Pearson -

“We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers’ productivity.”

+

"We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers’ productivity."

Read about Pearson
Wikimedia -

“With Kubernetes, we’re simplifying our environment and making it easier for developers to build the tools that make wikis run better.”

+

"With Kubernetes, we’re simplifying our environment and making it easier for developers to build the tools that make wikis run better."

Read about Wikimedia
diff --git a/case-studies/pearson.html b/case-studies/pearson.html index bf871789b9..5eecc6f349 100644 --- a/case-studies/pearson.html +++ b/case-studies/pearson.html @@ -19,7 +19,7 @@ title: Pearson Case Study
Pearson

- “To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers’ productivity.”

+ "To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers’ productivity."

— Chris Jackson, Director for Cloud Product Engineering, Pearson

@@ -63,9 +63,9 @@ title: Pearson Case Study

Kubernetes powers a comprehensive developer experience

-

Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, “Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it’s a great way for us to allow our team to express themselves and share the pride they have in their work.”

-

It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools.“

-

Kubernetes is at the core of the platform we’ve built for developers. After we get our big spike in back-to-school in traffic, much of Pearson’s traffic will interact with Kubernetes. It is proving to be as effective as we had hoped,” Jackson says.

+

Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, "Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it’s a great way for us to allow our team to express themselves and share the pride they have in their work."

+

It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools."

+

Kubernetes is at the core of the platform we’ve built for developers. After we get our big spike in back-to-school in traffic, much of Pearson’s traffic will interact with Kubernetes. It is proving to be as effective as we had hoped," Jackson says.

@@ -76,7 +76,7 @@ title: Pearson Case Study

Encouraging experimentation, saving engineers time

With the new platform, Pearson will increase stability and performance, and to bring products to market more quickly. The company says its engineers will also get a productivity boost because they won’t spend time managing infrastructure. Jackson estimates 15 to 20 percent in productivity savings.

Beyond that, Pearson says the platform will encourage innovation because of the ease with which new applications can be developed, and because applications will be deployed far more quickly than in the past. It expects that will help the company meet its goal of reaching 200 million learners within the next 10 years.

-

“We’re already seeing tremendous benefits with Kubernetes — improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online,” says Jackson.

+

"We’re already seeing tremendous benefits with Kubernetes — improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online," says Jackson.

diff --git a/case-studies/wikimedia.html b/case-studies/wikimedia.html index 00eb47e3e0..0dc910fbe4 100644 --- a/case-studies/wikimedia.html +++ b/case-studies/wikimedia.html @@ -20,7 +20,7 @@ title: Wikimedia Case Study
Wikimedia

- “Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it’s grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It’s like a big ball of mud — you really can’t see through it. With Kubernetes, we’re simplifying the environment and making it easier for developers to build the tools that make wikis run better.” + "Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it’s grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It’s like a big ball of mud — you really can’t see through it. With Kubernetes, we’re simplifying the environment and making it easier for developers to build the tools that make wikis run better."

— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs

@@ -67,13 +67,13 @@ title: Wikimedia Case Study

Using Kubernetes to provide tools for maintaining wikis

- Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, “It’s incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile.” + Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It’s incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."

To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.

- “With Kubernetes, I’ve been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users’ code also runs in a more stable way than previously,” says Yuvi. + "With Kubernetes, I’ve been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users’ code also runs in a more stable way than previously," says Yuvi.

@@ -90,7 +90,7 @@ title: Wikimedia Case Study In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs’ web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.

- “Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive,” says Yuvi. + "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.

diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 475f2e4be9..de544e3d8b 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -126,7 +126,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/ku When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. -Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). +Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). An example request body: @@ -151,7 +151,7 @@ An example request body: } ``` -The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s “spec” field is ignored and may be omitted. A permissive response would return: +The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s "spec" field is ignored and may be omitted. A permissive response would return: ``` { diff --git a/docs/admin/rescheduler.md b/docs/admin/rescheduler.md index c9a3bd074c..651fdf15b5 100644 --- a/docs/admin/rescheduler.md +++ b/docs/admin/rescheduler.md @@ -30,7 +30,7 @@ given the pods that are already running in the cluster the rescheduler tries to free up space for the add-on by evicting some pods; then the scheduler will schedule the add-on pod. To avoid situation when another pod is scheduled into the space prepared for the critical add-on, -the chosen node gets a temporary taint “CriticalAddonsOnly” before the eviction(s) +the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s) (see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)). Each critical add-on has to tolerate it, the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled. diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index 3096bed7eb..b5926744ae 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -18,15 +18,15 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. ### Linux -The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the “public” NIC. +The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC. ### Windows Each Window Server node should have the following configuration: 1. Two NICs (virtual networking adapters) are required on each Windows Server node - The two Windows container networking modes of interest (transparent and L2 bridge) use an external Hyper-V virtual switch. This means that one of the NICs is entirely allocated to the bridge, creating the need for the second NIC. 2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below -3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also “captures” packets that have the destination IP of a POD running on the node. To enable, open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Routing and Remote Access Service” and the underlying checkboxes -4. Routes defined pointing to the other pod CIDRs via the “public” NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below +3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes +4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below The following diagram illustrates the Windows Server networking setup for Kubernetes Setup ![Windows Setup](windows-setup.png) diff --git a/docs/tutorials/kubernetes-basics/explore-intro.html b/docs/tutorials/kubernetes-basics/explore-intro.html index edc813d3d4..56bde41cfd 100644 --- a/docs/tutorials/kubernetes-basics/explore-intro.html +++ b/docs/tutorials/kubernetes-basics/explore-intro.html @@ -34,7 +34,7 @@ title: Viewing Pods and Nodes
  • Networking, as a unique cluster IP address
  • Information about how to run each container, such as the container image version or specific ports to use
    • -

    A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    +

    A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.

    diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md index f0aa08bf04..86e60cffda 100644 --- a/docs/user-guide/replicasets.md +++ b/docs/user-guide/replicasets.md @@ -35,7 +35,7 @@ their Replica Sets. ## When to use a Replica Set? -A Replica Set ensures that a specified number of pod “replicas” are running at any given +A Replica Set ensures that a specified number of pod "replicas" are running at any given time. However, a Deployment is a higher-level concept that manages Replica Sets and provides declarative updates to pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using Replica Sets, unless From 521ae621eb869b97d209f35f23ffe37801a92130 Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 16:21:49 +0800 Subject: [PATCH 2/5] duplicated 'the' --- docs/admin/cluster-large.md | 16 ++++++++-------- docs/admin/ha-master-gce.md | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/admin/cluster-large.md b/docs/admin/cluster-large.md index f41df12689..41393bc01d 100644 --- a/docs/admin/cluster-large.md +++ b/docs/admin/cluster-large.md @@ -1,10 +1,10 @@ ---- -assignees: -- davidopp -- lavalamp -title: Building Large Clusters ---- - +--- +assignees: +- davidopp +- lavalamp +title: Building Large Clusters +--- + ## Support At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria: @@ -21,7 +21,7 @@ At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More sp A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. diff --git a/docs/admin/ha-master-gce.md b/docs/admin/ha-master-gce.md index 262dafbe0a..871ce56606 100644 --- a/docs/admin/ha-master-gce.md +++ b/docs/admin/ha-master-gce.md @@ -24,7 +24,7 @@ If true, reads will be directed to leader etcd replica. Setting this value to true is optional: reads will be more reliable but will also be slower. Optionally, you can specify a GCE zone where the first master replica is to be created. -Set the the following flag: +Set the following flag: * `KUBE_GCE_ZONE=zone` - zone where the first master replica will run. From 5d6a3aaa53486021aea2e1fe5446a5a5081cf12d Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 16:56:12 +0800 Subject: [PATCH 3/5] fix a series errors of using "a" and "an" --- _includes/v1.3/extensions-v1beta1-definitions.html | 6 +++--- _includes/v1.3/extensions-v1beta1-operations.html | 4 ++-- _includes/v1.3/v1-definitions.html | 6 +++--- _includes/v1.3/v1-operations.html | 8 ++++---- _includes/v1.4/extensions-v1beta1-operations.html | 4 ++-- _includes/v1.4/v1-operations.html | 10 +++++----- docs/admin/addons.md | 2 +- docs/admin/kubelet.md | 2 +- docs/getting-started-guides/libvirt-coreos.md | 2 +- docs/getting-started-guides/mesos/index.md | 2 +- docs/getting-started-guides/rackspace.md | 2 +- docs/tutorials/services/source-ip.md | 2 +- docs/user-guide/connecting-applications.md | 2 +- docs/user-guide/jobs/work-queue-2/rediswq.py | 2 +- docs/user-guide/load-balancer.md | 2 +- docs/user-guide/petset.md | 2 +- docs/user-guide/pods/init-container.md | 2 +- 17 files changed, 30 insertions(+), 30 deletions(-) diff --git a/_includes/v1.3/extensions-v1beta1-definitions.html b/_includes/v1.3/extensions-v1beta1-definitions.html index 7ecddc8d7b..92ce832083 100755 --- a/_includes/v1.3/extensions-v1beta1-definitions.html +++ b/_includes/v1.3/extensions-v1beta1-definitions.html @@ -2079,7 +2079,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i

    v1.FlexVolumeSource

    -

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    +

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    @@ -2535,7 +2535,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i - + @@ -5867,7 +5867,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/_includes/v1.3/extensions-v1beta1-operations.html b/_includes/v1.3/extensions-v1beta1-operations.html index be39609140..21f12fcf7a 100755 --- a/_includes/v1.3/extensions-v1beta1-operations.html +++ b/_includes/v1.3/extensions-v1beta1-operations.html @@ -5578,7 +5578,7 @@
    -

    create a Ingress

    +

    create an Ingress

    POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses
    @@ -5959,7 +5959,7 @@
    -

    delete a Ingress

    +

    delete an Ingress

    DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}
    diff --git a/_includes/v1.3/v1-definitions.html b/_includes/v1.3/v1-definitions.html index e833b003ea..693f3ce4c7 100755 --- a/_includes/v1.3/v1-definitions.html +++ b/_includes/v1.3/v1-definitions.html @@ -2560,7 +2560,7 @@ The resulting set of endpoints can be viewed as:

    v1.FlexVolumeSource

    -

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    +

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource

    path

    Path is a extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string
    @@ -3268,7 +3268,7 @@ The resulting set of endpoints can be viewed as:
    - + @@ -5555,7 +5555,7 @@ The resulting set of endpoints can be viewed as:
    - + diff --git a/_includes/v1.3/v1-operations.html b/_includes/v1.3/v1-operations.html index 24e21c4f53..de6b5117e6 100755 --- a/_includes/v1.3/v1-operations.html +++ b/_includes/v1.3/v1-operations.html @@ -2676,7 +2676,7 @@
    -

    create a Endpoints

    +

    create an Endpoints

    POST /api/v1/namespaces/{namespace}/endpoints
    @@ -3057,7 +3057,7 @@
    -

    delete a Endpoints

    +

    delete an Endpoints

    DELETE /api/v1/namespaces/{namespace}/endpoints/{name}
    @@ -3619,7 +3619,7 @@
    -

    create a Event

    +

    create an Event

    POST /api/v1/namespaces/{namespace}/events
    @@ -4000,7 +4000,7 @@
    -

    delete a Event

    +

    delete an Event

    DELETE /api/v1/namespaces/{namespace}/events/{name}
    diff --git a/_includes/v1.4/extensions-v1beta1-operations.html b/_includes/v1.4/extensions-v1beta1-operations.html index a18a2f6030..ce55af43d9 100755 --- a/_includes/v1.4/extensions-v1beta1-operations.html +++ b/_includes/v1.4/extensions-v1beta1-operations.html @@ -5578,7 +5578,7 @@
    -

    create a Ingress

    +

    create an Ingress

    POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses
    @@ -5959,7 +5959,7 @@
    -

    delete a Ingress

    +

    delete an Ingress

    DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}
    diff --git a/_includes/v1.4/v1-operations.html b/_includes/v1.4/v1-operations.html index 875b464420..f866fc12fc 100755 --- a/_includes/v1.4/v1-operations.html +++ b/_includes/v1.4/v1-operations.html @@ -2676,7 +2676,7 @@
    -

    create a Endpoints

    +

    create an Endpoints

    POST /api/v1/namespaces/{namespace}/endpoints
    @@ -3057,7 +3057,7 @@
    -

    delete a Endpoints

    +

    delete an Endpoints

    DELETE /api/v1/namespaces/{namespace}/endpoints/{name}
    @@ -3619,7 +3619,7 @@
    -

    create a Event

    +

    create an Event

    POST /api/v1/namespaces/{namespace}/events
    @@ -4000,7 +4000,7 @@
    -

    delete a Event

    +

    delete an Event

    DELETE /api/v1/namespaces/{namespace}/events/{name}
    @@ -7885,7 +7885,7 @@
    -

    create eviction of a Eviction

    +

    create eviction of an Eviction

    POST /api/v1/namespaces/{namespace}/pods/{name}/eviction
    diff --git a/docs/admin/addons.md b/docs/admin/addons.md index f45aebeb09..aeee68cc30 100644 --- a/docs/admin/addons.md +++ b/docs/admin/addons.md @@ -14,7 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes. +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes. * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md index 342189ba94..e593cda77b 100644 --- a/docs/admin/kubelet.md +++ b/docs/admin/kubelet.md @@ -79,7 +79,7 @@ kubelet --experimental-bootstrap-kubeconfig string Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir. --experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. --experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount - --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint. + --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch an in-process CRI server on behalf of docker, and communicate over a default endpoint. --experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6. --experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. --experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount. diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index 73be7e4261..e5668dbf53 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -30,7 +30,7 @@ Another difference is that no security is enforced on `libvirt-coreos` at all. F * Kubernetes secrets are not protected as securely as they are on production environments; * etc. -So, an k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like: +So, a k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like: * un-authenticated access to Kube API server; * Access to Kubernetes private data structures inside etcd; diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md index 948eae1a41..499ff0ba51 100644 --- a/docs/getting-started-guides/mesos/index.md +++ b/docs/getting-started-guides/mesos/index.md @@ -229,7 +229,7 @@ We assume that kube-dns will use Note that we have passed these two values already as parameter to the apiserver above. -A template for an replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: +A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: - replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1` - replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.` diff --git a/docs/getting-started-guides/rackspace.md b/docs/getting-started-guides/rackspace.md index 00c73a8e59..ff59f4d31b 100644 --- a/docs/getting-started-guides/rackspace.md +++ b/docs/getting-started-guides/rackspace.md @@ -45,7 +45,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo 1. A cloud network will be created and all instances will be attached to this network. - flanneld uses this network for next hop routing. These routes allow the containers running on each node to communicate with one another on this private network. -2. A SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password). +2. An SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password). 3. The master server and additional nodes will be created via the `nova` CLI. A `cloud-config.yaml` is generated and provided as user-data with the entire configuration for the systems. 4. We then boot as many nodes as defined via `$NUM_NODES`. diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index 6657e42720..76548e68ad 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -29,7 +29,7 @@ This document makes use of the following terms: You must have a working Kubernetes 1.5 cluster to run the examples in this document. The examples use a small nginx webserver that echoes back the source -IP of requests it receives through a HTTP header. You can create it as follows: +IP of requests it receives through an HTTP header. You can create it as follows: ```console $ kubectl run source-ip-app --image=gcr.io/google_containers/echoserver:1.4 diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index 95d365bdb1..c4ca8d20f0 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -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" %} diff --git a/docs/user-guide/jobs/work-queue-2/rediswq.py b/docs/user-guide/jobs/work-queue-2/rediswq.py index ebefa64311..ceda8bd1e3 100644 --- a/docs/user-guide/jobs/work-queue-2/rediswq.py +++ b/docs/user-guide/jobs/work-queue-2/rediswq.py @@ -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 diff --git a/docs/user-guide/load-balancer.md b/docs/user-guide/load-balancer.md index d8540d98e5..fadeb38d5f 100644 --- a/docs/user-guide/load-balancer.md +++ b/docs/user-guide/load-balancer.md @@ -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. diff --git a/docs/user-guide/petset.md b/docs/user-guide/petset.md index 3cba1fb31e..07934774b4 100644 --- a/docs/user-guide/petset.md +++ b/docs/user-guide/petset.md @@ -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 diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md index 75b6efcac3..c9266baf67 100644 --- a/docs/user-guide/pods/init-container.md +++ b/docs/user-guide/pods/init-container.md @@ -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 From e0a6a2c835c54c3a5508d43158d3c0d21e97f1e5 Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 17:57:06 +0800 Subject: [PATCH 4/5] revert --- docs/admin/cluster-large.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/admin/cluster-large.md b/docs/admin/cluster-large.md index 41393bc01d..f41df12689 100644 --- a/docs/admin/cluster-large.md +++ b/docs/admin/cluster-large.md @@ -1,10 +1,10 @@ ---- -assignees: -- davidopp -- lavalamp -title: Building Large Clusters ---- - +--- +assignees: +- davidopp +- lavalamp +title: Building Large Clusters +--- + ## Support At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria: @@ -21,7 +21,7 @@ At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More sp A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. From c67b76a2f0607943ffc0685f210edbc47646d1c3 Mon Sep 17 00:00:00 2001 From: guohaifang Date: Fri, 23 Dec 2016 15:29:44 +0800 Subject: [PATCH 5/5] problems of grammer --- docs/tutorials/stateful-application/basic-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md index 07e41cd56d..60a8a30652 100644 --- a/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/docs/tutorials/stateful-application/basic-stateful-set.md @@ -11,7 +11,7 @@ title: StatefulSet Basics --- {% capture overview %} -This tutorial provides an introduction to managing applications with +This tutorial provides an introduction to manage applications with [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/). It demonstrates how to create, delete, scale, and update the container image of a StatefulSet.

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource