Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7
* '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
This commit is contained in:
Andrew Chen
@@ -310,6 +310,7 @@
|
||||
/serviceaccount/token /docs/tasks/configure-pod-container/configure-service-account 301
|
||||
|
||||
/v1.1/docs/admin/networking.html /docs/concepts/cluster-administration/networking 301
|
||||
/v1.1/docs/getting-started-guides /docs/tutorials/kubernetes-basics/ 301
|
||||
|
||||
|
||||
############################
|
||||
@@ -317,6 +318,8 @@
|
||||
#
|
||||
/docs/user-guide/kubectl/kubectl_* /docs/user-guide/kubectl/v1.7/#:splat 200
|
||||
|
||||
/v1.1/docs/* /docs/ 301
|
||||
|
||||
/docs/user-guide/kubectl/1_5/* https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5 301
|
||||
/docs/user-guide/kubectl/v1.5/node_modules/* https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5 301
|
||||
/docs/resources-reference/1_5/* https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5 301
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: 调试Pods和Replication Controllers
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## 调试Pods
|
||||
|
||||
调试一个pod的第一步是观察它。使用下面的命令检查这个pod的当前状态和最近事件：
|
||||
|
||||
$ kubectl describe pods ${POD_NAME}
|
||||
|
||||
看看pod中的容器的状态。他们都是`Running`吗？有最近重启了吗？
|
||||
|
||||
根据pod的状态继续调试。
|
||||
|
||||
### 我的Pod保持Pending
|
||||
|
||||
如果一个pod被卡在`Pending`中，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足
|
||||
阻止调度。 看看上面的命令`kubectl describe ...`的输出。调度器的消息中应该会包含无法调度Pod的原因。
|
||||
理由包括：
|
||||
|
||||
#### 资源不足
|
||||
|
||||
您可能已经耗尽了集群中供应的CPU或内存。在这个情况下你可以尝试几件事情：
|
||||
|
||||
* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
|
||||
|
||||
* [终止不需要的pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
|
||||
为pending中的pods提供空间。
|
||||
|
||||
* 检查该pod是否不大于您的节点。例如，如果全部节点具有`cpu:1`容量，那么具有`cpu: 1.1`请求的pod永远不会被调度。
|
||||
|
||||
您可以使用`kubectl get nodes -o <format>`命令来检查节点容量。
|
||||
下面是一些能够提取必要信息的命令示例：
|
||||
|
||||
kubectl get nodes -o yaml | grep '\sname\|cpu\|memory'
|
||||
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
|
||||
|
||||
可以考虑配置[资源配额](/docs/concepts/policy/resource-quotas/)来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
|
||||
|
||||
#### 使用hostPort
|
||||
|
||||
当你将一个pod绑定到一个`hostPort`时，这个pod能被调度的位置数量有限。
|
||||
在大多数情况下，`hostPort`是不必要的; 尝试使用服务对象来暴露您的pod。
|
||||
如果你需要`hostPort`，那么你可以调度的Pod数量不能超过集群的节点个数。
|
||||
|
||||
### 我的Pod一直在Waiting
|
||||
|
||||
如果一个pod被卡在`Waiting`状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
|
||||
再次，来自`kubectl describe ...`的内容应该是可以提供信息的。
|
||||
最常见的原因`Waiting`的pod是无法拉取镜像。有三件事要检查：
|
||||
|
||||
* 确保您的镜像的名称正确。
|
||||
* 您是否将镜像推送到存储库？
|
||||
* 在您的机器上手动运行`docker pull <image>`，看看是否可以拉取镜像。
|
||||
|
||||
### 我的Pod一直Crashing或者有别的不健康状态
|
||||
|
||||
首先，查看当前容器的日志：
|
||||
|
||||
$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
|
||||
|
||||
如果您的容器先前已崩溃，则可以访问上一个容器的崩溃日志：
|
||||
|
||||
$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
||||
|
||||
或者，您可以使用`exec`在该容器内运行命令：
|
||||
|
||||
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
|
||||
请注意，`-c ${CONTAINER_NAME}`是可选的，对于pod只包含一个容器可以省略。
|
||||
|
||||
例如，要查看正在运行的Cassandra pod的日志，可以运行：
|
||||
|
||||
$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
||||
|
||||
如果这些方法都不起作用，您可以找到该运行pod所在的主机并SSH到该主机。
|
||||
|
||||
## 调试Replication Controllers
|
||||
|
||||
Replication Controllers相当简单。他们能或不能创建pod。如果他们无法创建pod，那么请参考
|
||||
[上面的说明](#debugging_pods)来调试你的pod。
|
||||
|
||||
您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
|
||||
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: 为容器设置启动时要执行的命令及其入参
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本页将展示如何为Kubernetes Pod下的容器设置启动时要执行的命令及其入参。
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## 创建Pod时为其下的容器设置启动时要执行的命令及其入参
|
||||
|
||||
创建Pod时，可以为其下的容器设置启动时要执行的命令及其入参。如果要设置命令，就
|
||||
填写在配置文件的`command`字段下，如果要设置命令的入参，就填写在配置文件的`args
|
||||
`字段下。一旦Pod创建完成，该命令及其入参就无法再进行更改了。
|
||||
|
||||
如果在配置文件中设置了容器启动时要执行的命令及其入参，那么容器镜像中自带的命令
|
||||
与入参将会被覆盖而不再执行。如果配置文件中只是设置了入参，却没有设置其对应的命
|
||||
令，那么容器镜像中自带的命令会使用该新入参作为其执行时的入参。
|
||||
|
||||
本示例中，将创建一个只包含单个容器的Pod。在Pod配置文件中设置了一个命令与两个入参：
|
||||
|
||||
{% include code.html language="yaml" file="commands.yaml" ghlink="/docs/tasks/inject-data-application/commands.yaml" %}
|
||||
|
||||
1. 基于YAML文件创建一个Pod：
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml
|
||||
|
||||
1. 获取一下当前正在运行的Pods信息：
|
||||
|
||||
kubectl get pods
|
||||
|
||||
查询结果显示在command-demo这个Pod下运行的容器已经启动完成
|
||||
|
||||
1. 如果要获取容器启动时执行命令的输出结果，可以通过Pod的日志进行查看
|
||||
|
||||
kubectl logs command-demo
|
||||
|
||||
日志中显示了HOSTNAME 与KUBERNETES_PORT 这两个环境变量的值：
|
||||
|
||||
command-demo
|
||||
tcp://10.3.240.1:443
|
||||
|
||||
## 使用环境变量来设置入参
|
||||
|
||||
在上面的示例中，我们直接将一串字符作为命令的入参。除此之外，我们还可以
|
||||
将环境变量作为命令的入参。
|
||||
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "hello world"
|
||||
command: ["/bin/echo"]
|
||||
args: ["$(MESSAGE)"]
|
||||
|
||||
这样一来，我们就可以将那些用来设置环境变量的方法应用于设置命令的入参，其
|
||||
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
|
||||
与
|
||||
[Secrets](/docs/concepts/configuration/secret/).
|
||||
|
||||
**注意：** 环境变量需要加上括号，类似于`"$(VAR)"`。这是在`command`
|
||||
或 `args`字段使用变量的格式要求。
|
||||
{: .note}
|
||||
|
||||
## 通过shell来执行命令
|
||||
|
||||
有时候，需要通过shell来执行命令。 例如，命令可能由多个命令组合而成，抑或包含
|
||||
在一个shell脚本中。这时，就可以通过如下方式在shell中执行命令：
|
||||
|
||||
command: ["/bin/sh"]
|
||||
args: ["-c", "while true; do echo hello; sleep 10;done"]
|
||||
|
||||
## 注意
|
||||
|
||||
下表给出了Docker 与 Kubernetes中对应的字段名称。
|
||||
|
||||
| Description | Docker field name | Kubernetes field name |
|
||||
|----------------------------------------|------------------------|-----------------------|
|
||||
| The command run by the container | Entrypoint | command |
|
||||
| The arguments passed to the command | Cmd | args |
|
||||
|
||||
如果要覆盖默认的Entrypoint 与 Cmd，需要遵循如下规则：
|
||||
|
||||
* 如果在容器配置中没有设置`command` 或者 `args`，那么将使用Docker镜像自带的命
|
||||
令及其入参。
|
||||
|
||||
* 如果在容器配置中只设置了`command`但是没有设置`args`,那么容器启动时只会执行该
|
||||
命令，Docker镜像中自带的命令及其入参会被忽略。
|
||||
|
||||
* 如果在容器配置中只设置了`args`,那么Docker镜像中自带的命令会使用该新入参作为
|
||||
其执行时的入参。
|
||||
|
||||
* 如果在容器配置中同时设置了`command` 与 `args`，那么Docker镜像中自带的命令及
|
||||
其入参会被忽略。容器启动时只会执行配置中设置的命令，并使用配置中设置的入参作为
|
||||
命令的入参。
|
||||
|
||||
下表涵盖了各类设置场景：
|
||||
|
||||
| Image Entrypoint | Image Cmd | Container command | Container args | Command run |
|
||||
|--------------------|------------------|---------------------|--------------------|------------------|
|
||||
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
|
||||
| `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` |
|
||||
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
|
||||
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* 获取更多资讯可参考 [containers and commands](/docs/user-guide/containers/).
|
||||
* 获取更多资讯可参考 [configuring pods and containers](/docs/tasks/).
|
||||
* 获取更多资讯可参考 [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
|
||||
* 参考 [Container](/docs/api-reference/{{page.version}}/#container-v1-core).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,226 @@
|
||||
---
|
||||
title: 运行一个单实例有状态应用
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
本文介绍在Kubernetes中使用PersistentVolume和Deployment如何运行一个单实例有状态应用. 该应用是MySQL.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture objectives %}
|
||||
|
||||
* 在环境中通过磁盘创建一个PersistentVolume.
|
||||
* 创建一个MySQL Deployment.
|
||||
* 在集群内以一个已知的DNS名将MySQL暴露给其他pods.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
* {% include task-tutorial-prereqs.md %}
|
||||
|
||||
* 为了数据持久性我们将在环境上通过磁盘创建一个持久卷. 环境支持的类型见这里[here](/docs/user-guide/persistent-volumes/#types-of-persistent-volumes). 本篇文档将介绍 `GCEPersistentDisk` . `GCEPersistentDisk`卷只能工作在Google Compute Engine平台上.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture lessoncontent %}
|
||||
|
||||
## 在环境中设置一个磁盘
|
||||
|
||||
你可以为有状态的应用使用任何类型的持久卷. 有关支持环境的磁盘列表，请参考持久卷类型[Types of Persistent Volumes](/docs/user-guide/persistent-volumes/#types-of-persistent-volumes). 对于Google Compute Engine, 请运行:
|
||||
|
||||
```
|
||||
gcloud compute disks create --size=20GB mysql-disk
|
||||
```
|
||||
|
||||
|
||||
接下来创建一个指向刚创建的 `mysql-disk`磁盘的PersistentVolume. 下面是一个PersistentVolume的配置文件，它指向上面创建的Compute Engine磁盘:
|
||||
|
||||
{% include code.html language="yaml" file="gce-volume.yaml" ghlink="/docs/tasks/run-application/gce-volume.yaml" %}
|
||||
|
||||
注意`pdName: mysql-disk` 这行与Compute Engine环境中的磁盘名称相匹配. 有关为其
|
||||
他环境编写PersistentVolume配置文件的详细信息，请参见持久卷[Persistent Volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
|
||||
|
||||
创建持久卷:
|
||||
|
||||
```
|
||||
kubectl create -f https://k8s.io/docs/tasks/run-application/gce-volume.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 部署MySQL
|
||||
|
||||
通过创建Kubernetes Deployment并使用PersistentVolumeClaim将其连接到现已存在的PersistentVolume上来运行一个有状态的应用. 例如, 下面这个YAML文件描述了一个运行MySQL
|
||||
并引用PersistentVolumeClaim的Deployment. 该文件定义了一个volume其挂载目录为/var/lib/mysql, 然后创建一个内存为20G的卷的PersistentVolumeClaim. 此申领可以通过任
|
||||
何符合需求的卷来满足, 在本例中满足上面创建的卷.
|
||||
|
||||
|
||||
注意: 在配置的yaml文件中定义密码的做法是不安全的. 具体安全解决方案请参考
|
||||
[Kubernetes Secrets](/docs/concepts/configuration/secret/).
|
||||
|
||||
{% include code.html language="yaml" file="mysql-deployment.yaml" ghlink="/docs/tasks/run-application/mysql-deployment.yaml" %}
|
||||
|
||||
|
||||
1. 部署YAML文件中定义的内容:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/run-application/mysql-deployment.yaml
|
||||
|
||||
|
||||
1. 展示Deployment相关信息:
|
||||
|
||||
kubectl describe deployment mysql
|
||||
|
||||
Name: mysql
|
||||
Namespace: default
|
||||
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
|
||||
Labels: app=mysql
|
||||
Annotations: deployment.kubernetes.io/revision=1
|
||||
Selector: app=mysql
|
||||
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
|
||||
StrategyType: Recreate
|
||||
MinReadySeconds: 0
|
||||
Pod Template:
|
||||
Labels: app=mysql
|
||||
Containers:
|
||||
mysql:
|
||||
Image: mysql:5.6
|
||||
Port: 3306/TCP
|
||||
Environment:
|
||||
MYSQL_ROOT_PASSWORD: password
|
||||
Mounts:
|
||||
/var/lib/mysql from mysql-persistent-storage (rw)
|
||||
Volumes:
|
||||
mysql-persistent-storage:
|
||||
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
|
||||
ClaimName: mysql-pv-claim
|
||||
ReadOnly: false
|
||||
Conditions:
|
||||
Type Status Reason
|
||||
---- ------ ------
|
||||
Available False MinimumReplicasUnavailable
|
||||
Progressing True ReplicaSetUpdated
|
||||
OldReplicaSets: <none>
|
||||
NewReplicaSet: mysql-63082529 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
|
||||
|
||||
|
||||
1. 列举出Deployment创建的pods:
|
||||
|
||||
kubectl get pods -l app=mysql
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mysql-63082529-2z3ki 1/1 Running 0 3m
|
||||
|
||||
|
||||
1. 查看持久卷:
|
||||
|
||||
kubectl describe pv mysql-pv
|
||||
|
||||
Name: mysql-pv
|
||||
Labels: <none>
|
||||
Status: Bound
|
||||
Claim: default/mysql-pv-claim
|
||||
Reclaim Policy: Retain
|
||||
Access Modes: RWO
|
||||
Capacity: 20Gi
|
||||
Message:
|
||||
Source:
|
||||
Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
|
||||
PDName: mysql-disk
|
||||
FSType: ext4
|
||||
Partition: 0
|
||||
ReadOnly: false
|
||||
No events.
|
||||
|
||||
|
||||
1. 查看PersistentVolumeClaim:
|
||||
|
||||
kubectl describe pvc mysql-pv-claim
|
||||
|
||||
Name: mysql-pv-claim
|
||||
Namespace: default
|
||||
Status: Bound
|
||||
Volume: mysql-pv
|
||||
Labels: <none>
|
||||
Capacity: 20Gi
|
||||
Access Modes: RWO
|
||||
No events.
|
||||
|
||||
|
||||
## 访问MySQL实例
|
||||
|
||||
|
||||
前面YAML文件中创建了一个允许集群内其他pods访问数据库的服务. 该服务中选项
|
||||
`clusterIP: None` 让服务DNS名称直接解析为Pod的IP地址. 当在一个服务下只有一个pod
|
||||
并且不打算增加pods的数量这是最好的.
|
||||
|
||||
|
||||
运行MySQL客户端以连接到服务器:
|
||||
|
||||
```
|
||||
kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -p <password>
|
||||
```
|
||||
|
||||
此命令在集群内创建一个新的Pod并运行MySQL客户端,并通过服务将其连接到服务器.如果连接成功,你就知道有状态的MySQL database正处于运行状态.
|
||||
|
||||
```
|
||||
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
|
||||
mysql>
|
||||
```
|
||||
|
||||
## 更新
|
||||
|
||||
|
||||
Deployment中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新. 以下是
|
||||
特定于有状态应用的一些注意事项:
|
||||
|
||||
* 不要弹性伸缩. 弹性伸缩仅适用于单实例应用. 下层的PersistentVolume仅只能挂载一个pod. 对于集群级有状态应用, 请参考StatefulSet文档
|
||||
[StatefulSet documentation](/docs/concepts/workloads/controllers/statefulset/).
|
||||
* 在Deployment的YAML文件中使用 `strategy:` `type: Recreate` . 该选项指示Kubernetes不使用滚动升级. 滚动升级将无法工作, 由于一次不能运行多个pod. 在更新配置文件
|
||||
创建一个新的pod前 `Recreate`策略将先停止第一个pod.
|
||||
|
||||
|
||||
## 删除deployment
|
||||
|
||||
|
||||
通过名称删除部署的对象:
|
||||
|
||||
```
|
||||
kubectl delete deployment,svc mysql
|
||||
kubectl delete pvc mysql-pv-claim
|
||||
kubectl delete pv mysql-pv
|
||||
```
|
||||
|
||||
如果使用Compute Engine磁盘，也可以使用如下命令:
|
||||
|
||||
```
|
||||
gcloud compute disks delete mysql-disk
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* 了解更多Deployment对象请参考 [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
* 了解更多Deployment应用请参考 [Deploying applications](/docs/user-guide/deploying-applications/)
|
||||
|
||||
* kubectl run文档请参考[kubectl run documentation](/docs/user-guide/kubectl/v1.6/#run)
|
||||
|
||||
* 卷和持久卷请参考[Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/tutorial.md %}
|
||||
+1
-5
@@ -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:
|
||||
|
||||
+1
-5
@@ -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:
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
+21
-4
@@ -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
|
||||
|
||||
@@ -3,6 +3,7 @@ kind: Pod
|
||||
metadata:
|
||||
name: hostaliases-pod
|
||||
spec:
|
||||
restartPolicy: Never
|
||||
hostAliases:
|
||||
- ip: "127.0.0.1"
|
||||
hostnames:
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
+332
-194
@@ -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.
|
||||
|
||||
@@ -464,7 +464,7 @@ Patch the container image for the `web` StatefulSet.
|
||||
|
||||
```shell
|
||||
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.7"}]'
|
||||
"web" patched
|
||||
statefulset "web" patched
|
||||
```
|
||||
|
||||
Delete the `web-0` Pod.
|
||||
|
||||
+1
-5
@@ -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:
|
||||
|
||||
+1
-5
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user