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

Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.8

Browse Source 
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  ZTE-SH-CN-debug-pod-replication-controller-2017-09-14-14
  ZTE-SH-CN-define-command-argument-container (#5381)
  Update index.md
  Update Kompose docs
  Improve host aliases page (#5443)
  Add link to AlwaysPullImages admission controller
  Revert "create homepage for user journeys"
  create homepage for user journeys
  fix the command output
  ZTE-SH-CN-run-application-run-single-instance-stateful-application-pr-2017-… (#5363)
  Add a note to static pod manifest scanning
  revert WordPress and MySQL PV doc changes to use apps/v1beta2 APIs (#5461)
  Fix pod probes yaml file
  Redirect v1 docs. (#5460)
  Fix error link (#5459)
  Fix typo in deployment documentation

# Conflicts:
#	docs/tutorials/stateful-application/basic-stateful-set.md
This commit is contained in:
Andrew Chen
2017-09-15 17:19:32 -07:00
parent 5b9b63454b 82ac9251fd
commit a60b2d3045
19 changed files with 833 additions and 254 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/containers/images.md
+7 -4
View File
@@ -19,10 +19,13 @@ The `image` property of a container supports the same syntax as the `docker` com
## Updating Images
The default pull policy is `IfNotPresent` which causes the Kubelet to not
pull an image if it already exists. If you would like to always force a pull
you must set a pull image policy of `Always` or specify a `:latest` tag on
your image.
The default pull policy is `IfNotPresent` which causes the Kubelet to skip
pulling an image if it already exists. If you would like to always force a pull,
you can do one of the following:
- set the `imagePullPolicy` of the container to `Always`;
- use `:latest` as the tag for the image to use;
- enable the [AllwaysPullImages](/docs/admin/admission-controllers/#alwayspullimages) admission controller.
If you did not specify tag of your image, it will be assumed as `:latest`, with
pull image policy of `Always` correspondingly.
docs/concepts/overview/components.md
+3 -3
View File
@@ -27,7 +27,7 @@ Kubernetes control plane. It is designed to scale horizontally -- that is, it sc
### etcd
[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
[etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
### kube-controller-manager
@@ -84,12 +84,12 @@ Containers started by Kubernetes automatically include this DNS server in their
#### Container Resource Monitoring
[Container Resource Monitoring](/docs/user-guide/monitoring) records generic time-series metrics
[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring) records generic time-series metrics
about containers in a central database, and provides a UI for browsing that data.
#### Cluster-level Logging
A [Cluster-level logging](/docs/user-guide/logging/overview) mechanism is responsible for
A [Cluster-level logging](/docs/concepts/cluster-administration/logging) mechanism is responsible for
saving container logs to a central log store with search/browsing interface.
## Node components
docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+21 -4
View File
@@ -15,14 +15,19 @@ Modification not using HostAliases is not suggested because the file is managed
## Default Hosts File Content
Lets start an Nginx Pod which is assigned an Pod IP:
```
```shell
$ kubectl run nginx --image nginx --generator=run-pod/v1
pod "nginx" created
$ kubectl get pods --output=wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
The hosts file content would look like this:
```
```shell
$ kubectl exec nginx -- cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
@@ -42,8 +47,20 @@ In addition to the default boilerplate, we can add additional entries to the hos
{% include code.html language="yaml" file="hostaliases-pod.yaml" ghlink="/docs/concepts/services-networking/hostaliases-pod.yaml" %}
The hosts file content would look like this:
This Pod can be started with the following commands:
```shell
$ kubectl apply -f hostaliases-pod.yaml
pod "hostaliases-pod" created
$ kubectl get pod -a -o=wide
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.244.135.10 node3
```
The hosts file content would look like this:
```shell
$ kubectl logs hostaliases-pod
# Kubernetes-managed hosts file.
127.0.0.1 localhost
@@ -52,7 +69,7 @@ fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.200.0.4 hostaliases-pod
10.244.135.10 hostaliases-pod
127.0.0.1 foo.local
127.0.0.1 bar.local
10.1.2.3 foo.remote
docs/concepts/services-networking/hostaliases-pod.yaml
+1
View File
@@ -3,6 +3,7 @@ kind: Pod
metadata:
name: hostaliases-pod
spec:
restartPolicy: Never
hostAliases:
- ip: "127.0.0.1"
hostnames:
docs/concepts/workloads/controllers/deployment.md
+1 -1
View File
@@ -115,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-TEMPLATE-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 Deployment is created.
To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned:
docs/getting-started-guides/windows/index.md
+16 -16
View File
@@ -9,10 +9,10 @@ Kubernetes version 1.5 introduces support for Windows Server Containers. In vers
## Prerequisites
In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported using the following:
1. Kubernetes control plane running on existing Linux infrastructure (version 1.5 or later)
2. Kubenet network plugin setup on the Linux nodes
3. Windows Server 2016 (RTM version 10.0.14393 or later)
4. Docker Version 1.12.2-cs2-ws-beta or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version)
1. Kubernetes control plane running on existing Linux infrastructure (version 1.5 or later).
2. Kubenet network plugin setup on the Linux nodes.
3. Windows Server 2016 (RTM version 10.0.14393 or later).
4. Docker Version 1.12.2-cs2-ws-beta or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version).
## Networking
Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don't natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used.
@@ -24,11 +24,11 @@ The above networking approach is already supported on Linux using a bridge inter
Each Window Server node should have the following configuration:
1. Two NICs (virtual networking adapters) are required on each Windows Server node - The two Windows container networking modes of interest (transparent and L2 bridge) use an external Hyper-V virtual switch. This means that one of the NICs is entirely allocated to the bridge, creating the need for the second NIC.
2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below
3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes
4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below
2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below.
3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes.
4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below.
The following diagram illustrates the Windows Server networking setup for Kubernetes Setup
The following diagram illustrates the Windows Server networking setup for Kubernetes Setup:
![Windows Setup](windows-setup.png)
## Setting up Windows Server Containers on Kubernetes
@@ -37,10 +37,10 @@ To run Windows Server Containers on Kubernetes, you'll need to set up both your
### Host Setup
**Windows Host Setup**
1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server
2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/)
3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause`
4. RRAS (Routing) Windows feature enabled
1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server.
2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/).
3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause`.
4. RRAS (Routing) Windows feature enabled.
5. Install a VMSwitch of type `Internal`, by running `New-VMSwitch -Name KubeProxySwitch -SwitchType Internal` command in *PowerShell* window. This will create a new Network Interface with name `vEthernet (KubeProxySwitch)`. This interface will be used by kube-proxy to add Service IPs.
**Linux Host Setup**
@@ -117,7 +117,7 @@ To start your cluster, you'll need to start both the Linux-based Kubernetes cont
Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated.
## Starting the Windows Node Components
To start kubelet on your Windows node:
Run the following in a PowerShell window. Be aware that if the node reboots or the process exits, you will have to rerun the commands below to restart the kubelet
Run the following in a PowerShell window. Be aware that if the node reboots or the process exits, you will have to rerun the commands below to restart the kubelet.
1. Set environment variable *CONTAINER_NETWORK* value to the docker container network to use
`$env:CONTAINER_NETWORK = "<docker network>"`
@@ -168,7 +168,7 @@ Because your cluster has both Linux and Windows nodes, you must explicitly set t
```
## Known Limitations:
1. There is no network namespace in Windows and as a result currently only one container per pod is supported
2. Secrets currently do not work because of a bug in Windows Server Containers described [here](https://github.com/docker/docker/issues/28401)
1. There is no network namespace in Windows and as a result currently only one container per pod is supported.
2. Secrets currently do not work because of a bug in Windows Server Containers described [here](https://github.com/docker/docker/issues/28401).
3. ConfigMaps have not been implemented yet.
4. `kube-proxy` implementation uses `netsh portproxy` and as it only supports TCP, DNS currently works only if the client retries DNS query using TCP
4. `kube-proxy` implementation uses `netsh portproxy` and as it only supports TCP, DNS currently works only if the client retries DNS query using TCP.
docs/tasks/administer-cluster/static-pod.md
+1
View File
@@ -17,6 +17,7 @@ Static pod can be created in two ways: either by using configuration file(s) or
### Configuration files
The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
Note that kubelet will ignore files starting with dots when scanning the specified directory.
For example, this is how to start a simple web server as a static pod:
docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
+1 -1
View File
@@ -65,7 +65,7 @@ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-livenes
Within 30 seconds, view the Pod events:
```
```shell
kubectl describe pod liveness-exec
```
docs/tasks/configure-pod-container/exec-liveness.yaml
+1 -6
View File
@@ -1,22 +1,17 @@
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: gcr.io/google_containers/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
image: gcr.io/google_containers/busybox
livenessProbe:
exec:
command:
docs/tasks/configure-pod-container/http-liveness.yaml
+1 -5
View File
@@ -6,14 +6,10 @@ metadata:
name: liveness-http
spec:
containers:
- name: liveness
image: gcr.io/google_containers/liveness
args:
- /server
image: gcr.io/google_containers/liveness
livenessProbe:
httpGet:
path: /healthz
docs/tools/kompose/user-guide.md
+332 -194
View File
@@ -1,208 +1,307 @@
---
approvers:
assignees:
- cdrage
title: Translate a Docker Compose File to Kubernetes Resources
redirect_from:
- "/docs/tools/kompose/"
- "/docs/tools/kompose/index.html"
---
* TOC
{:toc}
`kompose` is a tool to help users who are familiar with `docker-compose` move to **Kubernetes**. `kompose` takes a Docker Compose file and translates it into Kubernetes resources.
# Kubernetes + Compose = Kompose
More information about Kompose can be found on the official [http://kompose.io](http://kompose.io/) site.
What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift).
`kompose` is a convenience tool to go from local Docker development to managing your application with Kubernetes. Transformation of the Docker Compose format to Kubernetes resources manifest may not be exact, but it helps tremendously when first deploying an application on Kubernetes.
More information can be found our website at [http://kompose.io](http://kompose.io)
## Use Case
In three simple steps, we'll take you from Docker Compose to Kubernetes.
If you have a Docker Compose `docker-compose.yml` or a Docker Distributed Application Bundle `docker-compose-bundle.dab` file, you can convert it into Kubernetes deployments and services like this:
__1. Take a sample docker-compose.yaml file__
```console
$ kompose -f docker-compose.yml convert
WARN: Unsupported key networks - ignoring
file "redis-svc.yaml" created
file "web-svc.yaml" created
file "web-deployment.yaml" created
file "redis-deployment.yaml" created
```yaml
version: "2"
services:
redis-master:
image: gcr.io/google_containers/redis:e2e
ports:
- "6379"
redis-slave:
image: gcr.io/google_samples/gb-redisslave:v1
ports:
- "6379"
environment:
- GET_HOSTS_FROM=dns
frontend:
image: gcr.io/google-samples/gb-frontend:v4
ports:
- "80:80"
environment:
- GET_HOSTS_FROM=dns
labels:
kompose.service.type: LoadBalancer
```
## Installation
__2. Run `kompose up` in the same directory__
We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release.
```bash
$ kompose up
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
### GitHub release
INFO Successfully created Service: redis
INFO Successfully created Service: web
INFO Successfully created Deployment: redis
INFO Successfully created Deployment: web
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
```
__Alternatively, you can run `kompose convert` and deploy with `kubectl`__
__2.1. Run `kompose convert` in the same directory__
```bash
$ kompose convert
INFO Kubernetes file "frontend-service.yaml" created
INFO Kubernetes file "redis-master-service.yaml" created
INFO Kubernetes file "redis-slave-service.yaml" created
INFO Kubernetes file "frontend-deployment.yaml" created
INFO Kubernetes file "redis-master-deployment.yaml" created
INFO Kubernetes file "redis-slave-deployment.yaml" created
```
__2.2. And start it on Kubernetes!__
```bash
$ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
service "frontend" created
service "redis-master" created
service "redis-slave" created
deployment "frontend" created
deployment "redis-master" created
deployment "redis-slave" created
```
__3. View the newly deployed service__
Now that your service has been deployed, let's access it.
If you're already using `minikube` for your development process:
```bash
$ minikube service frontend
```
Otherwise, let's look up what IP your service is using!
```sh
$ kubectl describe svc frontend
Name: frontend
Namespace: default
Labels: service=frontend
Selector: service=frontend
Type: LoadBalancer
IP: 10.0.0.183
LoadBalancer Ingress: 123.45.67.89
Port: 80 80/TCP
NodePort: 80 31144/TCP
Endpoints: 172.17.0.4:80
Session Affinity: None
No events.
```
If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.
```sh
$ curl http://123.45.67.89
```
# Installation
We have multiple ways to install Kompose. Our prefered method is downloading the binary from the latest GitHub release.
#### GitHub release
Kompose is released via GitHub on a three-week cycle, you can see all current releases on the [GitHub release page](https://github.com/kubernetes/kompose/releases).
The current release we use is `1.0.0`.
```sh
# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.0.0/kompose-linux-amd64 -o kompose
# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-linux-amd64 -o kompose
# macOS
curl -L https://github.com/kubernetes/kompose/releases/download/v1.0.0/kompose-darwin-amd64 -o kompose
curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-darwin-amd64 -o kompose
# Windows
curl -L https://github.com/kubernetes/kompose/releases/download/v1.0.0/kompose-windows-amd64.exe -o kompose.exe
```
curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-windows-amd64.exe -o kompose.exe
Make the binary executable and move it to your PATH (e.g. `/usr/local/bin`)
```sh
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose
```
## Kompose convert
Alternatively, you can download the [tarball](https://github.com/kubernetes/kompose/releases).
Currently Kompose supports to transform either Docker Compose file (both of v1 and v2) and [experimental Distributed Application Bundles](https://blog.docker.com/2016/06/docker-app-bundle/) into Kubernetes and OpenShift objects.
There is a couple of sample files in the `examples/` directory for testing.
You will convert the compose or dab file to Kubernetes or OpenShift objects with `kompose convert`.
#### Go
### Kubernetes
```console
$ cd examples/
Installing using `go get` pulls from the master branch with the latest development changes.
$ ls
docker-compose.yml docker-compose-bundle.dab docker-gitlab.yml docker-voting.yml
$ kompose -f docker-gitlab.yml convert
file "redisio-svc.yaml" created
file "gitlab-svc.yaml" created
file "postgresql-svc.yaml" created
file "gitlab-deployment.yaml" created
file "postgresql-deployment.yaml" created
file "redisio-deployment.yaml" created
$ ls *.yaml
gitlab-deployment.yaml postgresql-deployment.yaml redis-deployment.yaml redisio-svc.yaml web-deployment.yaml
gitlab-svc.yaml postgresql-svc.yaml redisio-deployment.yaml redis-svc.yaml web-svc.yaml
```sh
go get -u github.com/kubernetes/kompose
```
You can try with a Docker Compose version 2 like this:
#### CentOS
```console
Kompose is in [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS repository.
If you don't have [EPEL](https://fedoraproject.org/wiki/EPEL) repository already installed and enabled you can do it by running `sudo yum install epel-release`
If you have [EPEL](https://fedoraproject.org/wiki/EPEL) enabled in your system, you can install Kompose like any other package.
```bash
sudo yum -y install kompose
```
#### Fedora
Kompose is in Fedora 24, 25 and 26 repositories. You can install it just like any other package.
```bash
sudo dnf -y install kompose
```
#### macOS
On macOS you can install latest release via [Homebrew](https://brew.sh):
```bash
brew install kompose
```
# User Guide
- CLI
- [`kompose convert`](#kompose-convert)
- [`kompose up`](#kompose-up)
- [`kompose down`](#kompose-down)
- Documentation
- [Build and Push Docker Images](#build-and-push-docker-images)
- [Alternative Conversions](#alternative-conversions)
- [Labels](#labels)
- [Restart](#restart)
- [Docker Compose Versions](#docker-compose-versions)
Kompose has support for two providers: OpenShift and Kubernetes.
You can choose a targeted provider using global option `--provider`. If no provider is specified, Kubernetes is set by default.
## `kompose convert`
Kompose supports conversion of V1, V2, and V3 Docker Compose files into Kubernetes and OpenShift objects.
### Kubernetes
```sh
$ kompose --file docker-voting.yml convert
WARN Unsupported key networks - ignoring
WARN Unsupported key build - ignoring
file "worker-svc.yaml" created
file "db-svc.yaml" created
file "redis-svc.yaml" created
file "result-svc.yaml" created
file "vote-svc.yaml" created
file "redis-deployment.yaml" created
file "result-deployment.yaml" created
file "vote-deployment.yaml" created
file "worker-deployment.yaml" created
file "db-deployment.yaml" created
INFO Kubernetes file "worker-svc.yaml" created
INFO Kubernetes file "db-svc.yaml" created
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "result-svc.yaml" created
INFO Kubernetes file "vote-svc.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
INFO Kubernetes file "result-deployment.yaml" created
INFO Kubernetes file "vote-deployment.yaml" created
INFO Kubernetes file "worker-deployment.yaml" created
INFO Kubernetes file "db-deployment.yaml" created
$ ls
db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml
db-svc.yaml docker-compose-bundle.dab docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml
db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml
```
You can also provide multiple docker-compose files at the same time:
```console
```sh
$ kompose -f docker-compose.yml -f docker-guestbook.yml convert
file "frontend-service.yaml" created
file "mlbparks-service.yaml" created
file "mongodb-service.yaml" created
file "redis-master-service.yaml" created
file "redis-slave-service.yaml" created
file "frontend-deployment.yaml" created
file "mlbparks-deployment.yaml" created
file "mongodb-deployment.yaml" created
file "mongodb-claim0-persistentvolumeclaim.yaml" created
file "redis-master-deployment.yaml" created
file "redis-slave-deployment.yaml" created
INFO Kubernetes file "frontend-service.yaml" created
INFO Kubernetes file "mlbparks-service.yaml" created
INFO Kubernetes file "mongodb-service.yaml" created
INFO Kubernetes file "redis-master-service.yaml" created
INFO Kubernetes file "redis-slave-service.yaml" created
INFO Kubernetes file "frontend-deployment.yaml" created
INFO Kubernetes file "mlbparks-deployment.yaml" created
INFO Kubernetes file "mongodb-deployment.yaml" created
INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
INFO Kubernetes file "redis-master-deployment.yaml" created
INFO Kubernetes file "redis-slave-deployment.yaml" created
$ ls
mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml
mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml
frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml
frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml
redis-master-deployment.yaml
```
When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be overridden by subsequent file.
Using `--bundle, --dab` to specify a DAB file as below:
```console
$ kompose --bundle docker-compose-bundle.dab convert
WARN: Unsupported key networks - ignoring
file "redis-svc.yaml" created
file "web-svc.yaml" created
file "web-deployment.yaml" created
file "redis-deployment.yaml" created
```
```
When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be over ridden by subsequent file.
### OpenShift
```console
```sh
$ kompose --provider openshift --file docker-voting.yml convert
WARN [worker] Service cannot be created because of missing port.
INFO file "vote-service.yaml" created
INFO file "db-service.yaml" created
INFO file "redis-service.yaml" created
INFO file "result-service.yaml" created
INFO file "vote-deploymentconfig.yaml" created
INFO file "vote-imagestream.yaml" created
INFO file "worker-deploymentconfig.yaml" created
INFO file "worker-imagestream.yaml" created
INFO file "db-deploymentconfig.yaml" created
INFO file "db-imagestream.yaml" created
INFO file "redis-deploymentconfig.yaml" created
INFO file "redis-imagestream.yaml" created
INFO file "result-deploymentconfig.yaml" created
INFO file "result-imagestream.yaml" created
```
In similar way you can convert DAB files to OpenShift.
```console
$ kompose --bundle docker-compose-bundle.dab --provider openshift convert
WARN: Unsupported key networks - ignoring
INFO file "redis-svc.yaml" created
INFO file "web-svc.yaml" created
INFO file "web-deploymentconfig.yaml" created
INFO file "web-imagestream.yaml" created
INFO file "redis-deploymentconfig.yaml" created
INFO file "redis-imagestream.yaml" created
INFO OpenShift file "vote-service.yaml" created
INFO OpenShift file "db-service.yaml" created
INFO OpenShift file "redis-service.yaml" created
INFO OpenShift file "result-service.yaml" created
INFO OpenShift file "vote-deploymentconfig.yaml" created
INFO OpenShift file "vote-imagestream.yaml" created
INFO OpenShift file "worker-deploymentconfig.yaml" created
INFO OpenShift file "worker-imagestream.yaml" created
INFO OpenShift file "db-deploymentconfig.yaml" created
INFO OpenShift file "db-imagestream.yaml" created
INFO OpenShift file "redis-deploymentconfig.yaml" created
INFO OpenShift file "redis-imagestream.yaml" created
INFO OpenShift file "result-deploymentconfig.yaml" created
INFO OpenShift file "result-imagestream.yaml" created
```
It also supports creating buildconfig for build directive in a service. By default, it uses the remote repo for the current git branch as the source repo, and the current branch as the source branch for the build. You can specify a different source repo and branch using ``--build-repo`` and ``--build-branch`` options respectively.
```console
```sh
$ kompose --provider openshift --file buildconfig/docker-compose.yml convert
WARN [foo] Service cannot be created because of missing port.
INFO Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
INFO file "foo-deploymentconfig.yaml" created
INFO file "foo-imagestream.yaml" created
INFO file "foo-buildconfig.yaml" created
WARN [foo] Service cannot be created because of missing port.
INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
INFO OpenShift file "foo-deploymentconfig.yaml" created
INFO OpenShift file "foo-imagestream.yaml" created
INFO OpenShift file "foo-buildconfig.yaml" created
```
**Note**: If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 .
## Kompose up
## `kompose up`
Kompose supports a straightforward way to deploy your "composed" application to Kubernetes or OpenShift via `kompose up`.
### Kubernetes
```console
```sh
$ kompose --file ./examples/docker-guestbook.yml up
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created deployment: frontend
INFO Successfully created deployment: frontend
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
@@ -228,18 +327,18 @@ Note:
- Only deployments and services are generated and deployed to Kubernetes. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
### OpenShift
```console
$kompose --file ./examples/docker-guestbook.yml --provider openshift up
```sh
$ kompose --file ./examples/docker-guestbook.yml --provider openshift up
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created service: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created ImageStream: redis-slave
INFO Successfully created deployment: frontend
INFO Successfully created ImageStream: frontend
INFO Successfully created deployment: frontend
INFO Successfully created ImageStream: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created ImageStream: redis-master
@@ -255,71 +354,118 @@ svc/frontend 172.30.46.64 <none> 80/TCP
svc/redis-master 172.30.144.56 <none> 6379/TCP 8s
svc/redis-slave 172.30.75.245 <none> 6379/TCP 8s
NAME DOCKER REPO TAGS UPDATED
is/frontend 172.30.12.200:5000/fff/frontend
is/redis-master 172.30.12.200:5000/fff/redis-master
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
is/frontend 172.30.12.200:5000/fff/frontend
is/redis-master 172.30.12.200:5000/fff/redis-master
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
```
Note:
- You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`)
## Kompose down
## `kompose down`
Once you have deployed "composed" application to Kubernetes, `kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
Once you have deployed "composed" application to Kubernetes, `$ kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
```console
```sh
$ kompose --file docker-guestbook.yml down
INFO Successfully deleted service: redis-master
INFO Successfully deleted service: redis-master
INFO Successfully deleted deployment: redis-master
INFO Successfully deleted service: redis-slave
INFO Successfully deleted service: redis-slave
INFO Successfully deleted deployment: redis-slave
INFO Successfully deleted service: frontend
INFO Successfully deleted service: frontend
INFO Successfully deleted deployment: frontend
```
Note:
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
## Alternate formats
## Build and Push Docker Images
The default `kompose` transformation will generate Kubernetes [Deployments](/docs/concepts/workloads/controllers/deployment/) and [Services](/docs/concepts/services-networking/service/), in yaml format. You have alternative option to generate json with `-j`. Also, you can alternatively generate [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) objects, [Daemon Sets](/docs/concepts/workloads/controllers/daemonset/), or [Helm](https://github.com/helm/helm) charts.
Kompose supports both building and pushing Docker images. When using the `build` key within your Docker Compose file, your image will:
```console
- Automatically be built with Docker using the `image` key specified within your file
- Be pushed to the correct Docker repository using local credentials (located at `.docker/config`)
Using an [example Docker Compose file](https://raw.githubusercontent.com/kubernetes/kompose/master/examples/buildconfig/docker-compose.yml):
```yaml
version: "2"
services:
foo:
build: "./build"
image: docker.io/foo/bar
```
Using `kompose up` with a `build` key:
```sh
$ kompose up
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
INFO Building image 'docker.io/foo/bar' from directory 'build'
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
INFO Attempting authentication credentials 'https://index.docker.io/v1/
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
INFO Deploying application in "default" namespace
INFO Successfully created Service: foo
INFO Successfully created Deployment: foo
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
```
In order to disable the functionality, or choose to use BuildConfig generation (with OpenShift) `--build (local|build-config|none)` can be passed.
```sh
# Disable building/pushing Docker images
$ kompose up --build none
# Generate Build Config artifacts for OpenShift
$ kompose up --provider openshift --build build-config
```
## Alternative Conversions
The default `kompose` transformation will generate Kubernetes [Deployments](http://kubernetes.io/docs/user-guide/deployments/) and [Services](http://kubernetes.io/docs/user-guide/services/), in yaml format. You have alternative option to generate json with `-j`. Also, you can alternatively generate [Replication Controllers](http://kubernetes.io/docs/user-guide/replication-controller/) objects, [Deamon Sets](http://kubernetes.io/docs/admin/daemons/), or [Helm](https://github.com/helm/helm) charts.
```sh
$ kompose convert -j
file "redis-svc.json" created
file "web-svc.json" created
file "redis-deployment.json" created
file "web-deployment.json" created
INFO Kubernetes file "redis-svc.json" created
INFO Kubernetes file "web-svc.json" created
INFO Kubernetes file "redis-deployment.json" created
INFO Kubernetes file "web-deployment.json" created
```
The `*-deployment.json` files contain the Deployment objects.
```console
$ kompose convert --rc
file "redis-svc.yaml" created
file "web-svc.yaml" created
file "redis-rc.yaml" created
file "web-rc.yaml" created
```sh
$ kompose convert --replication-controller
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-replicationcontroller.yaml" created
INFO Kubernetes file "web-replicationcontroller.yaml" created
```
The `*-rc.yaml` files contain the Replication Controller objects. If you want to specify replicas (default is 1), use `--replicas` flag: `$ kompose convert --rc --replicas 3`.
The `*-replicationcontroller.yaml` files contain the Replication Controller objects. If you want to specify replicas (default is 1), use `--replicas` flag: `$ kompose convert --replication-controller --replicas 3`
```console
$ kompose convert --ds
file "redis-svc.yaml" created
file "web-svc.yaml" created
file "redis-daemonset.yaml" created
file "web-daemonset.yaml" created
```sh
$ kompose convert --daemon-set
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-daemonset.yaml" created
INFO Kubernetes file "web-daemonset.yaml" created
```
The `*-daemonset.yaml` files contain the Daemon Set objects.
The `*-daemonset.yaml` files contain the Daemon Set objects
If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do:
```console
$ kompose convert -c
file "web-svc.yaml" created
file "redis-svc.yaml" created
file "web-deployment.yaml" created
file "redis-deployment.yaml" created
```sh
$ kompose convert -c
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-deployment.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
chart created in "./docker-compose/"
$ tree docker-compose/
@@ -335,28 +481,6 @@ docker-compose
The chart structure is aimed at providing a skeleton for building your Helm charts.
## Unsupported docker-compose configuration options
Currently `kompose` does not support some Docker Compose options, which are listed on the [conversion](http://kompose.io/conversion/) document.
For example:
```console
$ cat nginx.yml
nginx:
image: nginx
dockerfile: foobar
build: ./foobar
cap_add:
- ALL
container_name: foobar
$ kompose -f nginx.yml convert
WARN Unsupported key build - ignoring
WARN Unsupported key cap_add - ignoring
WARN Unsupported key dockerfile - ignoring
```
## Labels
`kompose` supports Kompose-specific labels within the `docker-compose.yml` file in order to explicitly define a service's behavior upon conversion.
@@ -367,7 +491,7 @@ For example:
```yaml
version: "2"
services:
services:
nginx:
image: nginx
dockerfile: foobar
@@ -375,7 +499,7 @@ services:
cap_add:
- ALL
container_name: foobar
labels:
labels:
kompose.service.type: nodeport
```
@@ -409,6 +533,7 @@ The currently supported options are:
| kompose.service.type | nodeport / clusterip / loadbalancer |
| kompose.service.expose| true / hostname |
**Note**: `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
## Restart
@@ -423,6 +548,8 @@ If you want to create normal pods without controllers you can use `restart` cons
**Note**: controller object could be `deployment` or `replicationcontroller`, etc.
For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
```yaml
version: '2'
@@ -433,5 +560,16 @@ services:
restart: "on-failure"
```
#### Warning about DeploymentConfig
#### Warning about Deployment Config's
If the Docker Compose file has a volume specified for a service, the Deployment (Kubernetes) or DeploymentConfig (OpenShift) strategy is changed to "Recreate" instead of "RollingUpdate" (default). This is done to avoid multiple instances of a service from accessing a volume at the same time.
If the Docker Compose file has service name with `_` in it (eg.`web_service`), then it will be replaced by `-` and the service name will be renamed accordingly (eg.`web-service`). Kompose does this because "Kubernetes" doesn't allow `_` in object name.
Please note that changing service name might break some `docker-compose` files.
## Docker Compose Versions
Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on versions 2.1 and 3.2 due to their experimental nature.
A full list on compatibility between all three versions is listed in our [conversion document](/docs/conversion.md) including a list of all incompatible Docker Compose keys.
docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml
+1 -5
View File
@@ -25,17 +25,13 @@ spec:
requests:
storage: 20Gi
---
apiVersion: apps/v1beta2
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml
+1 -5
View File
@@ -25,17 +25,13 @@ spec:
requests:
storage: 20Gi
---
apiVersion: apps/v1beta2
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: Recreate
template: