Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7
* 'master' of https://github.com/kubernetes/kubernetes.github.io: Fix sentence Minor grammatical correction Remove beta as K8s support on Bluemix Container Service is live Fix some output replace REASON with STATUS column IP is missed replace kubectl.sh with kubectl replace KUBECTL with kubectl fix the command output fix the command output fix the command output Correcting the typo in init-container's name fix typo fix typo fix typo fix typo fix typo Update pod-overview.md (#3881) apps/v1beta1 is not valid (#3814) Get access to search console. (#3901)
This commit is contained in:
Andrew Chen
@@ -486,7 +486,7 @@ invalid keys that were skipped. The example shows a pod which refers to the
|
||||
default/mysecret ConfigMap that contains 2 invalid keys, 1badkey and 2alsobad.
|
||||
|
||||
```shell
|
||||
$ kubectl.sh get events
|
||||
$ kubectl get events
|
||||
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON
|
||||
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.
|
||||
```
|
||||
|
||||
@@ -8,7 +8,7 @@ redirect_from:
|
||||
---
|
||||
|
||||
_Labels_ are key/value pairs that are attached to objects, such as pods.
|
||||
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but which do not directly imply semantics to the core system.
|
||||
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
|
||||
Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time.
|
||||
Each object can have a set of key/value labels defined. Each Key must be unique for a given object.
|
||||
|
||||
|
||||
@@ -41,9 +41,9 @@ You can list the current namespaces in a cluster using:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
NAME LABELS STATUS
|
||||
default <none> Active
|
||||
kube-system <none> Active
|
||||
NAME STATUS AGE
|
||||
default Active 1d
|
||||
kube-system Active 1d
|
||||
```
|
||||
|
||||
Kubernetes starts with two initial namespaces:
|
||||
|
||||
@@ -179,7 +179,7 @@ To modify policy interactively, use `kubectl edit`:
|
||||
$ kubectl edit psp permissive
|
||||
```
|
||||
|
||||
This command will open a default text editor where you will be ably to modify policy.
|
||||
This command will open a default text editor where you will be able to modify policy.
|
||||
|
||||
## Deleting a Pod Security Policy
|
||||
|
||||
|
||||
@@ -119,9 +119,9 @@ Note there's no mention of your Service. This is because you created the replica
|
||||
$ kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
|
||||
|
||||
$ kubectl get pods -l run=my-nginx -o wide
|
||||
NAME READY STATUS RESTARTS AGE NODE
|
||||
my-nginx-3800858182-e9ihh 1/1 Running 0 5s kubernetes-minion-ljyd
|
||||
my-nginx-3800858182-j4rm4 1/1 Running 0 5s kubernetes-minion-905m
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
|
||||
my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
|
||||
```
|
||||
|
||||
You may notice that the pods have different names, since they are killed and recreated.
|
||||
|
||||
@@ -526,7 +526,7 @@ Eventually, resume the Deployment and observe a new ReplicaSet coming up with al
|
||||
```shell
|
||||
$ kubectl rollout resume deploy nginx
|
||||
deployment "nginx" resumed
|
||||
$ KUBECTL get rs -w
|
||||
$ kubectl get rs -w
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 2 2 2 2m
|
||||
nginx-3926361531 2 2 0 6s
|
||||
@@ -543,7 +543,7 @@ nginx-2142116321 0 1 1 2m
|
||||
nginx-2142116321 0 0 0 2m
|
||||
nginx-3926361531 3 3 3 20s
|
||||
^C
|
||||
$ KUBECTL get rs
|
||||
$ kubectl get rs
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 0 0 0 2m
|
||||
nginx-3926361531 3 3 3 28s
|
||||
|
||||
@@ -308,7 +308,7 @@ to keep running, but you want the rest of the pods it creates
|
||||
to use a different pod template and for the job to have a new name.
|
||||
You cannot update the job because these fields are not updatable.
|
||||
Therefore, you delete job `old` but leave its pods
|
||||
running, using `kubectl delete jobs/old-one --cascade=false`.
|
||||
running, using `kubectl delete jobs/old --cascade=false`.
|
||||
Before deleting it, you make a note of what selector it uses:
|
||||
|
||||
```
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
apiVersion: apps/v1beta1
|
||||
apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx-deployment
|
||||
|
||||
@@ -118,7 +118,7 @@ Saving this config into `petset.yaml` and submitting it to a Kubernetes cluster
|
||||
```shell
|
||||
$ kubectl create -f petset.yaml
|
||||
service "nginx" created
|
||||
petset "nginx" created
|
||||
petset "web" created
|
||||
```
|
||||
|
||||
## Pet Identity
|
||||
|
||||
@@ -218,7 +218,7 @@ Events:
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
|
||||
13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634
|
||||
$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
|
||||
$ kubectl logs myapp-pod -c init-mydd # Inspect the second init container
|
||||
$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
|
||||
```
|
||||
|
||||
Once we start the `mydb` and `myservice` services, we can see the Init Containers
|
||||
|
||||
@@ -27,7 +27,7 @@ A Pod encapsulates an application container (or, in some cases, multiple contain
|
||||
Pods are employed a number of ways in a Kubernetes cluster, including:
|
||||
|
||||
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single managable entity.
|
||||
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
|
||||
|
||||
The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information on Pod use cases. For more information, see:
|
||||
|
||||
|
||||
@@ -125,7 +125,7 @@ Now create a node object internally in your Kubernetes cluster by running:
|
||||
$ kubectl create -f ./node.json
|
||||
|
||||
$ kubectl get nodes
|
||||
NAME STATUS AGE
|
||||
NAME STATUS AGE VERSION
|
||||
fed-node Unknown 4h
|
||||
```
|
||||
|
||||
@@ -172,7 +172,7 @@ done
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
NAME STATUS AGE
|
||||
NAME STATUS AGE VERSION
|
||||
fed-node Ready 4h
|
||||
```
|
||||
|
||||
|
||||
@@ -159,9 +159,9 @@ NAME READY STATUS RESTARTS AGE
|
||||
```shell
|
||||
# NOTE: your service IPs will likely differ
|
||||
$ kubectl get services
|
||||
NAME LABELS SELECTOR IP(S) PORT(S)
|
||||
k8sm-scheduler component=scheduler,provider=k8sm <none> 10.10.10.113 10251/TCP
|
||||
kubernetes component=apiserver,provider=kubernetes <none> 10.10.10.1 443/TCP
|
||||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
k8sm-scheduler 10.10.10.113 <none> 10251/TCP 1d
|
||||
kubernetes 10.10.10.1 <none> 443/TCP 1d
|
||||
```
|
||||
|
||||
Lastly, look for Kubernetes in the Mesos web GUI by pointing your browser to
|
||||
@@ -194,7 +194,7 @@ Send the pod description to Kubernetes using the `kubectl` CLI:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f ./nginx.yaml
|
||||
pods/nginx
|
||||
pod "nginx" created
|
||||
```
|
||||
|
||||
Wait a minute or two while `dockerd` downloads the image layers from the internet.
|
||||
|
||||
@@ -75,7 +75,7 @@ Pause the old workers so your workload migrates:
|
||||
|
||||
Verify old workloads have migrated with:
|
||||
|
||||
kubectl get-pod -o wide
|
||||
kubectl get pod -o wide
|
||||
|
||||
Tear down old workers with:
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ a Kubernetes cluster from scratch.
|
||||
|
||||
* [OpenShift Online](https://www.openshift.com/features/) provides free hosted access for Kubernetes applications.
|
||||
|
||||
* [IBM Bluemix Container Service](https://console.ng.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters. Currently in beta.
|
||||
* [IBM Bluemix Container Service](https://console.ng.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters.
|
||||
|
||||
* [Giant Swarm](https://giantswarm.io/product/) offers managed Kubernetes clusters in their own datacenter, on-premises, or on public clouds.
|
||||
|
||||
|
||||
@@ -68,6 +68,12 @@ $ curl http://localhost:8080/api/
|
||||
{
|
||||
"versions": [
|
||||
"v1"
|
||||
],
|
||||
"serverAddressByClientCIDRs": [
|
||||
{
|
||||
"clientCIDR": "0.0.0.0/0",
|
||||
"serverAddress": "10.0.1.149:443"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -199,4 +205,4 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -226,7 +226,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 represents 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 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.
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ life.
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=kube-system
|
||||
NAME READY REASON RESTARTS AGE
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
|
||||
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
|
||||
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
|
||||
|
||||
Reference in New Issue
Block a user