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

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
steveperry-53
2017-09-14 10:14:57 -07:00
parent 90d95e7ab2 6da3922bb5
commit ed363f786c
76 changed files with 2168 additions and 930 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/architecture/nodes.md
+1
View File
@@ -51,6 +51,7 @@ The `conditions` field describes the status of all `Running` nodes.
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last 40 seconds |
| `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` |
| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
The node condition is represented as a JSON object. For example, the following response describes a healthy node.
docs/concepts/cluster-administration/addons.md
+4
View File
@@ -21,6 +21,10 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
* [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.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Flannel, Calico, Canal, Romana, or Weave.
## Service Discovery
* [CoreDNS](https://coredns.io) is a flexible, extensible DNS server which can be [installed](https://github.com/coredns/deployment/tree/master/kubernetes) as the in-cluster DNS for pods.
## Visualization & Control
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes.
docs/concepts/cluster-administration/cloud-providers.md
+1 -1
View File
@@ -44,7 +44,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix.
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`.
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used.
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining.
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+1 -1
View File
@@ -50,7 +50,7 @@ credentials of the user listed in the current context.
## The KUBECONFIG environment variable
The `KUBECONGIG` environment variable holds a list of kubeconfig files.
The `KUBECONFIG` environment variable holds a list of kubeconfig files.
For Linux and Mac, the list is colon-delimited. For Windows, the list
is semicolon-delimited. The `KUBECONFIG` environment variable is not
required. If the `KUBECONFIG` environment variable doesn't exist,
docs/concepts/configuration/secret.md
+187 -295
View File
@@ -182,32 +182,23 @@ To consume a Secret in a volume in a Pod:
This is an example of a pod that mounts a secret in a volume:
```json
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "mypod",
"namespace": "myns"
},
"spec": {
"containers": [{
"name": "mypod",
"image": "redis",
"volumeMounts": [{
"name": "foo",
"mountPath": "/etc/foo",
"readOnly": true
}]
}],
"volumes": [{
"name": "foo",
"secret": {
"secretName": "mysecret"
}
}]
}
}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
```
Each secret you want to use needs to be referred to in `spec.volumes`.
@@ -222,36 +213,26 @@ You can package many files into one secret, or use many secrets, whichever is co
We can also control the paths within the volume where Secret keys are projected.
You can use `spec.volumes[].secret.items` field to change target path of each key:
```json
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "mypod",
"namespace": "myns"
},
"spec": {
"containers": [{
"name": "mypod",
"image": "redis",
"volumeMounts": [{
"name": "foo",
"mountPath": "/etc/foo",
"readOnly": true
}]
}],
"volumes": [{
"name": "foo",
"secret": {
"secretName": "mysecret",
"items": [{
"key": "username",
"path": "my-group/my-username"
}]
}
}]
}
}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
```
What will happen:
@@ -271,32 +252,23 @@ mode for the whole secret volume and override per key if needed.
For example, you can specify a default mode like this:
```json
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "mypod",
"namespace": "myns"
},
"spec": {
"containers": [{
"name": "mypod",
"image": "redis",
"volumeMounts": [{
"name": "foo",
"mountPath": "/etc/foo"
}]
}],
"volumes": [{
"name": "foo",
"secret": {
"secretName": "mysecret",
"defaultMode": 256
}
}]
}
}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: mysecret
defaultMode: 256
```
Then, the secret will be mounted on `/etc/foo` and all the files created by the
@@ -309,36 +281,26 @@ notation to specify permissions in a more natural way.
You can also use mapping, as in the previous example, and specify different
permission for different files like this:
```json
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "mypod",
"namespace": "myns"
},
"spec": {
"containers": [{
"name": "mypod",
"image": "redis",
"volumeMounts": [{
"name": "foo",
"mountPath": "/etc/foo"
}]
}],
"volumes": [{
"name": "foo",
"secret": {
"secretName": "mysecret",
"items": [{
"key": "username",
"path": "my-group/my-username",
"mode": 511
}]
}
}]
}
}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
volumes:
- name: foo
secret:
secretName: mysecret
items:
- key: username
path: my-group/my-username
mode: 511
```
In this case, the file resulting in `/etc/foo/my-group/my-username` will have
@@ -393,19 +355,19 @@ metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
restartPolicy: Never
```
@@ -515,40 +477,25 @@ $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/
Now we can create a pod which references the secret with the ssh key and
consumes it in a volume:
```json
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "secret-test-pod",
"labels": {
"name": "secret-test"
}
},
"spec": {
"volumes": [
{
"name": "secret-volume",
"secret": {
"secretName": "ssh-key-secret"
}
}
],
"containers": [
{
"name": "ssh-test-container",
"image": "mySshImage",
"volumeMounts": [
{
"name": "secret-volume",
"readOnly": true,
"mountPath": "/etc/secret-volume"
}
]
}
]
}
}
```yaml
kind: Pod
apiVersion: v1
metadata:
name: secret-test-pod
labels:
name: secret-test
spec:
volumes:
- name: secret-volume
secret:
secretName: ssh-key-secret
containers:
- name: ssh-test-container
image: mySshImage
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"
```
When the container's command runs, the pieces of the key will be available in:
@@ -577,78 +524,46 @@ secret "test-db-secret" created
Now make the pods:
```json
{
"apiVersion": "v1",
"kind": "List",
"items":
[{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "prod-db-client-pod",
"labels": {
"name": "prod-db-client"
}
},
"spec": {
"volumes": [
{
"name": "secret-volume",
"secret": {
"secretName": "prod-db-secret"
}
}
],
"containers": [
{
"name": "db-client-container",
"image": "myClientImage",
"volumeMounts": [
{
"name": "secret-volume",
"readOnly": true,
"mountPath": "/etc/secret-volume"
}
]
}
]
}
},
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "test-db-client-pod",
"labels": {
"name": "test-db-client"
}
},
"spec": {
"volumes": [
{
"name": "secret-volume",
"secret": {
"secretName": "test-db-secret"
}
}
],
"containers": [
{
"name": "db-client-container",
"image": "myClientImage",
"volumeMounts": [
{
"name": "secret-volume",
"readOnly": true,
"mountPath": "/etc/secret-volume"
}
]
}
]
}
}]
}
```yaml
apiVersion: v1
kind: List
items:
- kind: Pod
apiVersion: v1
metadata:
name: prod-db-client-pod
labels:
name: prod-db-client
spec:
volumes:
- name: secret-volume
secret:
secretName: prod-db-secret
containers:
- name: db-client-container
image: myClientImage
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"
- kind: Pod
apiVersion: v1
metadata:
name: test-db-client-pod
labels:
name: test-db-client
spec:
volumes:
- name: secret-volume
secret:
secretName: test-db-secret
containers:
- name: db-client-container
image: myClientImage
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"
```
Both containers will have the following files present on their filesystems with the values for each container's environment:
@@ -665,26 +580,18 @@ You could further simplify the base pod specification by using two Service Accou
one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
`test-user` with the `test-db-secret`. Then, the pod spec can be shortened to, for example:
```json
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "prod-db-client-pod",
"labels": {
"name": "prod-db-client"
}
},
"spec": {
"serviceAccount": "prod-db-client",
"containers": [
{
"name": "db-client-container",
"image": "myClientImage"
}
]
}
}
```yaml
kind: Pod
apiVersion: v1
metadata:
name: prod-db-client-pod
labels:
name: prod-db-client
spec:
serviceAccount: prod-db-client
containers:
- name: db-client-container
image: myClientImage
```
### Use-case: Dotfiles in secret volume
@@ -692,49 +599,34 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply
make that key begin with a dot. For example, when the following secret is mounted into a volume:
```json
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "dotfile-secret"
},
"data": {
".secret-file": "dmFsdWUtMg0KDQo="
}
}
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "secret-dotfiles-pod"
},
"spec": {
"volumes": [
{
"name": "secret-volume",
"secret": {
"secretName": "dotfile-secret"
}
}
],
"containers": [
{
"name": "dotfile-test-container",
"image": "gcr.io/google_containers/busybox",
"command": [ "ls", "-l", "/etc/secret-volume" ],
"volumeMounts": [
{
"name": "secret-volume",
"readOnly": true,
"mountPath": "/etc/secret-volume"
}
]
}
]
}
}
```yaml
kind: Secret
apiVersion: v1
metadata:
name: dotfile-secret
data:
.secret-file: dmFsdWUtMg0KDQo=
---
kind: Pod
apiVersion: v1
metadata:
name: secret-dotfiles-pod
spec:
volumes:
- name: secret-volume
secret:
secretName: dotfile-secret
containers:
- name: dotfile-test-container
image: gcr.io/google_containers/busybox
command:
- ls
- "-l"
- "/etc/secret-volume"
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"
```
@@ -798,7 +690,7 @@ reference a secret then `watch` the resource, re-requesting the secret when the
reference changes. Additionally, a ["bulk watch" API](
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md)
to let clients `watch` individual resources has also been proposed, and will likely
be available in future releases of Kubernetes.
be available in future releases of Kubernetes.
## Security Properties
docs/concepts/services-networking/service.md
+10 -10
View File
@@ -479,25 +479,25 @@ metadata:
{% include tabs.md %}
#### SSL support on AWS
For partial SSL support on clusters running on AWS, starting with 1.3 two
For partial SSL support on clusters running on AWS, starting with 1.3 three
annotations can be added to a `LoadBalancer` service:
```
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
```
The first specifies which certificate to use. It can be either a
The first specifies the ARN of the certificate to use. It can be either a
certificate from a third party issuer that was uploaded to IAM or one created
within AWS Certificate Manager.
```yaml
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
```
The second annotation specifies which protocol a pod speaks. For HTTPS and
docs/concepts/storage/persistent-volumes.md
+28 -23
View File
@@ -86,7 +86,7 @@ However, an administrator can configure a custom recycler pod template using the
apiVersion: v1
kind: Pod
metadata:
name: pv-recycler-
name: pv-recycler
namespace: default
spec:
restartPolicy: Never
@@ -128,7 +128,7 @@ For volume plugins that support the Delete reclaim policy, deletion removes both
* Glusterfs
* VsphereVolume
* Quobyte Volumes
* HostPath (single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
* HostPath (Single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
* VMware Photon
* Portworx Volumes
* ScaleIO Volumes
@@ -223,7 +223,7 @@ it will become fully deprecated in a future Kubernetes release.
Current reclaim policies are:
* Retain -- manual reclamation
* Recycle -- basic scrub ("rm -rf /thevolume/*")
* Recycle -- basic scrub (`rm -rf /thevolume/*`)
* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted
Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion.
@@ -232,7 +232,7 @@ Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk,
A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
**Note:** Not all Persistent volume types support mount options.
**Note:** Not all Persistent volume types support mount options.
{: .note}
The following volume types support mount options:
@@ -341,7 +341,7 @@ to Kubernetes cluster by addon manager during installation.
When a PVC specifies a `selector` in addition to requesting a `StorageClass`,
the requirements are ANDed together: only a PV of the requested class and with
the requested labels may be bound to the PVC.
the requested labels may be bound to the PVC.
**Note:** Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
{: .note}
@@ -574,6 +574,7 @@ parameters:
#### vSphere
1. Create a persistent volume with a user specified disk format.
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
@@ -587,9 +588,10 @@ parameters:
- `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
2. Create a persistent volume with a disk format on a user specified datastore.
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
@@ -602,9 +604,10 @@ parameters:
- `datastore`: The user can also specify the datastore in the Storageclass. The volume will be created on the datastore specified in the storage class which in this case is `VSANDatastore`. This field is optional. If not specified as in previous YAML description, the volume will be created on the datastore specified in the vsphere config file used to initialize the vSphere Cloud Provider.
3. Create a persistent volume with user specified VSAN storage capabilities.
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
apiVersion: storage.k8s.io/v1
metadata:
name: vsan-policy-fast
provisioner: kubernetes.io/vsphere-volume
@@ -636,22 +639,22 @@ You can see [vSphere example](https://github.com/kubernetes/examples/tree/master
#### Ceph RBD
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/rbd
parameters:
monitors: 10.16.153.105:6789
adminId: kube
adminSecretName: ceph-secret
adminSecretNamespace: kube-system
pool: kube
userId: kube
userSecretName: ceph-secret-user
fsType: ext4
imageFormat: "2"
imageFeatures: "layering"
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: kubernetes.io/rbd
parameters:
monitors: 10.16.153.105:6789
adminId: kube
adminSecretName: ceph-secret
adminSecretNamespace: kube-system
pool: kube
userId: kube
userSecretName: ceph-secret-user
fsType: ext4
imageFormat: "2"
imageFeatures: "layering"
```
* `monitors`: Ceph monitors, comma delimited. This parameter is required.
@@ -782,6 +785,7 @@ parameters:
* `ephemeral`: specifies whether the volume should be cleaned-up after unmount or should be persistent. `emptyDir` use case can set this value to true and `persistent volumes` use case such as for databases like Cassandra should set to false, [true/false] (default `false`). A string is expected here i.e. `"true"` and not `true`.
#### ScaleIO
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
@@ -818,6 +822,7 @@ $> kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" --fro
```
#### StorageOS
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
docs/concepts/storage/volumes.md
+4
View File
@@ -851,4 +851,8 @@ several media types.
{% endcapture %}
{% capture whatsnext %}
* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/controllers/deployment.md
+10 -7
View File
@@ -41,15 +41,18 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
In this example:
* A Deployment named `nginx` is created.
* The `nginx` Deployment creates three replicated Pods.
* The Pods are created from the `template` field.
* A Deployment named `nginx` is created, indicated by the `metadata: name` field.
* The Deployment creates three replicated Pods, indicated by the `replicas` field.
* The Pod template's specification, or `template: spec` field, indicates that
the Pods run one container, `nginx`, which runs the `nginx`
[Docker Hub](https://hub.docker.com/) image at version 1.7.9.
* The Deployment opens port 80 for use by the Pods.
The `template` field contains the following instructions:
* Create one container in each Pod.
* Label the container `app: nginx`.
* Run the [Docker Hub](https://hub.docker.com) image `nginx` at version `1.7.9`.
* The Pods are labeled `app: nginx`
* Create one container and name it `nginx`.
* Run the `nginx` image at version `1.7.9`.
* Open port `80` so that the container can send and accept traffic.
To create this Deployment, run the following command:
@@ -112,7 +115,7 @@ NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 3 18s
```
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPALTE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created.
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created.
To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned:
docs/concepts/workloads/controllers/statefulset.md
+1
View File
@@ -226,6 +226,7 @@ update, roll out a canary, or perform a phased roll out.
{% capture whatsnext %}
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set).
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
{% endcapture %}
{% include templates/concept.md %}
docs/concepts/workloads/pods/init-containers.md
+3 -3
View File
@@ -151,7 +151,7 @@ spec:
Yaml file below outlines the `mydb` and `myservice` services:
```
```yaml
kind: Service
apiVersion: v1
metadata:
@@ -175,7 +175,7 @@ spec:
This Pod can be started and debugged with the following commands:
```
```shell
$ kubectl create -f myapp.yaml
pod "myapp-pod" created
$ kubectl get -f myapp.yaml
@@ -221,7 +221,7 @@ $ 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
complete and the `myapp-pod` is created:
```
```shell
$ kubectl create -f services.yaml
service "myservice" created
service "mydb" created