whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into release-1.7

Browse Source
This commit is contained in:
steveperry-53
2017-08-09 10:12:58 -07:00
parent b551662dee 25f0f09775
commit 99c76f299e
25 changed files with 195 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWNERS
+3 -6
View File
@@ -1,6 +1,3 @@
approvers:
- smarterclayton
- janetkuo
- pwittrock
- kelseyhightower
- jaredbhatti
reviewers:
- chenopis
- zacharysarah
_data/tutorials.yml
+4 -2
View File
@@ -29,8 +29,11 @@ toc:
section:
- docs/tutorials/kubernetes-basics/update-intro.html
- docs/tutorials/kubernetes-basics/update-interactive.html
- title: Online Training Course
- title: Online Training Courses
section: Scalable Microservices with Kubernetes (Udacity)
path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
section: Introduction to Kubernetes (edX)
path: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#
- docs/tutorials/stateless-application/hello-minikube.md
- title: Configuration
section:
@@ -61,4 +64,3 @@ toc:
- title: Services
section:
- docs/tutorials/services/source-ip.md
docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -77,7 +77,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the
kubelet's serving certificate.
If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels)
If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
docs/concepts/overview/working-with-objects/namespaces.md
+1 -1
View File
@@ -82,7 +82,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
## Not All Objects are in a Namespace
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
in some namespace. However namespace resources are not themselves in a namespace.
in some namespaces. However namespace resources are not themselves in a namespace.
And low-level resources, such as [nodes](/docs/admin/node) and
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
have a namespace, depending on the object the event is about.
docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -101,7 +101,7 @@ Kubernetes supports 2 primary modes of finding a Service - environment variables
### Environment Variables
When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different):
When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different):
```shell
$ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -93,7 +93,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler
created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
when the pod is created, so it is ignored by the scheduler). Therefore:
- the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
- The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
by the DaemonSet controller.
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
bootstrap.
docs/concepts/workloads/controllers/statefulset.md
+3 -3
View File
@@ -94,10 +94,9 @@ spec:
volumeClaimTemplates:
- metadata:
name: www
annotations:
volume.beta.kubernetes.io/storage-class: anything
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: my-storage-class
resources:
requests:
storage: 1Gi
@@ -143,7 +142,8 @@ Note that Cluster Domain will be set to `cluster.local` unless
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled
with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
docs/concepts/workloads/pods/init-containers.md
+1 -1
View File
@@ -83,7 +83,7 @@ Here are some ideas for how to use Init Containers:
* Wait for some time before starting the app Container with a command like `sleep 60`.
* Clone a git repository into a volume.
* Place values into a configuration file and run a template tool to dynamically
generate a configuration file for the the main app Container. For example,
generate a configuration file for the main app Container. For example,
place the POD_IP value in a configuration and generate the main app
configuration file using Jinja.
docs/getting-started-guides/kubespray.md
+70 -62
View File
@@ -4,94 +4,102 @@ title: Installing Kubernetes On-premises/Cloud Providers with Kubespray
## Overview
This quickstart helps to install a Kubernetes cluster hosted
on GCE, Azure, OpenStack, AWS or Baremetal with
[`Kubespray`](https://github.com/kubernetes-incubator/kubespray) tool.
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks,
[inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md)
generation CLI tools and domain knowledge for generic OS/Kubernetes
clusters configuration management tasks. It provides:
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* [High available cluster](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md)
* [Composable](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md)
(Choice of the network plugin, for instance)
* Support most popular Linux
[distributions](https://github.com/kubernetes-incubator/kubespray#supported-linux-distributions)
* Continuous integration tests
* a highly available cluster
* composable attributes
* support for most popular Linux distributions
* continuous integration tests
To choose a tool which fits your use case the best, you may want to read this
[comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md)
to [kubeadm](../kubeadm) and [kops](../kops).
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](../kubeadm) and [kops](../kops).
## Creating a cluster
### (1/4) Ensure the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements) are met
### (1/5) Meet the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements)
#### Checklist
Provision servers with the following requirements:
* You must have cloud instances or baremetal nodes running for your future Kubernetes cluster.
A way to achieve that is to use the
[kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md).
* Or provision baremetal hosts with a tool-of-your-choice or launch cloud instances,
then create an inventory file for Ansible with this [tool](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py).
* `Ansible v2.3` (or newer)
* `Jinja 2.9` (or newer)
* `python-netaddr` installed on the machine that running Ansible commands
* Target servers must have access to the Internet in order to pull docker images
* Target servers are configured to allow IPv4 forwarding
* Target servers have SSH connectivity ( tcp/22 ) directly to your nodes or through a bastion host/ssh jump box
* Target servers have a privileged user
* Your SSH key must be copied to all the servers that are part of your inventory
* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate
* If using a cloud provider, you must have the appropriate credentials available and exported as environment variables
### (2/4) Compose the deployment
Kubespray provides the following utilities to help provision your environment:
#### Checklist
* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
* [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
* [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
* [kubespray-cli](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
* Customize your deployment by usual Ansible meanings, which is
[generating inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)
and overriding default data [variables](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md).
Or just stick with default values (Kubespray will choose Calico networking plugin for you
then). This includes steps like deciding on the:
* DNS [configuration options](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md)
* [Networking plugin](https://github.com/kubernetes-incubator/kubespray#network-plugins) to use
* [Versions](https://github.com/kubernetes-incubator/kubespray#versions-of-supported-components)
of components.
* Additional node groups like [bastion hosts](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md#bastion-host) or
[Calico BGP route reflectors](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/calico.md#optional--bgp-peering-with-border-routers).
* Plan custom deployment steps, if any, or use the default composition layer in the
[cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml).
Taking the best from Ansible world, Kubespray allows users to execute arbitrary steps via the
``ansible-playbook`` with given inventory, playbooks, data overrides and tags, limits, batches
of nodes to deploy and so on.
* For large deployments (100+ nodes), you may want to
[tweak things](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md)
for best results.
**Note:** kubespray-cli is no longer actively maintained.
{. :note}
### (3/4) Run the deployment
### (2/5) Compose an inventory file
#### Checklist
After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
* Apply deployment with
[kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
or ``ansible-playbook``
[manual commands](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
### (3/5) Plan your cluster deployment
### (4/4) (Optional) verify inter-pods connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md)
Kubespray provides the ability to customize many aspects of the deployment:
#### Checklist
* CNI (networking) plugins
* DNS configuration
* Choice of control plane: native/binary or containerized with docker or rkt)
* Component versions
* Calico route reflectors
* Component runtime options
* Certificate generation methods
* Ensure the netchecker-agent's pods can resolve DNS requests and ping each over within the default namespace.
Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
## Explore contributed add-ons
### (4/5) Deploy a Cluster
See the [list of contributed playbooks](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib)
to explore other deployment options.
Next, deploy your cluster with one of two methods:
* [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
* [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
**Note:** kubespray-cli is no longer actively maintained.
{. :note}
Both methods run the default [cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml).
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
### (5/5) Verify the deployment
Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
## Cluster operations
Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_.
### Scale your cluster
You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#Adding-nodes)".
### Upgrade your cluster
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
## What's next
Kubespray has quite a few [marks on the radar](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
## Cleanup
To delete your scratch cluster, you can apply the
[reset role](https://github.com/kubernetes-incubator/kubespray/blob/master/roles/reset/tasks/main.yml)
with the manual ``ansible-playbook`` command.
You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
Note, that it is highly unrecommended to delete production clusters with the reset playbook!
**Caution:** When running the reset playbook, be sure not to accidentally target your production cluster!
{. :caution}
## Feedback
docs/getting-started-guides/mesos/index.md
+6 -3
View File
@@ -228,13 +228,16 @@ Note that we have passed these two values already as parameter to the apiserver
A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/kubedns-controller.yaml.in][12] 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.`
{% assign dns_replicas = "{{ pillar['dns_replicas'] }}" %}
{% assign dns_domain = "{{ pillar['dns_domain'] }}" %}
- replace `{{ dns_replicas }}` with `1`
- replace `{{ dns_domain }}` with `cluster.local.`
- add `--kube_master_url=${KUBERNETES_MASTER}` parameter to the kube2sky container command.
In addition the service template at [cluster/addons/dns/kubedns-controller.yaml.in][12] needs the following replacement:
- `{% raw %}{{ pillar['dns_server'] }}{% endraw %}` with `10.10.10.10`.
{% assign dns_server = "{{ pillar['dns_server'] }}" %}
- `{{ dns_server }}` with `10.10.10.10`.
To do this automatically:
docs/getting-started-guides/ubuntu/upgrades.md
+1 -1
View File
@@ -40,7 +40,7 @@ The Kubernetes Charms use snap channels to drive payloads. The channels are defi
| beta | Latest alpha or beta of Kubernetes for that minor release |
| edge | Nightly builds of that minor release of Kubernetes |
If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availablility of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms.
If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availability of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms.
## Master Upgrades
docs/home/contribute/review-issues.md
+1 -1
View File
@@ -55,7 +55,7 @@ The following labels and definitions should be used to prioritize issues. If you
## Handling special issue types
### Duplicate issues
If a single problem has one or more issues open for it, the problem should be consolodated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem.
If a single problem has one or more issues open for it, the problem should be consolidated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem.
### Dead link issues
Depending on where the dead link is reported, different actions are required to resolve the issue. Dead links in the API and Kubectl docs are automation issues and should be assigned a P1 until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned a P3.
docs/home/contribute/style-guide.md
+1 -1
View File
@@ -231,7 +231,7 @@ I didn't read the stlye guide.
### Ordered Lists
Callouts will interupt numbered lists unless you indent three spaces before the notice and the tag.
Callouts will interrupt numbered lists unless you indent three spaces before the notice and the tag.
For example:
docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md
+1 -1
View File
@@ -127,7 +127,7 @@ $ kubectl get crontab -o json
"uid": "6f65e7a3-8601-11e6-a23e-42010af0000c"
}
}
]
],
"kind": "List",
"metadata": {},
"resourceVersion": "",
docs/tasks/administer-cluster/encrypt-data.md
+1 -1
View File
@@ -148,7 +148,7 @@ program to retrieve the contents of your secret.
Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
```
kubectl get secrets -o json | kubectl replace -f -
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
The command above reads all secrets and then updates them to apply server side encryption.
docs/tasks/administer-cluster/weave-network-policy.md
+81 -1
View File
@@ -26,9 +26,89 @@ The Weave Net Addon for Kubernetes comes with a [Network Policy Controller](http
{% endcapture %}
{% capture example %}
## Namespace isolation example
1. Create a namespace with `DefaultDeny`.
```yaml
kind: Namespace
apiVersion: v1
metadata:
name: myns
annotations:
net.beta.kubernetes.io/network-policy: |
{
"ingress": {
"isolation": "DefaultDeny"
}
}
```
2. Create 2 pods inside this namespace.
```yaml
kind: Pod
apiVersion: v1
metadata:
name: pod1
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod1
image: nginx
---
kind: Pod
apiVersion: v1
metadata:
name: pod2
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod2
image: nginx
```
3. Get the IP addresses of the pods.
```shell
kubectl get po -n myns -o wide
```
**Note:** If your cURL requests to pods are forbidden, try making cURL requests to other pods from within a pod.
{: .note}
4. Create a Kubernetes NetworkPolicy that allows pods within the same namespace to connect with each other.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: aaa
namespace: myns
spec:
podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
ingress:
- from:
- podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
```
**Caution:** After applying the network policy, pods outside the namespace you specify may be unable to connect with pods inside the namespace.
{. :caution}
{% endcapture %}
{% capture whatsnext %}
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
Once you have installed the Weave Net addon, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
{% endcapture %}
docs/tasks/configure-pod-container/configmap.md
+1 -1
View File
@@ -223,7 +223,7 @@ metadata:
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the a Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+1 -1
View File
@@ -136,7 +136,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
other code indicates failure.
You can see the source code for the server in
[server.go](http://k8s.io/docs/user-guide/liveness/image/server.go).
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go).
For the first 10 seconds that the Container is alive, the `/healthz` handler
returns a status of 200. After that, the handler returns a status of 500.
docs/tasks/configure-pod-container/configure-pod-configmap.md
+1 -1
View File
@@ -234,7 +234,7 @@ special.level
special.type
```
### Add ConfigMap data to a specific path in the Volume:
### Add ConfigMap data to a specific path in the Volume
Use the `path` field to specify the desired file path for specific ConfigMap items.
In this case, the `special.level` item will be mounted in the `config-volume` volume at `/etc/config/keys`.
docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+1 -1
View File
@@ -50,7 +50,7 @@ Here is a video showing how to setup and run a Google Cloud Monitoring backed He
[![how to setup and run a Google Cloud Monitoring backed Heapster](http://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](http://www.youtube.com/watch?v=xSMNR2fcoLs)
Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wide resource usage.
Here is a snapshot of the Google Cloud Monitoring dashboard showing cluster-wide resource usage.
![Google Cloud Monitoring dashboard](/images/docs/gcm.png)
docs/tasks/federation/set-up-cluster-federation-kubefed.md
+3 -3
View File
@@ -67,9 +67,9 @@ kubefed is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubefed --classic
sudo snap install kubefed --classic
2. Run `kubefed version` to verify that the verison you've installed is sufficiently up-to-date.
2. Run `kubefed version` to verify that the version you've installed is sufficiently up-to-date.
## Choosing a host cluster.
@@ -422,7 +422,7 @@ in the federation don't follow
In such cases, you can specify a cluster name that conforms to the
[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules
and specify the cluster context using the `--cluster-context` flag.
For example, if context of the cluster your are joining is
For example, if context of the cluster you are joining is
`gondor_needs-no_king`, then you can join the cluster by running:
```shell
docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+6 -6
View File
@@ -60,8 +60,8 @@ We may check the current status of autoscaler by running:
```shell
$ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
php-apache Deployment/php-apache/scale 50% 0% 1 10 18s
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
```
@@ -85,8 +85,8 @@ Within a minute or so, we should see the higher CPU load by executing:
```shell
$ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
php-apache Deployment/php-apache/scale 50% 305% 1 10 3m
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m
```
@@ -114,8 +114,8 @@ Then we will verify the result state (after a minute or so):
```shell
$ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
php-apache Deployment/php-apache/scale 50% 0% 1 10 11m
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
$ kubectl get deployment php-apache
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
docs/tools/kompose/user-guide.md
+1 -1
View File
@@ -30,7 +30,7 @@ file "redis-deployment.yaml" created
## Installation
We have multiple ways to install Kompose. Our prefered method is downloading the binary from the latest GitHub release.
We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release.
### GitHub release
docs/tutorials/index.md
+3 -1
View File
@@ -9,7 +9,9 @@ each of which has a sequence of steps.
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
* [Online Training Course](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
+1 -1
View File
@@ -484,7 +484,7 @@ TODO(1.6): For 1.6, add the following bullet point to 1.
### How different types of fields are merged
How a particular field in a configuration file is merged with
with the live configuration depends on the
the live configuration depends on the
type of the field. There are several types of fields:
- *primitive*: A field of type string, integer, or boolean.