0%

问题描述

我在GKE上的Kubernetes中有以下rc控制器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp
labels:
app: myapp
spec:
replicas: 2
selector:
app: myapp
deployment: initial
template:
metadata:
labels:
app: myapp
deployment: initial
spec:
containers:
- name: myapp
image: myregistry.com/myapp:5c3dda6b
ports:
- containerPort: 80
imagePullPolicy: Always
imagePullSecrets:
- name: myregistry.com-registry-key

现在,如果我执行以下命令执行滚动更新,但没有重新拉镜像。为什么?

1
kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b

高票回答

如果有如下定义,Kubernetes将会在Pod创建时拉取镜像(请参阅更新镜像文档):

  • 镜像的标签为:latest
  • 指定镜像的拉取策略imagePullPolicy: Always

如果你想每次都拉取镜像,这很好。但是,如果您想按需执行该操作:例如,如果您想使用some-public-image:latest,但只想在请求时手动提取新版本。你现在可以:

  • 将imagePullPolicy设置为IfNotPresent或Never并提前拉取好,在每个群集节点上手动拉取镜像,以便是最新版本,然后执行kubectl rolling-update或类似重启Pods
  • 暂时更改imagePullPolicy,执行kubectl apply,重新启动pod(例如kubectl rolling-update),还原imagePullPolicy,重新kubectl apply
  • 将一些some-public-image:latest推送到您的私有存储库并执行kubectl rolling-update

按需拉动没有好的解决方案。如果有变化,请评论,我会更新这个答案。

原文链接

How do I force Kubernetes to re-pull an image?

问题描述

我正在寻找在DC / OS上运行Docker容器时是否使用Marathon和Chronos,Docker Swarm或Kubernetes的一些优缺点。

例如,何时使用Marathon / Chronos比使用Kubernetes更好,反之亦然?

现在我主要是进行实验,但希望我们在夏天之后开始在生产中使用这些服务之一。这可能会使Docker Swarm失去资格,因为我不确定它是否会在那时处于生产可用。

我喜欢Docker Swarm的原因是它本质上只是“Docker命令”,你不需要学习全新的东西。我们已经在使用docker-compose,它将与Docker Swarm一起开箱即用(至少在理论上),这将是一个很大的优势。我对Docker Swarm的主要关注是它是否涵盖了在生产中运行系统所需的所有用例。

高票回答

我将尝试分解Mesos上每个容器编排框架的独特方面。

使用Docker Swarm,如果:

使用Kubernetes-Mesos,如果:

使用Marathon,如果:

  • 您想要启动Docker或非Docker长期运行的应用程序/服务
  • 您希望将Mesos属性用于基于约束的计划
  • 您希望使用应用程序组和依赖关系来启动,扩展或升级相关服务
  • 您希望使用运行状况检查来自动重新启动不健康的服务或回滚不健康的部署/升级
  • 您希望集成HAProxy或Consul以进行服务发现
  • 您希望通过Web UI或REST API启动和监控应用程序
  • 您想要使用从一开始就构建的框架

使用Chronos,如果:

  • 您希望启动预期退出的Docker或非Docker任务
  • 您希望将任务计划为在特定时间/计划(cron)运行
  • 您希望安排依赖任务的DAG工作流程
  • 您希望通过Web UI或REST API启动和监视作业
  • 您想要使用从一开始就构建的框架

原文链接

Marathon vs Kubernetes vs Docker Swarm on DC/OS with Docker containers

问题描述

CloudFoundry / Diego的下一个版本将为Docker容器提供原生支持,这些容器将在多个主机[链接]之间进行编排。这听起来与Kubernetes非常相似。

当然,Kubernetes试图解决的问题更为通用,其中CloudFoundry更专注于应用程序开发。然而,对我来说,它听起来都朝着类似的方向发展,而CloudFoundry正在简单的业务流程之上添加更多功能。

所以,我想知道Kubernetes会比CloudFoundry增加更多有价值的用例吗?

高票回答

