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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user