Kubernetes工作stream程
我一直在使用kubernetes。
$ kubectl version Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0+2831379", GitCommit:"283137936a 498aed572ee22af6774b6fb6e9fd94", GitTreeState:"not a git tree", BuildDate:"2016-07-05T15:40:25Z", GoV ersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.0", GitCommit:"5cb86ee022267586db 386f62781338b0483733b3", GitTreeState:"clean", BuildDate:"", GoVersion:"", Compiler:"", Platform:""} 我通常为每个项目设置一个Ingress，Service和复制控制器。
apiVersion: extensions/v1beta1 kind: Ingress metadata: namespace: portifolio name: portifolio-ingress spec: rules: - host: www.cescoferraro.xyz http: paths: - path: / backend: serviceName: portifolio servicePort: 80 --- apiVersion: v1 kind: Service metadata: namespace: portifolio name: portifolio labels: name: portifolio spec: selector: name: portifolio ports: - name: web port: 80 targetPort: 80 protocol: TCP --- apiVersion: v1 kind: ReplicationController metadata: namespace: portifolio name: portifolio labels: name: portifolio spec: replicas: 1 selector: name: portifolio template: metadata: namespace: portifolio labels: name: portifolio spec: containers: - image: cescoferraro/portifolio:latest imagePullPolicy: Always name: portifolio env: - name: KUBERNETES value: "true" - name: BRANCH value: "production"
我的“问题”是通常我部署我的应用程序：
kubectl -f delete kubernetes.yaml kubectl -f create kubernetes.yaml
我希望我可以使用一个单一的命令进行部署，每当我的应用程序是打开或closures。 当我使用相同的图像时，滚动更新不起作用（我认为它是我的kubernetes服务器版本上的一个错误）。 但是当应用程序从未被部署时，它也不起作用。
我已阅读关于部署，我不知道它会如何帮助我？
目标 1.部署如果应用程序是全新的2.使用来自dockerregistry的新图像replace现有的豆荚。
我不认为将所有资源都放在一个单独的清单中，可以帮助您实现自己的目标，因为您的Service，Ingress和ReplicationController不可能同时更改。
如果所有你想要做的是推出新的豆荚，我build议你用一个部署replace你的ReplicationController。 清单几乎有完全相同的语法，所以很容易从标准RC迁移，并且可以使用单个kubectl replace -f manifest.yml执行服务器端滚动更新。
请注意，即使使用Deployment资源，如果清单中没有任何更改，也不能触发重新部署。 kubectl replace将只是无能为力。 因此，如果需要（例如revision: 003 ），您可以在清单中增加或更改标签以强制部署。
正如前面的回答中所写，build议使用部署而不是ReplicationController。
使用imagePullPolicy: Always只会确保Kubernetes在启动新的POD之前执行docker pull 。 当“部署”资源中没有任何更改时，它不强制重新创buildPOD。
我build议添加2个东西到你的解决scheme：
- 使用
CURRENT_DATE值作为占位符值向Deployment添加标签 - 添加一个简单的shell脚本到您的项目中，用当前的date+时间replace占位符，然后使用kubectl来应用资源。
示例Bash脚本
#!/usr/bin/env bash sed "s/CURRENT_DATE/$(date)/" kubernetes.yaml | kubectl apply -f -
然后使用这个脚本重新部署，而不是自己调用kubectl。
这只是一个非常简单的例子。 当在Kubernetes中创build/应用/修补资源时，事情往往会随着时间变得越来越复杂。 如果发生这种情况，可以考虑使用一些更高级的模板解决scheme，例如使用Python和Jinja2。
你可以使用这个部署。 第一次创build它，之后，你只需要做kubectl set image deploy/my-app app=user/image:tag --record ，你很好去。
这样做，你也可以做一些很酷的事情，比如kubectl rollout undo deploy/my-app或者获取历史和状态。
你可以考虑使用Argo 。
Argo是Kubernetes的开源工作stream引擎。 它允许在源代码仓库中使用YAML定义复杂的基于微服务的应用程序部署，并自动在YAML变更（例如每次提交到production分支）上重新部署应用程序。