作为CloudFoundry(过去)和Kubernetes(现在)的提交者,我可能有资格回答这个问题。

PaaS平台

我喜欢将CloudFoundry称为“应用程序PaaS”,将Kubernetes称为“容器PaaS”,但鉴于两个项目都会随着时间的推移而在同一市场中竞争,因此区别相当微妙和流畅。

两者之间的区别在于CF有一个暂存层,它采用(12-factor)用户应用程序(例如jar或gem)和Heroku风格的buildpack(例如Java + Tomcat或Ruby)并生成一个Droplet(类似于Docker镜像)。CF不会将容器化接口暴露给用户,但Kubernetes会这样做。

受众人员

CloudFoundry的主要受众是希望使用Heroku风格的buildpack部署12-factor无状态应用程序的企业应用程序开发人员。

Kubernetes的受众范围更广,包括无状态应用程序和提供自己容器的有状态服务开发人员。

这种区别可能在未来发生变化:

  • CloudFoundry开始接受docker镜像
  • Kubernetes可以添加镜像生成层

功能比较

随着两个项目的成熟和竞争,它们的异同将发生变化。因此,请将以下特征进行比较。

CF和K8都有许多相似的功能,如容器化,命名空间,身份验证。

Kubernetes的竞争优势:

  • 对共享网络堆栈的容器进行分组和扩展,而不是仅仅进行独立扩展
  • 提供自己的容器
  • 有状态持久层
  • 更大、更活跃的OSS社区
  • 具有可替换组件和第三方插件
  • 免费的web GUI

CloudFoundry的竞争优势:

  • 成熟的身份验证,用户分组和多租户支持[x]
  • 提供自己的APP
  • 包括负载均衡器
  • 由BOSH部署,扩展并保持状态[x]
  • 强大的日志记录和度量聚合[x]
  • 企业Web GUI [x]

[x] 这些功能不是Diego的一部分或包含在Lattice中。

部署

CloudFoundry的竞争优势之一是它拥有成熟的部署引擎BOSH,可以实现核心CF组件的扩展,恢复和监控等功能。BOSH还支持许多具有可插拔云提供程序抽象的IaaS层。不幸的是,BOSH的学习曲线和部署配置管理是噩梦。(作为BOSH提交者,我想我可以准确地说出来。)

Kubernetes的部署抽象仍处于起步阶段。核心仓库中提供了多个目标环境,但它们并非全部正在运行,经过良好测试或得到主要开发人员的支持。这主要是成熟的事情。人们可能会期望这会随着时间的推移而改进并且会增加抽象。例如,DCOS上的Kubernetes允许使用单个命令将Kubernetes部署到现有DCOS群集。

历史背景

Diego是CF的Droplet执行代理的重写。它最初是在Kubernetes宣布之前开发的,随着竞争格局的演变,它已经具有更多的功能范围。它的最初目标是生成droplets(用户应用程序 + CF buildpack)并在Warden(在Go中重写时重命名为Garden)容器中运行它们。自成立以来,它也被重新打包为Lattice,它有点像CloudFoundry-lite(虽然这个名字是由现有项目拍摄的)。出于这个原因,Lattice有点像玩具一样,因为它故意减少了用户的观众和范围,显然缺少使其达到“企业就绪”的功能。CF已经提供的功能。这部分是因为Lattice用于测试核心组件,而没有来自更复杂的CF的一些开销,但您也可以在内部高信任环境中使用Lattice,其中安全性和多租户不是那么重要。

值得一提的是,CloudFoundry和Warden(它的容器引擎)也早于Docker,差不多几年了。

另一方面,Kubernetes是一个相对较新的项目,由Google根据BORG和Omega多年的容器使用情况开发而成。Kubernetes可以被认为是谷歌的第三代容器编排,就像Diego是Pivotal / VMware的第三代容器编排一样(v1在VMware编写; v2在VMware与Pivotal Labs帮助; v3在Pivotal接管项目后)。

原文链接

Kubernetes vs. CloudFoundry

问题描述

