Merge branch 'master' into updoc3
This commit is contained in:
Mike Spreitzer
@@ -349,8 +349,8 @@ logs or through `journalctl`. More information is provided in
|
||||
|
||||
Additional resources:
|
||||
|
||||
- http://wiki.apparmor.net/index.php/QuickProfileLanguage
|
||||
- http://wiki.apparmor.net/index.php/ProfileLanguage
|
||||
- [Quick guide to the AppArmor profile language](http://wiki.apparmor.net/index.php/QuickProfileLanguage)
|
||||
- [AppArmor core policy reference](http://wiki.apparmor.net/index.php/ProfileLanguage)
|
||||
|
||||
## API Reference
|
||||
|
||||
|
||||
@@ -42,16 +42,6 @@ You will install the following packages on all the machines:
|
||||
|
||||
For each host in turn:
|
||||
|
||||
<!--
|
||||
# curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
|
||||
# cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
|
||||
deb http://packages.cloud.google.com/apt kubernetes-xenial main
|
||||
EOF
|
||||
# apt-get update
|
||||
# apt-get install -y kubeadm docker.io§
|
||||
-->
|
||||
|
||||
|
||||
* SSH into the machine and become `root` if you are not already (for example, run `sudo su -`).
|
||||
* If the machine is running Ubuntu 16.04, run:
|
||||
|
||||
@@ -92,6 +82,9 @@ To initialize the master, pick one of the machines you previously installed `kub
|
||||
|
||||
# kubeadm init
|
||||
|
||||
**Note:** this will autodetect the network interface to advertise the master on as the interface with the default gateway.
|
||||
If you want to use a different interface, specify `--api-advertise-addresses=<ip-address>` argument to `kubeadm init`.
|
||||
|
||||
This will download and install the cluster database and "control plane" components.
|
||||
This may take several minutes.
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ export KUBERNETES_PROVIDER=libvirt-coreos; wget -q -O - https://get.k8s.io | bas
|
||||
Here is the curl version of this command:
|
||||
|
||||
```shell
|
||||
export KUBERNETES_PROVIDER=libvirt-coreos; curl -sS https://get.k8s.io | bash`
|
||||
export KUBERNETES_PROVIDER=libvirt-coreos; curl -sS https://get.k8s.io | bash
|
||||
```
|
||||
|
||||
This script downloads and unpacks the tarball, then spawns a Kubernetes cluster on CoreOS instances with the following characteristics:
|
||||
|
||||
@@ -47,9 +47,8 @@ ssh jclouds@${ip_address_of_master_node}
|
||||
Build Kubernetes-Mesos.
|
||||
|
||||
```shell
|
||||
git clone https://github.com/kubernetes/kubernetes
|
||||
cd kubernetes
|
||||
export KUBERNETES_CONTRIB=mesos
|
||||
git clone https://github.com/kubernetes-incubator/kube-mesos-framework
|
||||
cd kube-mesos-framework
|
||||
make
|
||||
```
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ To start a cluster, run the command:
|
||||
```shell
|
||||
minikube start
|
||||
Starting local Kubernetes cluster...
|
||||
Kubernetes is available at https://192.168.99.100:443.
|
||||
Kubectl is now configured to use the cluster.
|
||||
```
|
||||
|
||||
This will build and start a lightweight local cluster, consisting of a master, etcd, Docker and a single node.
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
This page shows how to assign a Kubernetes Pod to a particular node in a
|
||||
Kubernetes cluster.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
* Install [kubectl](http://kubernetes.io/docs/user-guide/prereqs).
|
||||
|
||||
* Create a Kubernetes cluster, including a running Kubernetes
|
||||
API server. One way to create a new cluster is to use
|
||||
[Minikube](/docs/getting-started-guides/minikube).
|
||||
|
||||
* Configure `kubectl` to communicate with your Kubernetes API server. This
|
||||
configuration is done automatically if you use Minikube.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
### Adding a label to a node
|
||||
|
||||
1. List the nodes in your cluster:
|
||||
|
||||
kubectl get nodes
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME STATUS AGE
|
||||
worker0 Ready 1d
|
||||
worker1 Ready 1d
|
||||
worker2 Ready 1d
|
||||
|
||||
1. Chose one of your nodes, and add a label to it:
|
||||
|
||||
kubectl label nodes <your-node-name> disktype=ssd
|
||||
|
||||
where `<your-node-name>` is the name of your chosen node.
|
||||
|
||||
1. Verify that your chosen node has a `disktype=ssd` label:
|
||||
|
||||
kubectl get nodes --show-labels
|
||||
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME STATUS AGE LABELS
|
||||
worker0 Ready 1d ...,disktype=ssd,kubernetes.io/hostname=worker0
|
||||
worker1 Ready 1d ...,kubernetes.io/hostname=worker1
|
||||
worker2 Ready 1d ...,kubernetes.io/hostname=worker2
|
||||
|
||||
In the preceding output, you can see that the `worker0` node has a
|
||||
`disktype=ssd` label.
|
||||
|
||||
### Creating a pod that gets scheduled to your chosen node
|
||||
|
||||
This pod configuration file describes a pod that has a node selector,
|
||||
`disktype: ssd`. This means that the pod will get scheduled on a node that has
|
||||
a `disktype=ssd` label.
|
||||
|
||||
{% include code.html language="yaml" file="pod.yaml" ghlink="/docs/tasks/administer-cluster/pod.yaml" %}
|
||||
|
||||
1. Use the configuration file to create a pod that will get scheduled on your
|
||||
chosen node:
|
||||
|
||||
export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master
|
||||
kubectl create -f $REPO/docs/tasks/administer-cluster/pod.yaml
|
||||
|
||||
1. Verify that the pod is running on your chosen node:
|
||||
|
||||
kubectl get pods --output=wide
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
Learn more about
|
||||
[labels and selectors](/docs/user-guide/labels/).
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
nodeSelector:
|
||||
disktype: ssd
|
||||
@@ -11,6 +11,9 @@ The Tasks section of the Kubernetes documentation is a work in progress
|
||||
|
||||
* [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api)
|
||||
|
||||
#### Administering a Cluster
|
||||
|
||||
* [Assigning Pods to Nodes](/docs/tasks/administer-cluster/assign-pods-nodes/)
|
||||
|
||||
### What's next
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ The Tutorials section of the Kubernetes documentation is a work in progress.
|
||||
|
||||
* [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/)
|
||||
|
||||
* [Exposing an External IP Address Using a Service](/docs/tutorials/stateless-application/expose-external-ip-address-service/)
|
||||
* [Using a Service to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address-service/)
|
||||
|
||||
### What's next
|
||||
|
||||
|
||||
@@ -16,4 +16,3 @@ spec:
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
Contact GitHub API Training Shop Blog About
|
||||
|
||||
@@ -4,9 +4,8 @@
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to create a Kubernetes Service object that external
|
||||
clients can use to access an application running in a cluster. The
|
||||
Service exposes a stable IP address and provides load balancing for
|
||||
an application that has two running instances.
|
||||
clients can use to access an application running in a cluster. The Service
|
||||
provides load balancing for an application that has two running instances.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -28,7 +27,7 @@ an application that has two running instances.
|
||||
{% capture objectives %}
|
||||
|
||||
* Run two instances of a Hello World application.
|
||||
* Create a Service object that exposes an external IP address.
|
||||
* Create a Service object that exposes a node port.
|
||||
* Use the Service object to access the running application.
|
||||
|
||||
{% endcapture %}
|
||||
@@ -55,63 +54,68 @@ an application that has two running instances.
|
||||
kubectl get deployments hello-world
|
||||
kubectl describe deployments hello-world
|
||||
|
||||
1. Display information about the ReplicaSet:
|
||||
1. Display information about your ReplicaSet objects:
|
||||
|
||||
kubectl get replicasets hello-world
|
||||
kubectl describe replicasets hello-world
|
||||
|
||||
1. List the pods that are running the Hello World application:
|
||||
|
||||
kubectl get pods --selector="run=load-balancer-example"
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hello-world-2189936611-8fyp0 1/1 Running 0 6m
|
||||
hello-world-2189936611-9isq8 1/1 Running 0 6m
|
||||
kubectl get replicasets
|
||||
kubectl describe replicasets
|
||||
|
||||
1. Create a Service object that exposes the deployment:
|
||||
|
||||
kubectl expose deployment hello-world --type="LoadBalancer" --name="example-service"
|
||||
kubectl expose deployment hello-world --type=NodePort --name=example-service
|
||||
|
||||
1. Display the IP addresses for your service:
|
||||
1. Display information about the Service:
|
||||
|
||||
kubectl get services example-service
|
||||
|
||||
The output shows the internal IP address and the external IP address of
|
||||
your service. If the external IP address shows as `<pending>`, repeat the
|
||||
command.
|
||||
|
||||
Note: If you are using Minikube, you don't get an external IP address. The
|
||||
external IP address remains in the pending state.
|
||||
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
example-service 10.0.0.160 <pending> 8080/TCP 40s
|
||||
|
||||
1. Use your service to access the Hello World application:
|
||||
|
||||
curl <your-external-ip-address>:8080
|
||||
|
||||
where `<your-external-ip-address>` is the external IP address of your
|
||||
service.
|
||||
|
||||
The output is a hello message from the application:
|
||||
|
||||
Hello Kubernetes!
|
||||
|
||||
Note: If you are using Minikube, enter these commands:
|
||||
|
||||
kubectl cluster-info
|
||||
kubectl describe services example-service
|
||||
|
||||
The output displays the IP address of your Minikube node and the NodePort
|
||||
value for your service. Enter this command to access the Hello World
|
||||
application:
|
||||
The output is similar to this:
|
||||
|
||||
curl <minikube-node-ip-address>:<service-node-port>
|
||||
Name: example-service
|
||||
Namespace: default
|
||||
Labels: run=load-balancer-example
|
||||
Selector: run=load-balancer-example
|
||||
Type: NodePort
|
||||
IP: 10.32.0.16
|
||||
Port: <unset> 8080/TCP
|
||||
NodePort: <unset> 31496/TCP
|
||||
Endpoints: 10.200.1.4:8080,10.200.2.5:8080
|
||||
Session Affinity: None
|
||||
No events.
|
||||
|
||||
where `<minikube-node-ip-address>` us the IP address of your Minikube node,
|
||||
and `<service-node-port>` is the NodePort value for your service.
|
||||
Make a note of the NodePort value for the service. For example,
|
||||
in the preceding output, the NodePort value is 31496.
|
||||
|
||||
1. List the pods that are running the Hello World application:
|
||||
|
||||
kubectl get pods --selector="run=load-balancer-example" --output=wide
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
NAME READY STATUS ... IP NODE
|
||||
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
|
||||
hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2
|
||||
|
||||
1. Get the public IP address of one of your nodes that is running
|
||||
a Hello World pod. How you get this address depends on how you set
|
||||
up your cluster. For example, if you are using Minikube, you can
|
||||
see the node address by running `kubectl cluster-info`. If you are
|
||||
using Google Compute Engine instances, you can use the
|
||||
`gcloud compute instances list` command to see the public addresses of your
|
||||
nodes.
|
||||
|
||||
1. On your chosen node, create a firewall rule that allows TCP traffic
|
||||
on your node port. For example, if your Service has a NodePort value of
|
||||
31568, create a firewall rule that allows TCP traffic on port 31568.
|
||||
|
||||
1. Use the node address and node port to access the Hello World application:
|
||||
|
||||
curl http://<public-node-ip>:<node-port>
|
||||
|
||||
where `<public-node-ip>` us the public IP address of your node,
|
||||
and `<node-port>` is the NodePort value for your service.
|
||||
|
||||
The response to a successful request is a hello message:
|
||||
|
||||
Hello Kubernetes!
|
||||
|
||||
### Using a service configuration file
|
||||
|
||||
|
||||
@@ -75,7 +75,7 @@ a Deployment that runs the nginx:1.7.9 Docker image:
|
||||
|
||||
1. Display information about a pod:
|
||||
|
||||
kubectl display pod <pod-name>
|
||||
kubectl describe pod <pod-name>
|
||||
|
||||
where `<pod-name>` is the name of one of your pods.
|
||||
|
||||
|
||||
@@ -451,7 +451,8 @@ nginx-deployment-2035384211 0 0 1h
|
||||
nginx-deployment-3066724191 0 0 1h
|
||||
```
|
||||
|
||||
Note: A paused Deployment cannot be scaled at this moment, and we will add this feature in 1.3 release, see [issue #20853](https://github.com/kubernetes/kubernetes/issues/20853). You cannot rollback a paused Deployment either, and you should resume a Deployment first before doing a rollback.
|
||||
Note: You cannot rollback a paused Deployment until you resume it.
|
||||
|
||||
|
||||
## Use Cases
|
||||
|
||||
|
||||
@@ -89,5 +89,5 @@ Pods and containers
|
||||
* [Images and registries](/docs/user-guide/images/)
|
||||
* [Migrating from docker-cli to kubectl](/docs/user-guide/docker-cli-to-kubectl/)
|
||||
* [Configuration Best Practices and Tips](/docs/user-guide/config-best-practices/)
|
||||
* [Assign pods to selected nodes](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/update-demo/)
|
||||
* [Assign pods to selected nodes](/docs/user-guide/node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](/docs/user-guide/update-demo/)
|
||||
|
||||
@@ -238,11 +238,11 @@ considering one set of work items that the user wants to manage together —
|
||||
There are several different patterns for parallel computation, each with strengths and weaknesses.
|
||||
The tradeoffs are:
|
||||
|
||||
- One Job object for each work item, vs a single Job object for all work items. The latter is
|
||||
- One Job object for each work item, vs. a single Job object for all work items. The latter is
|
||||
better for large numbers of work items. The former creates some overhead for the user and for the
|
||||
system to manage large numbers of Job objects. Also, with the latter, the resource usage of the job
|
||||
(number of concurrently running pods) can be easily adjusted using the `kubectl scale` command.
|
||||
- Number of pods created equals number of work items, vs each pod can process multiple work items.
|
||||
- Number of pods created equals number of work items, vs. each pod can process multiple work items.
|
||||
The former typically requires less modification to existing code and containers. The latter
|
||||
is better for large numbers of work items, for similar reasons to the previous bullet.
|
||||
- Several approaches use a work queue. This requires running a queue service,
|
||||
|
||||
Reference in New Issue
Block a user