Kubernetes似乎都是将容器部署到集群云中。它似乎没有提及开发和临时环境(或类似环境)。

在开发期间,您希望尽可能接近生产环境并进行一些重要更改:

  • 在本地部署(或至少在您和您可以访问的地方部署)
  • 在页面刷新时使用最新的源代码(假设它是一个网站;理想情况下,本地文件保存页面自动刷新,如果您安装源代码并使用像Yeoman这样的东西可以完成)

同样,人们可能希望在非公共环境进行持续集成。

Kubernetes是否支持这种开发环境,或者是必须构建的东西,希望在生产过程中它仍然可以工作?

高票回答

更新(2016-07-15)

随着Kubernetes 1.3的发布,Minikube现在是在本地机器上运行Kubernetes进行开发的推荐方式。

原文链接

How to create a local development environment for Kubernetes?

问题描述

我很困惑Ingress和Load Balancer在Kubernetes中的角色。

据我所知,Ingress用于将来自互联网的传入流量映射到群集中运行的服务。

Load Balancer的作用是将流量转发到主机。在这方面,Ingress与Load Balancer有何不同?与Amazon ELB和ALB相比,kubernetes中的Load Balancer的概念是什么?

高票回答

Load Balancer:kubernetes LoadBalancer是指向不在您的kubernetes集群中但存在于其他地方的外部负载均衡器的服务。假设您的pod可以从外部路由,它们可以与您的pod一起使用。Google和AWS本身就提供此功能。就Amazon而言,在AWS中运行时直接映射到ELB,kubernetes可以为部署的每个LoadBalancer服务自动配置和配置ELB实例。

Ingress:Ingress实际上只是将一组规则传递给正在监听它们的控制器。您可以部署一组Ingress规则,但除非您有可以处理它们的控制器,否则不会发生任何事情。如果配置为执行此操作,则LoadBalancer服务可以侦听Ingress规则。

您还可以创建NodePort服务,该服务在群集外部具有可外部路由的IP,但指向群集中存在的Pod。这可能是一个Ingress控制器。

Ingress Controller只是一个配置为解释入口规则的pod。nginx是kubernetes支持的最受欢迎的Ingress控制器之一。就亚马逊而言,ALB可用作Ingress控制器。

例如,这个nginx控制器能够获取你定义的入口规则并将它们转换为一个nginx.conf文件,它在它的pod中加载和启动。比如说你定义了一个Ingress如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app

然后,如果您检查nginx控制器的pod,您将在/etc/nginx.conf中看到定义的以下规则:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;

client_max_body_size "1m";

proxy_set_header Host $best_http_host;

# Pass the extracted client certificate to the backend

# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;

# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";

# Custom headers

proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";

proxy_http_version 1.1;

proxy_cookie_domain off;
proxy_cookie_path off;

rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;

}

Nginx刚刚创建了一条规则来路由http://kubernetes.foo.bar/app以指向群集中的服务appsvc。

示例介绍了如何在kubernetes集群中使用nginx ingress控制器。希望这可以帮助!

原文链接

Ingress vs Load Balancer

问题描述

1 - 我正在阅读文档,我对措辞有点困惑。它说:

ClusterIP:在集群内部IP上公开服务。选择此值使服务只能从群集中访问。这是默认的ServiceType

NodePort:在每个Node的IP上公开静态端口(NodePort)服务。将自动创建NodePort服务到ClusterIP服务的路由。您可以通过请求来从群集外部请求NodePort服务。

LoadBalancer:使用云提供商的负载均衡器在外部公开服务。将自动创建外部负载均衡器到NodePort和ClusterIP服务的路由。

NodePort服务类型是否仍然使用ClusterIP,而只是在不同的端口,该端口对外部客户端开放?那么在这种情况下,相同?

或者,NodeIP是否是运行kubectl get nodes得到的IP,而不是用于ClusterIP的虚拟IP?

2 - 同样在以下链接的图表中:

http://kubernetes.io/images/docs/services-iptables-overview.svg

客户端在节点内是否有任何特殊原因?我认为在ClusterIP服务类型的情况下,它需要在Cluster内。如果为NodePort绘制一个类似的图表,那么把客户端画在Node和Cluster之外是否有效,或者我是否忽略了什么?

高票回答

ClusterIP公开以下内容:

  • spec.clusterIp:spec.ports[*].port

您只能在群集内访问此服务。可以从spec.clusterIp端口访问它。如果设置了spec.ports [*].targetPort,它将从端口路由到targetPort。调用kubectl get services时获得的CLUSTER-IP是内部在集群内分配给此服务的IP。

NodePort公开以下内容:

  • <NodeIP>:spec.ports[*].nodePort
  • spec.clusterIp:spec.ports[*].port

如果通过nodePort的方式从节点的外部IP访问此服务,它会将请求路由到spec.clusterIp:spec.ports[*].port,然后将其路由到spec.ports [*].targetPort,如果设置。也可以使用与ClusterIP相同的方式访问此服务。

您的NodeIP是节点的外部IP地址。您无法从:spec.ports [*].nodePort访问您的服务。

LoadBalancer公开以下内容:

  • spec.loadBalancerIp:spec.ports[*].port
  • <NodeIP>:spec.ports[*].nodePort
  • spec.clusterIp:spec.ports[*].port

您可以从负载均衡器的IP地址访问此服务,该IP地址将您的请求路由到nodePort,而nodePort又将请求路由到clusterIP端口。您可以像访问NodePort或ClusterIP服务一样访问此服务。

原文链接

What’s the difference between ClusterIP, NodePort and LoadBalancer service types in Kubernetes

问题描述

我对所有这些都比较陌生,并且在尝试理解列出的这些技术时遇到了麻烦。

虽然,所有这些技术都试图解决不同的问题,但也有共同点。我想了解哪些是相同的,哪些是不同的。少数技术的组合很可能非常适合,如果是这样的话,他们是什么?

我列出了其中的一些以及问题,但如果有人详细列出所有问题并回答问题,那将会很棒。

  1. Kubernetes vs Mesos:

    Apache的Mesos和Google的Kubernetes有什么区别提供了很好的洞察力,但我无法理解为什么Kubernetes应该运行在Mesos之上。两个开源解决方案的结合更多的是什么?

  2. Kubernetes vs Core-OS Fleet:

    如果我使用kubernetes,是否需要Core-OS Fleet?

  3. Docker-Swarm如何适应上述所有内容?

高票回答

我认为Mesos和Kubernetes主要是为了解决运行集群应用程序的类似问题,他们有不同的历史和解决问题的不同方法。

Mesos将精力集中在非常通用的调度上,并插入多个不同的调度程序。这意味着它使Hadoop和Marathon等系统能够在同一个调度环境中共存。Mesos不太关注运行时容器。Mesos存在于对容器的广泛关注之前,并且已经重新更新以支持容器。

相比之下,Kubernetes从一开始就被设计成一个用于从容器构建分布式应用程序的环境。它包括用于复制和服务发现的原语作为核心原语,其中 - 在Mesos中是通过框架添加这些原语。Kubernetes的主要目标是构建,运行和管理分布式系统的系统。

Fleet是一个较低级别的任务分发者。它对于引导群集系统很有用,例如CoreOS使用它将kubernetes代理和二进制文件分发到群集中的计算机,以便启动kubernetes群集。它并不是真正意图解决相同的分布式应用程序开发问题,更像是集群的systemd / init.d / upstart。如果您运行kubernetes,则不需要它,您可以使用其他工具(例如Salt,Puppet,Ansible,Chef,…)来完成相同的二进制分发。

Swarm是Docker努力扩展现有的Docker API,使一组机器看起来像一个Docker API。从根本上说,我们在Google和其他地方的经验表明,节点API不足以支持群集API。你可以在这里看到一堆讨论:
https://github.com/docker/docker/pull/8859和这里:
https://github.com/docker/docker/issues/8781

原文链接

Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet

问题描述

我一直在创建类型为deploy的pod,但我看到一些文档使用的type是pod,更具体地说是多容器pod的文档

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Pod
metadata:
name: ""
labels:
name: ""
namespace: ""
annotations: []
generateName: ""
spec:
? "// See 'The spec schema' for details."
: ~

但是要创建pod,我可以使用deployment类型:

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ""
spec:
replicas: 3
template:
metadata:
labels:
app: ""
spec:
containers:
etc

我注意到pod文档说:

create命令可用于直接创建pod,也可以通过Deployment创建pod或pods。强烈建议您使用deployment来创建pod。它会监视失败的pod,并根据需要启动新的pod以维持指定的数量。如果您不希望deployment监视您的pod(例如,您的pod正在编写非持久性数据,或者您的pod的生命非常短暂),则可以直接创建一个pod。

注意:我们建议使用“deployment”来创建pods。

但是这引出了一个问题:kind类型为pod有什么好处?你能以某种方式参考deployment中的pod吗?我没有看到办法。看起来使用pod获得的是一些额外的元数据,但没有任何deployment选项,如副本或重启策略。没有持久数据的pod有什么用,可以在重启后保存下来?我想我也可以创建一个deployment的多容器pod。

高票回答

Pod和Deployment都是Kubernetes API中的完整对象。Deployment通过ReplicaSet管理创建Pod。它归结为Deployment将使用模板中的规范创建Pod。您不太可能需要直接为生产用例创建Pod。

原文链接

What is the difference between a pod and a deployment?

问题描述

我试图删除一个有12个pod的ReplicationController,但是发现一些pod卡在了Terminating状态。

我的Kubernetes集群安装在Ubuntu虚拟机上,包括一个master节点和三个worker节点。

这个问题可能是什么原因?

1
2
3
4
5
6
NAME        READY     STATUS        RESTARTS   AGE
pod-186o2 1/1 Terminating 0 2h
pod-4b6qc 1/1 Terminating 0 2h
pod-8xl86 1/1 Terminating 0 1h
pod-d6htc 1/1 Terminating 0 1h
pod-vlzov 1/1 Terminating 0 1h

高票回答

您可以使用以下命令强制删除POD。

1
kubectl delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>

原文链接

Pods stuck in Terminating status

问题描述

虽然分析了Docker,Google Cloud和Kubernetes,但还没有清楚地理解它们, 在我看来这些产品是重叠但不兼容的。

例如,需要重新编写docker-compose文件,以便可以将应用程序部署到Kubernetes。

有人可以从较高层次描述Docker,Docker-Compose,Docker Cloud和Kubernetes重叠的位置以及哪一个依赖于另一个吗?

高票回答

Docker :

Docker是一种容器技术,可以让您对应用程序进行容器化。Docker是使用其他技术的核心。

Docker Compose:

允许配置和启动多个docker容器。当你想要启动多个docker容器并且不想使用docker run分别启动每个Docker容器时,可以使用Docker compose启动。

Docker Swarm:

Docker swarm用于在多个主机上运行和连接容器。Docker swarm是一个容器集群管理和编排工具。它管理在多个主机上运行的容器,并执行缩放,在崩溃时启动新容器,网络容器……

Docker swarm是生产环境中的docker。它是嵌入在Docker引擎中的本机docker编排工具。名为stack file的docker swarm文件与docker compose文件非常相似。

Kubernetes:

由Google开发的容器编排工具。Kubernetes的目标与Docker swarm的目标非常相似。

Docker Cloud:

一种付费的企业级docker服务,允许您在云服务器或本地服务器上构建和运行容器。它提供了一个Web UI和一个中央控制面板来运行和管理容器,同时在用户友好的Web界面中提供所有docker功能。

Update:

Docker Clou“部分”功能停止使用

1
Docker Cloud上提供应用程序,节点和群集集群管理的服务将于5月21日关闭......自动构建和注册表存储服务将不会受到影响并将继续可用

原文链接

What’s the difference between docker compose and kubernetes?