istio-访问授权

Daniel_Ji阅读(102)评论(0)

Istio授权功能是基于角色的访问控制(RBAC),支持在Istio Mesh中,为服务提供名称空间级别,服务级别和方法级别的访问控制。它具有以下特点:

  • 基于角色的语义,简单易用。
  • 支持服务到服务,以及终端用户到服务授权
  • 灵活性的自定义属性支持,例如角色和角色绑定中的条件。
  • 高性能,Istio授权在Envoy上本地执行。
  • 高兼容性,本地支持HTTP,HTTPS和HTTP2,以及任何普通的TCP协议。

1. 授权架构

Istio授权架构

上图显示了基本的Istio授权架构。运营商使用.yaml文件指定Istio授权策略。部署后,Istio将策略保存在中Istio Config Store。

Pilot监视Istio授权策略的更改。如果看到任何更改,它将获取更新的授权策略。Pilot将Istio授权策略分发给与服务实例位于同一位置的Envoy代理。

每个Envoy代理都运行一个授权引擎,该引擎在运行时对请求进行授权。当请求到达代理时,授权引擎根据当前的授权策略评估请求上下文,并返回授权结果ALLOW或DENY。

2.  启用授权

可以使用ClusterRbacConfig对象启用Istio授权。该ClusterRbacConfig 对象是集群范围内的单例,其固定名称值为default。在网格中只能使用ClusterRbacConfig一个实例。与其他Istio配置对象一样,ClusterRbacConfig被定义为Kubernetes CustomResourceDefinition (CRD)对象。

在ClusterRbacConfig对象中,操作员可以指定一个mode值,该值可以是:

  • OFF:Istio授权已禁用。
  • ON:已为网格中的所有服务启用Istio授权。
  • ON_WITH_INCLUSION:仅对inclusion字段中指定的服务和名称空间启用Istio授权。
  • ON_WITH_EXCLUSION注意:除在exclusion字段中指定的服务和名称空间外,将为网格中的所有服务启用Istio授权。

在以下示例中,为default 名称空间启用了Istio授权。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    namespaces: ["default"]

3.  授权策略

通过指定ServiceRole和 ServiceRoleBinding 来配置Istio授权策略。与其他Istio配置对象一样,它们是Kubernetes CustomResourceDefinition (CRD)对象。

  • ServiceRole :定义一组访问服务的权限。
  • ServiceRoleBinding:将ServiceRole授予特定主题,例如用户,组或服务。

ServiceRole和ServiceRoleBinding组合规定:在什么条件下,被允许做什么。特别:

  • Who:参考ServiceRoleBinding中的subjects。
  • What参考permissions的ServiceRole。
  • Which condition:参考ServiceRole和ServiceRoleBinding是指conditions您可以在或中使用Istio属性指定的部分。

3.1.  ServiceRole

ServiceRole规范包括的rules的,AKA权限。每个规则都有以下标准字段:

  • services:服务名称列表。可以将值设置为*,这样会包括指定名称空间中的所有服务。
  • methods:HTTP方法列表。可以将值设置为*,这样会包括所有HTTP方法。不应为TCP和gRPC服务设置此字段。
  • paths:HTTP路径或gRPC方法。gRPC方法必须采用/packageName.serviceName/methodName且区分大小写。

ServiceRole规格只适用于指定的命名空间。规格services字段是必须的,其他字段是可选的。如果未指定字段或将其值设置为*,则Istio将该字段应用于所有实例。

下面的示例显示一个简单的角色:service-admin,该角色对default名称空间中所有服务的具有完全访问权限。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: service-admin
  namespace: default
spec:
  rules:
  - services: ["*"]

这里是另一个角色:products-viewer,对default命名空间下的products.default.svc.cluster.local服务,具有”GET”和”HEAD”访问权限。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: products-viewer
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]

此外,支持规则中所有字段的前缀匹配和后缀匹配。例如,可以tester在default名称空间中定义具有以下权限的角色:

  • 访问所有前缀为”test-*”的服务,例如:test-bookstore,test-performance,test-api.default.svc.cluster.local。
  • (”GET”)访问后缀为”*/reviews”的所有路径,例如:在default.svc.cluster.local服务中的/books/reviews,/events/booksale/reviews,/reviews。
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: tester
  namespace: default
spec:
  rules:
  - services: ["test-*"]
    methods: ["*"]
  - services: ["bookstore.default.svc.cluster.local"]
    paths: ["*/reviews"]
    methods: ["GET"]

在ServiceRole,组合namespace+ services+ paths+ methods定义了服务或服务如何被访问。在某些情况下,可能需要为规则指定其他条件。例如,规则可能仅适用于某个版本的服务,或仅适用于带有特定标签的服务(例如”foo”)。可以通过使用约束来实现上述的条件。

例如,以下ServiceRole定义添加了一个约束,该约束 request.headers[version]:”v1″或”v2″。约束和属性页面key中列出了约束的支持值。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: products-viewer-version
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]
    constraints:
    - key: request.headers[version]
      values: ["v1", "v2"]

3.2.  ServiceRoleBinding

ServiceRoleBinding规范包括两个部分:

  • roleRef:引用相同名称空间中的ServiceRole资源。
  • subjects:分配给角色的列表。

可以明确地为subjects指定一个user或带有一组属性的user。ServiceRoleBinding subjects的属性是类似于ServiceRole规范中的约束。可以通过属性使用条件来为角色分配帐户。属性它包含一个 key及其允许的值。

以下示例显示了一个名称为test-binding-products 的ServiceRoleBinding,它将两个主题绑定到名称为”product-viewer”的ServiceRole。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: test-binding-products
  namespace: default
spec:
  subjects:
  - user: "service-account-a"
  - user: "istio-ingress-service-account"
    properties:
      request.auth.claims[email]: "a@foo.com"
  roleRef:
    kind: ServiceRole
    name: "products-viewer"

如果要使服务可以被公开访问,可以在subjects设置user: “*”。此值将分配ServiceRole给所有(经过身份验证和未经身份验证的)用户和服务,例如:

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: binding-products-allusers
namespace: default
spec:
subjects:
- user: "*"
roleRef:
kind: ServiceRole
name: "products-viewer"

要将ServiceRole分配给仅通过身份验证的用户和服务,请source.principal: “*” 改用,例如:

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: binding-products-all-authenticated-users
  namespace: default
spec:
  subjects:
  - properties:
    source.principal: "*"
  roleRef:
    kind: ServiceRole
    name: "products-viewer"

4.  在纯TCP协议上使用Istio授权

服务角色和服务角色绑定的示例显示在服务上使用HTTP协议进行Istio授权的典型方法。在这些示例中,支持服务角色和服务角色绑定中的所有字段。Istio授权支持任何使用普通TCP协议(例如MongoDB)的服务,服务角色配置和服务角色绑定都是与HTTP协议一样。区别在于使用某些仅适用于HTTP服务的字段,约束和属性。这些字段包括:

  • 服务角色配置对象中的paths和methods字段。
  • 服务角色绑定配置对象中的group字段。

如果对TCP服务使用了仅支持HTTP的字段,则Istio会完全忽略服务角色或服务角色绑定自定义资源和策略。假设在端口27017上具有MongoDB服务,下面的示例仅允许bookinfo-ratings-v2访问MongoDB服务。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: mongodb-viewer
namespace: default
spec:
rules:
- services: ["mongodb.default.svc.cluster.local"]
constraints:
- key: "destination.port"
values: ["27017"]
---

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: bind-mongodb-viewer
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookinfo-ratings-v2"
  roleRef:
    kind: ServiceRole
    name: "mongodb-viewer"

 

作者简介:季向远,北京神舟航天软件技术有限公司。本文版权归原作者所有。

istio-bookinfo入门示例

Daniel_Ji阅读(321)评论(0)

本示例部署一个名称为bookinfo的应用程序,该应用程序由四个单独的微服务组成,用于演示各种Istio功能。该应用程序用于显示书籍有关的信息,类似于在线书籍商店的单个目录条目。页面上显示的是书的说明,书的详细信息(ISBN,页数等)和一些书评。该应用程序是由多种多语言编写的,即微服务以不同的语言编写。值得注意的是,这些服务不依赖于Istio。Bookinfo应用程序分为四个单独的微服务:

  • productpage:productpage微服务调用details和reviews微服务来填充页面。
  • details:details微服务包含图书的详细信息。
  • reviews:reviews微服务包含书评,它还调用ratings微服务。
  • ratings:ratings微服务包含书的排名信息。

其中,reviews微服务提供了3个版本:

  • 版本v1不调用ratings服务。
  • 版本v2调用ratings服务,并将每个等级显示为1到5个黑星。
  • 版本v3调用ratings服务,并将每个等级显示为1到5个红色星号。

该应用程序的端到端体系结构如下所示。

Bookinfo Application

1. 应用部署

使用Istio运行bookinfo application示例时,无需更改应用程序本身的任何内容。这里只需要在启用Istio的环境中进行配置和运行服务,并为每个服务注入Envoy Proxy辅助工具。所有微服务都将与Envoy sidecar打包在一起,该Envoy sidecar用于拦截对服务的入站和出站。基于Istio部署的bookinfo application结构如下:

Bookinfo Application

1.1.  部署示例应用

通过下面的步骤部署booking application示例应用:

  • 默认情况,在Istio上部署安装应用使用自动Sidecar 注入。使用以下命令将托管应用程序的名称空间(此处为default)的标记为istio-injection=enabled:
$ kubectl label namespace default istio-injection=enabled
  • 使用以下kubectl命令部署应用程序:
$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

该命令将启动bookinfo应用程序体系结构图中显示的所有四个服务。评论服务的有3个版本,即v1,v2和v3。在实际部署中,随着时间的推移会部署新版本的微服务,而不是同时部署所有版本。

  • 确认所有服务和Pod均已正确定义并正在运行:
$ kubectl get services
NAME                      CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
details                    10.0.0.31    <none>        9080/TCP             6m
kubernetes                 10.0.0.1     <none>        443/TCP              7d
productpage                10.0.0.120   <none>        9080/TCP             6m
ratings                    10.0.0.15    <none>        9080/TCP             6m
reviews                    10.0.0.170   <none>        9080/TCP             6m

$ kubectl get pods
NAME                                READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

1.2.  创建入口网关

现在Bookinfo服务已启动并正在运行,还需要使该应用程序可以从Kubernetes集群外部访问。

  • 定义应用程序的入口网关:
$ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
  • 确认网关已创建:
$ kubectl get gateway
NAME               AGE
bookinfo-gateway   32s

2.  访问应用

通过下面的命令,将productpage微服务以NodePort模式暴露到Kubernetes集群外:

$ kubectl expose deployment/ productpage-v1 –type=NodePort

通过下面的命令,获取对外暴露的端口(这里为31532):

$ kubectl get svc

在浏览器地址中输入:http://{宿主机ip}:31532 浏览器将进入productpage页面:

3.  创建默认目标规则

在使用Istio控制Bookinfo版本路由之前,需要在目标规则中定义可用的版本,称为子集。运行以下命令为Bookinfo服务创建默认目标规则:

如果启用双向TLS,请执行以下命令:

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml

此YAML配置文件的内容如下:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  # 此host的名称对应于Kubernetes中服务的名称
host: productpage
  subsets:
  - name: v1
# 标签的键值对对应于Kubernetes中标签一致的pod
labels:
      version: v1
---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  # reviews存在v1、v2和v3三个子集,分别对应于Kubernetes中三个Pod
subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---

如果确实启用了双向TLS,请执行以下命令:

$ kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

等待几秒钟,以便传播目标规则。可以使用以下命令显示目标规则:

$ kubectl get destinationrules -o yaml

4.  路由请求

在bookinfo示例中包含四个单独的微服务,每个微服务具有多个版本。reviews微服务有3个版本被部署并同时运行。在浏览器中访问Bookinfo应用,然后刷新几次,会注意到书评输出有时包含星级,有时则不。这是因为没有明确的默认服务版本可路由,Istio以循环方式将请求路由到所有可用版本。

4.1. 创建虚拟服务

为微服务设置默认版本的虚拟服务,从而实现将流量路由到特定的一个版本。在这种情况下,虚拟服务会将所有流量路由到特定版本下的每个微服务。在这里即可以通过kubectl创建虚拟服务,也可以通过小米的Naftis创建虚拟服务。

4.1.1.  通过kubectl创建

此处通过kubectl创建虚拟服务:

  • 运行以下命令以应用虚拟服务:
$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
  • 使用以下命令显示定义的路由:
$ kubectl get virtualservices -o yaml

下面是新路由定义的代码示例:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  # 定义名称为productpage的虚拟服务
name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    # 目的路由的主机为productpage,子集为v1
- destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v3
---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1

4.1.2.  通过Naftis创建

此处通过Naftis可视化创建虚拟服务:

  • 登录Naftis,并在“服务管理”中定位到“productpage”微服务。

  • 进入“productpage”微服务主页,点击右上角的“执行任务”。

  • 进入“执行任务”页面后,点击RequestRouting类型的“创建任务”。

  • 在“创建任务”页面,填写命名空间信息和各个微服务的主机和目标地址子集:

  • Namespace:default
  • Host:productpage DestinationSubset:v1
  • Host:details DestinationSubset:v1
  • Host:ratings DestinationSubset:v1
  • Host:review3 DestinationSubset:v3

4.2. 测试新的路由配置

在浏览器中打开Bookinfo网站,多次刷新页面,页面中的评论部分均显示星级。这是因为将Istio配置为将评论服务的所有流量路由到了reviews:v3。

 

作者简介:季向远,北京神舟航天软件技术有限公司产品经理。本文版权归原作者所有。

 

 

Kubernetes v1.16 重磅发布!

中文社区阅读(3146)评论(0)

美国时间 9 月 18 日,Kubernetes 迎来了 2019 年的第三个新版本 1.16。K8sMeetup 中国社区第一时间整理了 Kubernetes v1.16 的亮点内容,为大家详细介绍此版本的主要功能。

根据 Release Note 介绍,Kubernetes v1.16 由 31 个增强功能组成:8 个进入稳定,8 个进入 Beta,15 个进入 Alpha。

一、新版本四大主题

新版本主要围绕以下主题:

1、Custom resources:CRD 是对 Kubernetes 的扩展,用以服务于新的资源类型,自 1.7 版本以来,CRD 已经在 Beta 版中可用。在 1.16 版本中,CRD 正式步入通用可用性(GA)。

2、Admission webhook:Admission webhooks 作为 Kubernetes 扩展机制被广泛使用,并且自 1.9 版本以来已经在 Beta 版中可用。在 1.16 版本中,Admission webhook 也正式步入通用可用性(GA)。

3、Overhauled metrics:Kubernetes 广泛使用一个全局 metrics registry 来注册要公开的 metrics。通过实现 metrics registry,metrics 可以以更透明的方式注册。而在这之前,Kubernetes metrics 被排除在任何稳定性需求之外。

4、Volume Extension:新版本有大量和 Volume 及 Volume 修改相关的增强。CSI 规范中对 Volume 调整的支持正在转向 Beta 版,它允许任何 CSI spec Volume plugin 都可以调整大小。

二、其他值得注意的功能更新

在 K8sMeetup 社区之前发布的《Kubernetes v1.16 Beta 前瞻》中,社区已经归纳了 Beta 版中比较受关注的一些改动。在今天发布的新版本中,官方重提了其中部分有趣更新。

  • 拓扑管理器是一个新的 Kubelet 组件,旨在协调资源分配决策,以提供优化的资源分配(见《Kubernetes v1.16 Beta 前瞻》);
  • IPv4/IPv6 双栈允许将 IPv4 和 IPv6 地址分配给 Pods 和服务(见《Kubernetes v1.16 Beta 前瞻》);
  • API Server Network Proxy 在 1.16 版本中进入 Alpha;
  • Cloud Controller Manager Migration 增强;
  • 继续淘汰 extensions/v1beta1、apps/v1beta1 和 apps/v1beta2 API,这些扩展会在 1.16 版本中被弃用(见《用户须知:Kubernetes v1.16 将删除被弃用的 API》)!

三、已知的问题

etcd 和 KMS plugin 的健康检查没有在新的 livez 的 和 readyz 端点中公开。这将在 v1.16.1 中得到修正。

运行iptables 1.8.0 或更新版本的系统应以兼容模式启动它。请注意,这将影响所有版本的 Kubernetes,而不仅仅是 v1.16.0。有关此问题的更详细信息以及解决方案,请参阅官方文档。

四、紧急升级须知

注意!此内容为升级前必读!

1、集群生命周期

amd64 的容器镜像 tar 文件现在将包含 RepoTags manifest.json 的体系结构。如果你正在使用 Docker 清单,则没有可见的更改 (#80266)。

在 TLS 引导用户依赖 bootstrap-kubelet.conf 之后,kubeadm 现在已删除 bootstrap-kubelet.conf 文件,用户应该切换到包含节点凭证的 kubelet.conf 文件(#80676)。

beta.kubernetes.io/metadata-proxy-ready、

beta.kubernetes.io/masq-agent-ds-ready、

beta.kubernetes.io/kube-proxy-ds-ready(节点标签)不再添加到新节点上。

  • ip-mask-agent addon 开始使用标签node.kubernetes.io/masq-agent-ds-ready作为其节点选择器;
  • kube-proxy addon 开始使用标签node.kubernetes.io/kube-proxy-ds-ready作为其节点选择器;
  • metada -proxy addon 开始使用标签cloud.google.com/metada -proxy-ready作为其节点选择器。

2、存储

当为 CSI 驱动启用 PodInfoOnMount 时,Volume 上下文中新的 csi.storage.k8s.io/ephemeral 参数允许驱动程序的 NodePublishVolume 实现根据具体情况确定该 Volume 是临时性的还是正常的持久卷(#79983)。

为 VerifyVolumesAreAttached 和 BulkVolume-Verify 添加 CSI Migration Shim(#81792)。

新版本将 VolumePVCDataSource(克隆)特性提升到 Beta 版(#81792)。

将 in-tree 和 CSI Volume 的 Volume Limits 集成到一个 scheduler predicate 中。 (#77595)

注:更多内容请见 GitHub,社区后续会视情况对新版本做更深入的解读,敬请期待!

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#v1160

来源:GitHub

翻译:bot(才云),译文:K8sMeetup社区

技术校对:Lichuan(才云)

KubeFed: Kubernetes Federation v2 详解

中文社区阅读(1438)评论(0)

Kubernetes Federation(联邦)一直是很有趣的议题,并被重视的功能,Federation目的是希望实现单一集群统一管理多个Kubernetes集群的机制,这些集群可能是跨地区(Region),也可能是在不同公有云供应商(Cloud Provider)上,亦或者是公司内部自行建立的集群。一但集群进行联邦后,就可以利用Federation API资源来统一管理多个集群的Kubernetes API资源,如定义Deployment如何部署到不同集群上,其集群所需的副本数等。
而Kubernetes Federation 的诞生正是希望利用联邦机制来解决一些问题,并达到一些好处,如以下:
  • 简化管理多个集群的Kubernetes 组件(如Deployment, Service 等)。
  • 在多个集群之间分散工作负载(容器),以提升应用(服务)的可靠性。
  • 跨集群的资源编排,依据编排策略在多个集群进行应用(服务)部署。
  • 在不同集群中,能更快速更容易地迁移应用(服务)。
  • 跨集群的服务发现,服务可以提供给当地存取,以降低延迟。
  • 实践多云(Multi-cloud)或混合云(Hybird Cloud)的部署。
虽然Kubernetes 社区很早之前就已实现Federation(v1) 机制,但随着Kubernetes 成长,Federation v1 发展的越来越缓慢,并在之后版被弃用了??,而SIG Multi-Cluster 团队也随即提出新架构Federation v2 来取代。
至于v1 为何被弃用?而v2 又带来什么变化呢?我将在接下来部分简单说明。

为什么v1 被弃用?

Federation v1在Kubernetes v1.3左右时,就已经着手设计( Design Proposal ),并在后面几个版本中发布了相关的组件与命令行工具(kubefed),用于帮助使用者快速建立联邦集群,并在Kubernetes v1.6时,进入了Beta阶段。
但Federation v1 在进入Beta 后,就没有更进一步的发展,一直到Kubernetes v1.11 左右正式被弃用。至于为什么被弃用呢?这是因为开发团队认为集群联邦的实践比想象中还要困难,有许多问题是v1 架构没被考虑进去的,比如说:
  • 控制平面组件会因为发生问题,而影响整体集群效率。
  • 无法兼容新的Kubernetes API 资源。
  • 无法有效的在多个集群管理权限,如不支持RBAC
  • 联邦层级的设定与策略依赖API 资源的Annotations 内容,这使得弹性不佳。
而这些问题基本上是当初设计架构所延伸而来。我们可以通过了解整体架构来更容易知道问题点。

从上图架构中得知Federation v1 的设计沿用类似Kubernetes 控制平面架构,其主要组件有以下:
  • federation-apiserver :提供Federation API资源,只支持部分Kubernetes API resources。
  • federation-controller-manager :协调不同集群之间的状态,如同步Federated资源与策略,并建立Kubernetes组件至对应集群上。
  • etcd :储存Federation的状态。
Federation v1提供了kubefed工具来简化?安装Federation控制平面元件的过程,并提供新增/删除集群的操作。
从代码大致可以了解Federation v1的API Server在基础上是通过k8s.io/apiserver套件开发,这种是采用API Aggregation方式来扩充Kubernetes API。而Federated API资源则是实作Adapter来管理Kubernetes API资源,但这些Adapter都是写死API版本的,比如说Deployment只支持extensions/v1beta1版本API,所以当建立一个apps/v1的Deployment,并且在Annotations设定联邦策略时,就会无法正常运作。
因此,若想要支持其他资源(如CronJob)或版本,就必须在Federation types新增对应的Adapter,然后通过Code Generator产生API的client-go组件给Controller Manager操作API使用,最后重新建构一版本来更新API Server与Controller Manager以提供对其他资源与版本的支持。另外Federation v1在设计之初未考虑RBAC与CRD(TPR)功能,因此无法提供跨集群的权限控管,以及定制化资源的扩展。从上述状况中,就能感受到Federation v1在扩展性有很多挑战。
也正因为在架构上无法很好解决这些问题,Federation v1 才会发展的越来越缓慢,并在最后被弃用。当然也是因为有这样的发展过程与经验,才能有Federation v2 的诞生。

Federation v2

Kubernetes Cluster Federation又名KubeFed或Federation v2,是Kubernetes SIG Multi-Cluster团队新提出的集群联邦架构( Architecture Doc与Brainstorming Doc ),新架构在Federation v1基础之上,简化扩展Federated API过程,并加强跨集群服务发现与编排的功能。另外KubeFed在设计之初,有两个最重要核心理念是KubeFed希望实现的,分别为Modularization(模块化)与Customizable(定制化),这两个理念大概是希望KubeFed能够跟随着Kubernetes生态发展,并持续保持相容性与扩展性。
KubeFed在组件上最大改变是将API Server移除,并通过CRD机制来完成Federated Resources的扩充。而KubeFed Controller则管理这些CRD,并实现同步Resources、跨集群编排等功能。从架构图中看到,KubeFed提出了一些新概念来加强功能的扩展。

Concepts
目前KubeFed 通过CRD 方式新增了四种API 群组来实现联邦机制的核心功能:
API Group 用途
core.kubefed.k8s.io
集群组态、联邦资源组态、KubeFed Controller 设定档等。
types.kubefed.k8s.io
被联邦的Kubernetes API 资源。
scheduling.kubefed.k8s.io
副本编排策略。
multiclusterdns.kubefed.k8s.io
跨集群服务发现设定。
而在这些核心功能中,我们必须先了解一些KebeFed 提出的基础概念后,才能更清楚知道KubeFed 是如何运作的。

Cluster Configuration

用来定义哪些Kubernetes集群要被联邦。可透过kubefedctl join/unjoin来加入/删除集群,当成功加入时,会建立一个KubeFedCluster组件来储存集群相关信息,如API Endpoint、CA Bundle等。这些信息会被用在KubeFed Controller存取不同Kubernetes集群上,以确保能够建立Kubernetes API资源,示意图如下所示。

在Federation 中,会区分Host 与Member 两种类型集群。
  • Host :用于提供KubeFed API与控制平面的集群。
  • Member :通过KubeFed API注册的集群,并提供相关身份凭证来让KubeFed Controller能够存取集群。Host集群也可以作为Member被加入。

Type Configuration

定义了哪些Kubernetes API资源要被用于联邦管理。比如说想将ConfigMap资源通过联邦机制建立在不同集群上时,就必须先在Federation Host集群中,通过CRD建立新资源FederatedConfigMap,接着再建立名称为configmaps的Type configuration(FederatedTypeConfig)资源,然后描述ConfigMap要被FederatedConfigMap所管理,这样KubeFed Controllers才能知道如何建立Federated资源。以下为简单范例:
apiVersion: core.kubefed.k8s.io/v1beta1
kind: FederatedTypeConfig
metadata:
  name: configmaps
  namespace: kube-federation-system
spec:
  federatedType:
    group: types.kubefed.k8s.io
    kind: FederatedConfigMap
    pluralName: federatedconfigmaps
    scope: Namespaced
    version: v1beta1
  propagation: Enabled
  targetType:
    kind: ConfigMap
    pluralName: configmaps
    scope: Namespaced
    version: v1
若想新增CRD的Federated API的话,可通过kubefedctl enable <res>指令来建立,如下:
$ kubefedctl enable etcdclusters
$ kubectl api-resources | grep etcd
etcdclusters                      etcd         etcd.database.coreos.com         true         EtcdCluster
federatedetcdclusters             fetcd        types.kubefed.k8s.io             true         FederatedEtcdCluster

$ kubectl -n kube-federation-system get federatedtypeconfigs | grep etcd
etcdclusters.etcd.database.coreos.com    3m16s
而一个Federated资源一般都会具备三个主要功能,这些信息能够在spec中由使用者自行定义,如下范例:
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template: # 定义 Deployment 的所有內容,可理解成 Deployment 与 Pod 之间的关联。
    metadata:
      labels:
        app: nginx
    spec:
      ...
  placement:
    clusters:
    - name: cluster2
    - name: cluster1
  overrides: 
  - clusterName: cluster2
    clusterOverrides:
    - path: spec.replicas
      value: 5
    • Placement :定义Federated资源要分散到哪些集群上,若没有该文件,则不会分散到任何集群中。如FederatedDeployment中的spec.placement定义了两个集群时,这些集群将被同步建立相同的Deployment。另外也支用spec.placement.clusterSelector的方式来选择要放置的集群。
    • Override :定义修改指定集群的Federated资源中的spec.template内容。如部署FederatedDeployment到不同公有云上的集群时,就能通过spec.overrides来调整Volume或副本数。
目前Override不支持List(Array)。比如说无法修改spec.template.spec.containers[0].image。

Scheduling

KubeFed提供了一种自动化机制来将工作负载实例分散到不同的集群中,这能够基于总副本数与集群的定义策略来将Deployment或ReplicaSet资源进行编排。编排策略是通过建立ReplicaSchedulingPreference(RSP)文件,再由KubeFed RSP Controller监听与撷取RSP内容来将工作负载实例建立到指定的集群上。
以下为一个RSP 范例。假设有三个集群被联邦,名称分别为ap-northeast、us-east 与us-west。
apiVersion: scheduling.kubefed.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 15 
  clusters: 
    "*":
      weight: 2
      maxReplicas: 12
    ap-northeast:
      minReplicas: 1
      maxReplicas: 3
      weight: 1
当该范例建立后,RSP Controller会收到资源,并匹配对应namespace/name的FederatedDeployment与FederatedReplicaSet是否存在,若存在的话,会根据设定的策略计算出每个集群预期的副本数,之后覆写Federated资源中的spec.overrides内容以修改每个集群的副本数,最后再由KubeFed Sync Controller来同步至每个集群的Deployment。以上面为例,结果会是ap-northeast集群会拥有3个Pod,us-east跟us-west则分别会有6个Pod。
  • 若spec.clusters未定义的话,则预设为{“*”:{Weight: 1}}。
  • 若有定义spec.replicas 的overrides 时,副本会以RSP 为优先考量。
  • 分配的计算机制可以参考kubefed/pkg/controller/util/planner/planner.go。

Multi-Cluster DNS

KubeFed提供了一组API资源,以及Controllers来实现跨集群Service/Ingress的DNS records自动产生机制,并结合ExternalDNS来同步更新至DNS服务供应商。以下为简单例子:
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: Domain
metadata:
  name: test
  namespace: kube-federation-system
domain: k8s.example.com
---
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: ServiceDNSRecord
metadata:
  name: nginx
  namespace: development
spec:
  domainRef: test
  recordTTL: 300
首先假设已建立一个名称为nginx的FederatedDeployment,然后放到development namespace中,并且也建立了对应的FederatedService提供LoadBalancer。这时当建立上述Domain与ServiceDNSRecord后,KubeFed的Service DNS Controller会依据ServiceDNSRecord文件内容,去收集不同集群的Service信息,并将这些信息更新至ServiceDNSRecord状态中,接着DNS Endpoint Controller会依据该ServiceDNSRecord的状态内容,建立一个DNSEndpoint文件,并产生DNS records资源,最后再由ExternalDNS来同步更新DNS records至DNS供应商。下图是Service DNS建立的架构。

若是Ingress 的话,会由IngressDNSRecord 文件取代,并由Ingress DNS Controller 收集信息。

Setup Federation v2 on AWS

本节将简单说明如何在AWS 建立跨不同地区的Kubernetes 联邦集群,其架构如下图所示。

  • KubeFed 官方文件也提供了On-premises(minikube 与kind)、GKE 与IBM ICP 的教学,来让使用者快速学习如何构建。

事前准备

开始前,需要先安装下列工具到操作机器上来提供使用:
  • kubectl:用来操作部署完成的Kubernetes集群。版本为v1.14.1。
  • kops:用来部署与管理公有云上的Kubernetes集群。版本为v1.14.0。
    • Mac OS X:
    • $ brew update && brew install kops
    • Linux distro:
    • $ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
      $ chmod +x kops-linux-amd64 && sudo mv kops-linux-amd64 /usr/local/bin/kops
  • helm :用来部署Federation v2组件的工具。
  • kubefedctl:用来新增与加入集群成为联邦的工具。可以到连结中下载二进制档,版本为v0.1.0-rc1
  • AWS CLI:用来操作AWS服务的工具。
$ sudo pip install awscli
$ aws --version
aws-cli/1.15.4
上述工具完成后,还要准备一下信息:
  • 申请AWS 帐号,并在IAM 服务新增一个User 设定存取所有服务(AdministratorAccess)。另外这边要记住AccessKey 与SecretKey。
一般来说只需开启S3、Route53、EC2、EBS、ELB 与VPC 权限,但由于偷懒就全开。以下为各AWS 服务在本次安装中的用意:
  • IAM: 提供身份认证与存取管理。
  • EC2: Kubernetes 集群部署的虚拟机环境。
  • ELB: Kubernetes 文件与Service 负载平衡。
  • Route53: 提供Public domain 存取Kubernetes 集群环境与应用。
  • S3: 储存Kops 状态。
  • VPC: 提供Kubernetes 的Host 与CNI 网路环境。
  • 拥有自己的Domain Name,这边可以在AWS Route53 注册,或者是到GoDaddy 购买。

设定脚本参数

教学将使用撰写好的脚本aws-k8s-federation进行部署。首先在操作的节点通过Git取得脚本:
$ git clone https://github.com/kairen/aws-k8s-federation
$ cd aws-k8s-federation
$ cp .env.sample .env
编辑.env档案并修改一下参数:
# Kubernetes version
export KUBERNETES_VERSION="1.14.1"

# Your domain name and envs
export DOMAIN_NAME="k8s.example.com" # 你的 Domain Name( <hoste_dzone_name>.<domain_name>)

建立Route53 Hosted Zone

首先通过aws 工具进行设定使用指定AccessKey 与SecretKey:
$ aws configure
AWS Access Key ID [****************QGEA]:
AWS Secret Access Key [****************zJ+w]:
Default region name [None]:
Default output format [None]:
设定的Keys可以在~/.aws/credentials找到。
接着需要在Route53建立一个Hosted Zone,并在Domain Name供应商上设定NameServers:
$ ./0-create-hosted-domain.sh
# output
...
{
    "HostedZone": {
        "ResourceRecordSetCount": 2,
        "CallerReference": "2018-04-25-16:16",
        "Config": {
            "PrivateZone": false
        },
        "Id": "/hostedzone/Z2JR49ADZ0P3WC",
        "Name": "k8s.example.com."
    },
    "DelegationSet": {
        "NameServers": [
            "ns-1547.awsdns-01.co.uk",
            "ns-1052.awsdns-03.org",
            "ns-886.awsdns-46.net",
            "ns-164.awsdns-20.com"
        ]
    },
    "Location": "https://route53.amazonaws.com/2013-04-01/hostedzone/Z2JR49ADZ0P3WC",
    "ChangeInfo": {
        "Status": "PENDING",
        "SubmittedAt": "2018-04-25T08:16:57.462Z",
        "Id": "/change/C3802PE0C1JVW2"
    }
}
之后将上述NameServers新增至自己的Domain name的record中,如Godaddy:

部署集群

当上述流程都完成后,即可依照脚本顺序来完成Kubernetes 集群与Federation 集群的建立,过程中也会包含操作Federation v2 的功能。最终会以Federated 组件建立一个NGINX 应用,并部署到不同集群中,然后通过MultiClusterDNS + ExternalDNS 来自动建立DNS records 到AWS 上。

Summary
虽然KubeFed 还处于Alpha 阶段,但整体架构基于Federation v1 进行了很多改善,而从GitHub 近几个月的贡献来看,可以发现Red Hat 在此项目投入许多的贡献,这对于KubeFed 来说是很好的发展。而现在KubeFed 官方也有发布来一些文件,用来帮助使用者快速在Minikube、kind(Kubernetes IN Docker)、GCP 上部署,这对于初次接触的人是一项福利。
另外有趣的是从OpenShift v4.0 Roadmap中,也能看到KubeFed被放入其中,在Operator Hub跟federation-v2-operator也能看到Red Hat在这方面的布局。我想之后Kubernetes集群联邦又会再次成为热烈讨论的议题,或许Red Hat也是希望通过KubeFed实现OpenShift的多云(Multi-cloud)与混合云(Hybird Cloud)部署吧(个人觉得拉)。
不过这不完全表示KubeFed 在今后势必会发展得很好,因为随着Kubernetes 发展,想必还会有更多的问题需要去发现、提出与解决的,比如说有状态服务(Stateful Service)、Federation Host集群挂了怎么办等问题,这些问题若之后有相关社群的信息,我也会更新上来。

Related Posts

  • https://k2r2bai.com/2018/03/21/kubernetes/federation-v1/
  • https://k2r2bai.com/2018/04/21/kubernetes/aws-federation-v1/
  • https://speakerdeck.com/kairen/setup-kubernetes-federation-v2-on-aws
  • https://speakerdeck.com/kairen/setup-eks-multi-cluster-using-federation-v2

References

  • https://github.com/kubernetes-sigs/kubefed
  • https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/
  • https://containerjournal.com/2019/04/09/kubernetes-and-the-challenge-of-federation/
  • https://blog.openshift.com/combining-federation-v2-and-istio-multicluster/
  • https://medium.com/condenastengineering/k8s-federation-v2-a-guide-on-how-to-get-started-ec9cc26b1fa7
  • https://podctl.com/multi-cluster-and-federation-v2/
  • https://www.youtube.com/watch?v=q27rbaX5Jis&feature=youtu.be&t=7m20s

Kubernetes 1.15版本正式发布,kubeadm喜提新logo

中文社区阅读(7293)评论(1)

导读:美国时间2019年6月19日,Kubernetes发布了今年第二大版本 Kubernetes 1.15,此次版本共更新加强了25个相关功能,其中2个升级到GA版本,13个升级到beta版,10个alpha版。1.15版本的发布主题是:持续改进和可扩展性。

持续改进:

项目可持续性不仅仅与功能有关。许多SIG一直致力于提高测试覆盖率,确保基础功能持续可靠,核心功能持续稳定。

可扩展性:

Kubernetes社区一直致力于支持可扩展性。1.15版本发布周期中包含更多关于CRD和API Machinery的工作。此次周期中的大多数增强功能来自SIG API Machinery及相关领域。

更深入了解此次版本主要功能:

围绕核心Kubernetes API的可扩展性

在CRD新开发的主题是围绕者数据一致性和原生性。用户考虑重点不会放在是CustomResource还是使用Golang原生资源。在下个版本或后续版本中,将会升级CRD和admissio webhooks 到GA版本。

在这个方向上,社区重新考虑了CRD中基于OpenAPI的验证模式,并且从1.15开始,我们根据称为“structural schema”的限制检查每个资源。这基本上强制执行CustomResource中每个字段的非多态和完整类型。未来需要定义structural schema,尤其是所有新功能,

更多信息可以在这里了解:

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema

beta: CustomResourceDefinition Webhook Conversion

从 1.14版本起,CRD持续在多个小版本中作为beta存在。使用Kubernetes 1.15,他们可以即时在不同版本之间进行转换,就像用户长期使用原生资源一样。CRD的转换是通过集群管理员在集群内部署的webhook实现的。此功能在Kubernetes 1.15中被升级为beta版,将CRD提升到一个全新水平。

beta:CustomResourceDefinition OpenAPI Publishing

kube-apiserver在openAPI/V2上已经为原生类型提供了OpenAPI规范很长一段时间了,它们被许多组件使用,特别是kubectl客户端验证,kubectl解释和基于OpenAPI的客户端生成器。

用于CRD的OpenAPI发布将以Kubernetes 1.15作为测试版提供,但仅适用于structural schemas。

beta: CustomResourceDefinitions Pruning

Pruning是自动删除发送到Kubernetes API的对象中的未知字段。如果未在OpenAPI验证模式中指定字段,则该字段是未知的。这既是数据一致性又是一个和安全相关功能。它强制只将CRD开发人员指定的数据结构持久保存到etcd。这是kubernetes原生资源的行为,也可用于CRD,从Kubernetes 1.15开始为beta。

alpha: CustomResourceDefinition Defaulting

CustomResourceDefinitions默认值支持许可。使用defaultOpenAPI验证模式中的关键字指定默认值。在发送到API的对象中以及从etcd读取时,为未指定的字段设置默认值。

对于structural schemas,从Kubernetes 1.15开始,默认值为alpha。

集群生命周期稳定性和可用性改进

SIG Cluster Lifecycle在1.15版本周期中,主要任务是加强Kubernetes安装、升级、配置稳定,在1.15版本中对生产环境使用,bug修复等高可用性被优先考虑。

kubeadm是集群生命周期构建工具,它的功能稳定性得到进一步提升。kubeadm高可用性(HA)升级到beta版本,允许用户使用熟悉的kubeadm init和kubeadm join命令来配置和部署HA控制平面。社区专门设计了一个全新的测试套件,以确保这些功能随着时间的推移保持稳定。

证书管理在1.15版本中变得更加强大,kubeadm现在可以在证书到期之前,无缝升级所有证书(升级时)。有关如何管理证书的信息,请查看kubeadm文档。

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/

kubeadm配置文件API在1.15中从v1beta1升级到v1beta2。

最后,kubeadm 喜提单独 logo,祝贺!

CSI持续改善

在Kubernetes v1.15中,SIG Storage继续致力于将内部的卷插件迁移到Container Storage Interface(CSI)。SIG Storage致力于将CSI与树内功能进行校验,包括调整大小,内联卷等功能。SIG Storage在CSI中引入了新的alpha功能,这在之前版本Kubernetes Storage子系统中尚不存在,如卷克隆。

卷克隆使用户可以在配置新卷时将另一个PVC指定为“DataSource”。如果底层存储系统支持此功能并在其CSI驱动程序中实现“CLONE_VOLUME”功能,则新卷将成为源卷的克隆。

其他值得注意的新功能:

lKubernetes Core中支持go模块

l继续准备云提供程序提取和代码组织。云提供商代码已移至kubernetes / legacy-cloud-providers,以便以后更容易删除和外部使用。

lKubectl get和describe现在适用扩展

lNode节点现在支持第三方监控插件。

l用于计划插件的新计划框架现在是Alpha

l钩子命令的 ExecutionHook API 现在是Alpha。

l对extensions / v1beta1,apps / v1beta1和apps / v1beta2 API的持续弃用; 这些扩展将在1.16退出!

更多内容可查看:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes

新版下载地址:

Kubernetes 1.15可从GitHub下载。

https://github.com/kubernetes/kubernetes/releases/tag/v1.15.0

开始使用Kubernetes,请查看这些交互式教程。

https://kubernetes.io/docs/tutorials/

您也可以使用kubeadm轻松安装1.15 。

https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

发布团队

新版的发布,是数百名技术和非技术个人共同努力结果,特别感谢Pivotal Software高级技术项目经理Claire Laurence领导的发布团队。发布团队中的38个人协调了发布项目的各个方面,从文档到测试,以及验证和功能完整性。

随着Kubernetes社区的发展,我们的发布过程代表了开源软件开发协作的一个惊人演示。Kubernetes社区持续有新用户加入。这种增长创造了一个积极的社区生态,更多的贡献者提交代码,创建一个更有活力社区, 迄今为止,Kubernetes拥有超过32,000名贡献者,并拥有超过66,000人的活跃社区。

作者:1.15 发布团队

译者:曹辉

原文地址:

https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/

Kubernetes 5周年快乐

中文社区阅读(1652)评论(0)

五年前Kubernetes诞生,当时它还很小,功能有限,只有少数人参与到它的创建。现在,五年之后,kubernetes已经获得了长足的发展,如果是孩子的话,五岁的时候可能才刚上幼儿园,但是kubernetes已经作为工作负载的核心为从初创公司到全球金融机构各种各样的领域提供服务。

kubernetes的成功离不开成千上万贡献者的帮助,kubernetes社区从诞生之初的少数开发者到如今数千名贡献者,只用了短短五年的时间。而如果我们将meetup,文档,版本管理,以及更广泛的社区支持囊括进来的话,贡献者会更多。当然,随着项目的迅速发展壮大,社区也在积极的变更组织方式,以支持其继续取得成功。一个项目能够达到这样的规模并且能继续成功运作,这是一项了不起的成就。

五年后,值得思考kubernetes取得的成就,它是最大的开源项目之一,它在数千名来自不同公司的工程师团队中保持快速发展,它已经合并了成千上万的commit且依旧保持高质量版本的定期发布。能做到这一点,对一个公司来说也是不小的成就,更难能可贵的是,这是由来在来自不同公司的成千上万开发者(其中许多人甚至还在学校)的驱动下完成的。这是社区所有人努力的结果,他们每天辛苦工作,以确保所有ci都是绿色的,版本能够得到修补,安全能够得到维护。对于很多人来说,这项工作通常是乏味的,有时是情绪化的工作,每一位贡献者都应该得到我们最深切的敬意。

当然,kubernetes的故事不只是一个社区的故事,它还是一个技术的故事。kubernetes已经成为组织向云原生技术进行数字化转型的催化剂。它已经成为整个项目和产品生态系统开发的关键点和支撑平台,为开发人员和运营商提供了强大的云原生功能。通过为应用开发提供通用的可扩展的控制平面,Kubernetes成功地提供了一整类更高级别的抽象接口和工具。

kubernetes最重要的一个方面就是知道它的边界在哪里,这从一开始就是该项目的核心原则。虽然kubernetes仍在继续增长,但是它已经接近极限,正因为如此,在核心api之上之外还有一个繁荣的生态系统。从包管理到自动化运维,从workflow到ai,kubernetes api已经成为一个充满活力的云原生生态的基础。

随着kubernetes年满五岁,我们自然会展望未来,并思考如何让它继续蓬勃发展。在庆祝所取得的成果的同时,还必须指出,总有改进的余地。虽然我们的社区庞大而令人惊叹,但是多元化和包容性的社区是一个旅程,而不是目的,我们仍需不断的投入。同时,虽然有云原生技术的承诺,构建可靠的,可扩展的服务仍是一件很困难的事情,在将来,这些是必须进行持续投入以确保持续成功的核心领域。

这是惊人的五年,在你的帮助下,接下来的五年会更加惊人,谢谢。

文章作者:Edison/Lion

来源:容器魔方

微服务治理平台产品化实践与应用微服务化解析

时速云阅读(1210)评论(0)

2019年4月24日,由中国信息通信研究院主办的首届云原生产业大会在北京成功举办,时速云资深架构师赵昕受邀参加了此次大会并发表主题演讲。

赵昕演讲的题目为《微服务治理平台产品化与应用微服务化》。随着微服务被越来越多的企业所了解和认识,针对微服务治理平台的需求和应用微服务化的需求也变得越来越强烈。因此,目前各厂商面临的问题是如何提供符合客户需求的微服务治理平台产品,以及如何协助客户来进行应用微服务化的问题。

针对微服务治理平台产品,目前在市场上有三种主要的形态:

  • 适合虚拟或物理主机搭建的微服务治理平台产品
  • 容器化的微服务治理平台产品
  • 与PaaS平台结合使用的微服务治理平台产品。

以上各形态的微服务治理平台,都有其优缺点。适合传统方式搭建的微服务治理平台,其组件都需要单独的虚拟机或物理机部署,部署过程相对复杂。此外,其组件若要实现高可用,要按照传统方式采用多机热备部署,占用大量的主机资源。而且在此种方式下,微服务治理平台组件与应用的部署环境分离,加大了运维的工作量与运维难度。

以容器化方式部署的微服务治理平台,其组件可以运行在具备 Docker 环境的虚拟机或物理机上。与容器 PaaS 平台解耦,可以在不同厂家的平台上部署。但是其问题是微服务治理平台作为一个应用,其访问入口与 PaaS 入口割裂,不方便使用。

时速云的微服务治理平台是与时速云的 PaaS 平台结合成为一个整体交付给用户。首先,微服务治理平台组件作为应用部署,能够接受 PaaS 平台统一调度管理。同时,用户的微服务应用代码能够与时速云 PaaS 平台的 Devops 功能结合起来,通过流水线,自动的将开发代码项目构建成容器镜像,并在 PaaS 平台上部署起来。同时 PaaS 平台可以管理多个集群,用以将测试环境与生产环境进行分离管理。

服务治理平台,不是单一技术路线的产品,目前支持 spring cloud、service mesh、dubbo,可以为用户提供丰富的选择。同时,针对分布式部署的微服务,时速云的微服务治理平台还提供分布式事务组件,来保证事务的一致性。此外,为了满足容器集群内的应用与外部应用能够进行互相调用,我们还专门定制了 CSB 云服务总线,通过服务订阅的形式,将集群内外的应用 API 开放打通。

我们不仅仅提供治理平台,还希望针对不同的用户能更好与微服务开发结合起来,因此,平台还提供了微服务开发的模板,用户可以自行选择java版本、依赖等来创建自己的代码模板,实现快速上手开发微服务。

当提供了相对完毕的微服务治理平台之后,用户所面临的问题是如何将应用进行微服务化。针对此问题,赵昕进行了六个方面的阐述:

  • 应用微服务化的需求及现况
  • 应用微服务化的优势
  • 应用微服务化的主要步骤
  • 应用微服务化的方法
  • 应用微服务化过程中的问题
  • 咨询服务

目前用户的主要需求在于构建全新的微服务应用及现有的应用改造。但现况是用户的技术程度参差不齐,比如相当一部分用户并没有Docker使用的经验,或者用户有Docker 的使用经验也有应用微服务化的需求,再有用户已有应用微服务化的经验,但形态比较简单。因此,时速云认为应用的微服务化应用需要一套循序渐进的流程来实现:熟悉Docker、Kubernetes->选取试点应用进行容器化->迁移应用至云平台->微服务改造

赵昕表示应用微服务化的价值在于,与传统应用相比,微服务化的应用有诸多优点。

传统单体应用主要缺点有:

  • 复杂性逐渐变高
  • 技术债务逐渐上升
  • 部署速度逐渐变慢
  • 阻碍技术创新
  • 无法按需伸缩

相比直线,微服务应用的主要优点有:

  • 模块独立开发
  • 模块独立部署
  • 独立的可伸缩性
  • 可重用性

因此,应用的微服务化必定会作为应用所演进的方向,为更多的用户接受与使用。

当用户面临微服务改造的时候,必然会经历微服务的拆分,赵昕认为主要有四种拆分方法:

基于业务逻辑拆分

将系统中的业务模块按照职责范围识别出来,每个单独的业务模块拆分为一个独立的服务。

基于可扩展拆分

将系统中的业务模块按照稳定性排序,将已经成熟和改动不大的服务拆分为稳定服务,将经常变化和迭代的服务拆分为变动服务。

基于可靠性拆分

将系统中的业务模块按照优先级排序,将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来,然后重点保证核心服务的高可用。

基于性能拆分

基于性能拆分和基于可靠性拆分类似,将性能要求高或者性能压力大的模块拆分出来,避免性能压力大的服务影响其他服务。

但单纯的提出拆分方法,并不能很好满足用户各类应用微服务拆分的需求,因此,赵昕指出,平台提供商在提供治理平台的同时,还需要提供相应的咨询服务,结合微服务产品的实现,以及在项目落地过程中所遇到的问题,有针对性的提出微服务化的解决方案,这样才能实现产品更好的落地,也能帮助客户快速的实现应用的微服务化,达到平台提供商与客户在技术、经济层面的双赢。

Pod优先级和抢占提高Kubernetes集群资源利用率

中文社区阅读(2270)评论(0)

Kubernetes以运行可扩展工作负载而闻名。它根据资源使用情况调整工作负载。扩展工作负载时,会创建更多应用程序实例。当应用程序对你的产品至关重要时,你希望确保即使在你的群集受资源压力下也会安排这些新实例。解决此问题的一个显而易见的解决方案是过度配置群集资源,以便为扩展情况提供一些闲置资源。这种方法通常有效,但成本更高,因为你必须为大多数时间闲置的资源付费。

Pod优先级和抢占是Kubernetes 1.14里一般可用的调度程序功能,它允许你在不过度配置群集的情况下为关键工作负载实现高水平的调度可信度。它还提供了一种方法来提高群集中的资源利用率,而不会牺牲基本工作负载的可靠性。

保证调度,控制成本

Kubernetes Cluster Autoscaler是K8s生态系统中的一款出色工具,可在你的应用程序需要时为你的群集添加更多节点。但是,群集自动缩放器有一些限制,可能不适用于所有用户:

  • 它在物理集群中不起作用。
  • 向群集添加更多节点的成本更高。
  • 添加节点不是即时的,可能需要几分钟才能使这些节点可用于调度。

另一种选择是Pod优先级(Priority)和抢占(Preemption)。在此方法中,你将多个工作负载组合在一个群集中。例如,你可以在同一群集中运行CI/CD管道,ML工作负载和关键服务。当多个工作负载在同一群集中运行时,群集的大小大于用于仅运行关键服务的群集。如果你为关键服务提供最高优先级,并且CI/CD和ML工作负载的优先级较低,则当你的服务需要更多计算资源时,调度程序会抢占(驱逐)较低优先级工作负载的足够容量,例如ML工作负载,以允许所有你要安排的优先级较高的pod。

使用pod优先级和抢占,你可以在Autoscaler配置中为群集设置最大大小,以确保在不牺牲服务可用性的情况下控制成本。此外,抢占比向群集添加新节点要快得多。在几秒钟内就可以安排高优先级的pod,这对延迟敏感的服务至关重要。

提高集群资源利用率

运行关键服务的集群运营商会随着时间,粗略估计他们在集群中需要的节点数量,以实现高服务可用性。估计通常是保守的。此类估计会考虑流量突发以查找所需节点的数量。可以配置群集自动缩放器永远不会将群集的大小减小到此级别以下。唯一的问题是这种估计通常是保守的,而且大多数时候集群资源可能仍未得到充分利用。Pod优先级和抢占允许你通过在群集中运行非关键工作负载来显着提高资源利用率。

非关键工作负载可能具有多于群集可以运行的pod数量。如果对非关键工作负载给予负数优先级,则当非关键容器挂起时,Cluster Autoscaler不会向群集添加更多节点。因此,你不会产生更高的费用。当你的关键工作负载需要更多计算资源时,调度程序会抢占非关键容器并安排关键容器。

非关键pod填充了群集资源中的“空隙”,可在不增加成本的情况下提高资源利用率。

参与其中

如果你对此功能有反馈意见或有兴趣参与设计和开发,请加入Scheduling特别兴趣小组。

https://github.com/kubernetes/community/tree/master/sig-scheduling

来源:CNCF官微

Kubernetes 2018 年度简史

中文社区阅读(4781)评论(0)

来源:K8sMeetup社区

作者:bot、小君君

技术校对:星空下的文仔

Kubernetes 在过去几年中一直是云计算领域最著名的开源项目之一。

2018 年,Kubernetes 度过了自己的 4 岁生日。从 2014 年开源,到如今成功从 CNCF 孵化,它已成为容器编排的事实标准。虽然 Kubernetes 还很年轻,但它正如初升的朝阳,在过去几年中一往直前,为组织设计和部署应用程序带来全新定义。本文将回顾 2018 年 Kubernetes 的发展情况,同时展望它在 2019 年的前行之路。

分布式计算的新时代

当容器于 2008 年首次推出时,虚拟机(VM)还是云提供商和内部数据中心寻求优化数据中心资产的最佳选择。

在那时,VM 确实提供了良好的灵活性,但它也存在一些缺陷,如每个 VM 都需要在整个层(管理程序)中模拟完全可操作的系统,并大幅占用物理 CPU 资源。即使采用 Intel VT-x 和 AMD-V 等技术,使用 VM 的性能也远不如裸机运行。

在这个背景下,容器技术通过在所有镜像中共享相同的内核来解决这些缺陷。换句话说,来自不同镜像的流程可以在同一空间中运行,而内核负责保证它们之间的正确隔离,我们也可以设置限制镜像资源利用,对计算资源进行合理调配。占用内存更少,又不存在硬件仿真层,因此容器一经提出就迅速走红。

但随着容器广泛进入生产领域,人们很快也意识到一个事实,就是尽管在同一台计算机上部署容器很容易,但它在高可用性管理、灾难恢复和可伸缩性方面仍存在不少问题,优秀的编排层才是在生产中大规模部署容器的必要前提。

这些问题催生了一种名为容器编排系统的新型软件,这种软件也在过去五年中得到了普及。它们负责进行集群操作,协调调度、内存分配、安全性和网络,目的是确保所有镜像按规定工作。

经过激烈竞争,最后,于 2014 年开源的 Kubernetes 力克 Docker Swarm 和 Apache Mesos,成了容器编排领域当之无愧的胜者。它背靠 Google 多年实践,实现了对即时部署、弹性伸缩、健康检查与高可用性(HA)系统的全部覆盖,能为生产完整生命周期保驾护航。

Kubernetes 的 2018

 自身不断发展 

在刚开源的前两年,Kubernetes 只有五个主要版本。从 2017 年起,它相继推出 1.6、1.7、1.8、1.9,围绕稳定性、性能和平台的 cloud availability 做了改进。而在 2018 年,Kubernetes 更进一步,又进行了 4 次重大更新,在企业最关注的安全性和可扩展性上做了显著改善:

  • 2018 年 3 月 27 日,Kubernetes v1.10 发布。此版本持续增强了 Kubernetes 的成熟性、可扩展性以及可插拔性,并在存储、安全、网络增强了其稳定性;
  • 2018 年 6 月 28 日,Kubernetes v1.11 发布。此版本增强了网络功能、可扩展性与灵活性。Kubernetes 1.11 功能的更新为任何基础架构、云或内部部署都能嵌入到 Kubernetes 系统中增添了更多可能性;
  • 2018 年 9 月 28 日,Kubernetes v1.12 发布。此版本新增了两个备受期待的功能,Kubelet TLS Bootstrap 和对 Azure 虚拟机规模集支持(并已达到 GA 阶段)。同时该版本在安全性和 Azure 等关键功能上作出了改进;
  • 2018 年 12 月 4 日,Kubernetes v1.13 发布。此版本是迄今为止发布时间最短的版本之一。这一周期的三个主要特性已逐渐过渡到 GA。此版本中的显着特征包括:使用 kubeadm 简化集群管理、Container Storage Interface(CSI)、以 CoreDNS 作为默认 DNS。

功能方面,Kubernetes 在 1.10 版本中对接了 kubectl 凭证,从此云服务供应商、企业可以发布二进制插件以处理特定云供应商 IAM 服务的身价验证,可扩展性更强。

在 1.13 版本中,CoreDNS 被声明为通过所有规模/资源使用测试的默认集群 DNS。CoreDNS 解决了 kube-dns 存在的安全性和扩展性问题,把 Service 放在一个容器中完成,并用不同插件来复制(并增强)kube-dns 功能,为 Kubernetes 在网络安全方面的长期发展铺好了路。

 社区日渐繁荣 

CNCF 是一个随容器编排和微服务发展起来的新一代基金会,它的设立初衷是在开源社区基础上对现代分布式系统环境进行不断优化。而在 Google 把 Kubernetes 捐献给它后,CNCF 就把管理、支持 Kubernetes 推广发展作为自己的使命。

2018 年,作为 Kubernetes 最强大的支持者,CNCF 为繁荣社区做了许多事,其中又以 3 个孵化项目的成功毕业最为典型:

  • 2018 年 3 月 7 日,CNCF 宣布 Kubernetes 正式毕业;
  • 2018 年 8 月 9 日, Prometheus 成为继 Kubernetes 之后的第二个毕业项目;
  • 2018 年 11 月 28 日,CNCF 宣布 Envoy 成功毕业。

而在不久前刚举办的云容器领域最大的峰会之一 KubeCon + CloudNativeCon North America 2018 上,基金会宣布接受 etcd 分布式键值存储作为孵化项目,发挥它在 Kubernetes 集群管理软件设计中的重要作用;2019 年 1 月 24 日,CNCF 宣布 CoreDNS 毕业,为新一年 Kubernetes 的蓬勃发展打响第一炮。

在 GitHub 上,由于 Kubernetes 在稳定性和成熟性上已经上升到一个新高度,这一年提交数量有所降低,但 Kubernetes 的代码行数还在保持持续增长,且已突破 200 万大关。

尽管谷歌这些年来是 Kubernetes 的主要贡献者,但现在其他技术人员在这个项目上的贡献量已经几乎和谷歌持平了。此外,包括 IBM、Microsoft 等主要云提供商在内的 600 余个组织也为社区发展提供了的重要支持。在国内,华为、才云等组织和机构的贡献也名列前茅。

在 Kubernetes 代码库中导出的 API 端点数量已经稳定在 16,000,这也从侧面印证了 Kubernetes 的成熟度和复杂性水平。

 企业踊跃支持 

Kubernetes 所处的时间点是传统和现代软件开发日益高流量的交叉点。根据 CNCF 统计数据,2018 年,云原生技术增长了 200%,全球有近三分之一的企业正在运营多达 50 个容器,运营 50 至 249 个容器地企业占比也超过 25%,有超过 80% 的受访者把 Kubernetes 作为容器管理的首选。

这些数据都在说明这样一个事实:谁掌握了 Kubernetes,谁就能进一步扩大在云计算市场的竞争力,在风云诡谲的市场上抢占先机。结合这个背景,2018 年同样也是谷歌、亚马逊、微软等大型云提供商围绕 Kubernetes 奋勇争先的一年:

  • 1 月,红帽收购 CoreOS,扩大其 Kubernetes 和容器的领导地位;
  • 2 月,Pivotal 与 VMware 联合开发的企业级容器平台 Pivotal Container Service 1.0(简称 PKS),使运营商能够大规模运营 Kubernetes;
  • 5 月,微软宣布扩大与红帽的合作关系,在 Azure 上提供全托管的 OpenShift,使开发人员能够在 Azure 和本地运行基于容器的应用程序;
  • 6 月,微软宣布 Azure Kubernetes 服务(AKS)可用。 通过 AKS,用户可以部署和管理他们用于生产的 Kubernetes 应用程序;
  • 6 月,亚马逊 EKS 可用。 Amazon EKS 简化了构建、保护、操作和维护 Kubernetes 集群的过程,对企业充分利用基于容器的云计算优势进行简化;
  • 8 月,Google 将 Kubernetes 的云资源控制权移交给 CNCF 社区,并且承诺会在三年内提供价值约 900 万美元的支持;
  • 10 月,IBM 斥资 340 亿美元收购 Red Hat,这是开源领域金额最大的一笔收购,也标志着 IBM 将更强势介入云计算市场,介入 Kubernetes 竞争;
  • 11 月,VMware 用 5.5 亿美元收购 Heptio,借 Kubernetes 加强其在云原生态系统中的角色。

这些举动都在表明云计算市场的战火将继续蔓延,Kubernetes 已经成为兵家必争之地。而根据招聘网站 Dice 的报告,2018 年,Kubernetes 也是最受互联网公司青睐的 IT 技能之一,发展前景不可估量。

 Kubernetes 和 AI 的结合 

这两年,AI 发展得如火如荼,越来越多的企业正在寻求把它用于降低成本和业务创新,同时结合大数据实现企业整体的数字化升级。但再强的算法也需强大的架构和工程作为支撑。

从开发到测试再到生产,容器为流程运行提供了紧凑的环境,它们易于扩展,能将大型完整应用程序分解为有针对性、易于维护的微服务,完美契合 AI 应用开发的各个阶段。因此,Kubernetes 和 AI 的结合也被业界视为大势所趋。

但是,AI 在产品化过程中仍会遇到部署复杂、指令繁冗等种种问题。为了解决这些问题,智能且易于操作的 Kubeflow 应运而生。它可以使机器学习的工作负载分布在多个节点上,极大提高开发人员的工作效率,让 Kubernetes 上的机器学习、深度学习堆栈变得简单、快速、可扩展。

2018 年 11 月 8 日,Google Cloud 宣布推出 Kubeflow Pipelines。它部分基于并利用来自 TensorFlow Extended 的库,允许开发人员利用该工作并将其投入生产,促进了企业内部协作,并进一步实现了访问民主化。

近日,英特尔推出 Kubernetes-Native 深度学习平台 Nauta,这是一个企业级堆栈,适用于需要运行 DL 的工作负载,训练那些将在生产中部署的模型。用户可以在单个或多个工作节点上使用 Kubernetes 定义,安排容器化深度学习实验,并检查这些实验的状态和结果。

“Kubeflow 在简易化 Kubernetes 上配置和生产化机器学习工作负载上取得了重大进步,我们认为这会极大程度上让更多企业接受该平台。” 

—— Reza Shafii,CoreOS 产品副总裁

新的一年,Kubernetes 和 AI 在融合之路上还有很长的一段路需要走,而除了简化整个流程,它们仍将面临在带宽上做出更多突破。

Kubernetes 尚有不足

然而,随着 Kubernetes 被更广泛采用,它也为容器带来了挑战,这涉及从安全性到复杂性再到可扩展性的各个方面。

 可扩展性 

可扩展性包括两部分:基础架构的可扩展性和 API 的可扩展性。

谈到它,首先我们要理解一个概念:微服务。微服务是一项在云中部署应用和服务的技术,它允许公司将其应用程序分解为更小的专用代码包,根据需要进行独立调整和更新。虽然可用性很强,但与之俱来的是网络复杂性,企业难以管理用于构建应用程序的微服务之间的流量,也难以提高这些应用程序执行方式的安全性和可视性。

为了解决这个问题,现在许多供应商开始纷纷采用谷歌、IBM 和 Lyft 开发的开源项目 Istio,以帮助改进云原生网络。

 复杂性 

近日,Nirmata (一家增强企业 DevOps 能力的容器初创公司)的一项研究显示,虽然 Kubernetes 未来可期,但它的复杂性已经成为项目继续发展的一个不可忽视的障碍。根据他们的调查报告,有超过 50% 的开发人员表示曾因 Kubernetes 的复杂操作有过不同程度的困扰。

对简单小型业务来说,Kubernetes 的体量太大了,不如直接用 shell 脚本来得高效直接。因此如果 Kubernetes 想要取得真正的成功,它还要在轻量级和化繁为简上做出更多努力。

 安全性 

同样的,安全性问题也不容小觑。去年,Kubernetes 出现的严重安全漏洞,攻击者可以利用该漏洞通过 Kubernetes API 服务器连接到后端服务器,利用 API 服务器的 TLS 凭证进行身份验证并发送任意请求,从企业防火墙内破坏应用和服务。

而同样是 2018 年,包括特斯拉、Weight Watchers 在内的多家公司也曾遭受 Kubernetes 环境的攻击,原因是他们把 Kubernetes 仪表板打开并暴露在互联网上。这些事故无疑会打击企业对 Kubernetes 的信心。

Kubernetes 的安全性问题是多维度的。一方面,对于一个运行在 Kubernetes 上的普通应用,真正业务代码只占 0.1%,不同的组件都可能存在不同的安全隐患;另一方面,企业的广泛使用和网络安全意识缺失也加剧了问题的严重性。

可喜的是,随着问题的暴露,社区中围绕 Kubernetes 安全的技术项目(如 Notary、TUF 以及谷歌 gVisor)在日益增多,开发者们也正积极地针对漏洞进行补丁和建议。

2019 年预测

随着越来越多的公司将 Kubernetes 视为转向现代化 IT 企业的路标,再结合 2018 年的发展情况,新的一年,我们可以对 Kubernetes 有以下展望:

  • 2019 年,Kubernetes 将完成其作为首选、协调的主导地位;
  • Kubernetes 与大数据的结合将是一种趋势;
  • Kubernetes 快速变化的脚步不会停滞;
  • Kubernetes 安全性或将成为焦点;
  • IT 领导者将对他们的 Kubernetes 平台更加挑剔。

至于屏幕前的你 —— Kubernetes 最亲密的开发者,2019 年,你希望它将在哪些方面实现巨大突破呢?Kubernetes 有你,社区有你,让我们一起期待 Kubernetes 的成长!

Kubernetes-docker守护程序问题处理

Daniel_Ji阅读(2656)

1、检查Docker是否正在运行

在进行具体问题定位和处理之前,最好和最简单直观的方式是先看看docker引擎是否能够正常运行。有以下几种方法可以确认docker是否处于正常运行状态:

1)通过执行docker info命令可以直接确认docker是否正常运行:

$ sudo docker info

2)也可以使用操作系统的命令来检查docker是否正常运行:

$ sudo systemctl is-active docker
# 或者
$ sudo service docker status

3)可以使用ps或top等命令检查进程的进程是否有正常运行的dockerd。

2、解决daemon.json与启动脚本之间的冲突

在Docker中,守护程序会将所有数据都保存在一个根目录中。通过此目录,将能够跟踪到与Docker相关的所有内容,包括容器(containers),镜像(images),存储卷(volumes),服务定义(service definition)和机密(secrets)。默认情况下,此根目录为:

  • Linux环境:/var/lib/docker
  • Windows环境:C:\ProgramData\docker

可以使用data-root配置选项将Docker守护程序的配置为使用其他目录 。由于Docker守护程序的状态保留在此根目录中,因此需要确保每个守护程序使用专用的目录。如果两个守护程序共享同一根目录(例如,NFS共享),将可能会导致故障的无法处理的情况。

在docker引擎中,如果使用了daemon.json文件,同时通过手动或使用启动脚本将选项传递给dockerd命令,并且这些选项间存在冲突,则会导致Docker无法启动,例如:

unable to configure the Docker daemon with file /etc/docker/daemon.json:
the following directives are specified both as a flag and in the configuration
file: hosts: (from flag: [unix:///var/run/docker.sock], from file: [tcp://127.0.0.1:2376])

如果看到类似于上述内容的错误,并且使用此标志手动启动守护程序,则可能需要调整命令字段或daemon.json以解决冲突。如果使用操作系统的初始脚本启动Docker,则可能需要以特定于操作系统的方式覆盖这些脚本中的默认值。

2.1 在DAEMON.JSON中使用HOSTS密钥

默认情况下,Docker会监听套接字(socket)。在Debian和Ubuntu操作系统中使用启动docker时,-H字段会一直被使用。如果在daemon.json指定了一个 hosts条目,则会导致配置冲突,从而导致Docker无法启动。为了解决此问题,请/etc/systemd/system/docker.service.d/docker.conf使用以下内容创建一个新文件,以删除默认情况下启动守护程序时使用的-H参数。

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

3、查看日志

守护程序的日志可以帮助诊断问题,docker守护程序日志的具体存储位置取决于操作系统配置和使用的日志记录子系统:

操作系统 目录
RHEL,Oracle Linux /var/log/messages
Debian /var/log/daemon.log
Ubuntu 16.04+,CentOS 使用journalctl -u docker.service命令检查日志
Ubuntu 14.10- /var/log/upstart/docker.log
macOS(Docker 18.01+) ~/Library/Containers/com.docker.docker/Data/vms/0/console-ring
macOS(Docker <18.01) ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/console-ring
Windows AppData\Local

4、启用调试

在daemon.json文件中将 debug键的值设置为true就可以启用docker的调试模式,此方法适用于每个Docker平台。

  1. daemon.json文件通常位于/etc/docker/目录,如果该文件尚不存在,则需要手动创建此文件。
  2. 如果文件为空,请添加以下内容:
    {
      "debug": true
    }
    

    如果文件中已经包含JSON,则只需添加键值对”debug”: true,如果它不是文件中的最后最后一行,请在行尾添加“;”。同时需要确认log-level是否已设置为info或debug。默认值为info,可能的值包括debug,info,warn,error,fatal。

  3. 向守护程序发送hup信号以使其重新加载新的配置。在Linux主机上,使用以下命令。
    $ sudo kill -SIGHUP $(pidof dockerd)
    

也可以手动停止Docker守护程序,并使用debug的-D字段标志重新启动它。

5、强制记录堆栈跟踪

如果守护程序没有响应,则可以通过向SIGUSR1守护程序发送信号来强制记录完整堆栈跟踪。

$ sudo kill -SIGUSR1 $(pidof dockerd)

这会强制记录堆栈跟踪,但不会停止守护程序。守护程序日志显示堆栈跟踪或包含堆栈跟踪的文件的路径(如果已记录到文件)。处理完SIGUSR1信号并将堆栈跟踪转储到日志后,守护程序继续运行。堆栈跟踪可用于确定守护程序中所有goroutine和线程的状态。

5.1 查看堆栈跟踪

可以使用以下方法之一查看Docker守护程序日志:

  • 在Linux系统上执行journalctl -u docker.service命令;
  • 在较旧的Linux系统上,查看/var/log/messages,/var/log/daemon.log或/var/log/docker.log

在Docker日志中查找如下消息:

...goroutine stacks written to /var/run/docker/goroutine-stacks-2017-06-02T193336z.log
...daemon datastructure dump written to /var/run/docker/daemon-data-2017-06-02T193336z.log

Docker保存这些堆栈跟踪和转储的位置取决于操作系统和配置,有时可以直接从堆栈跟踪和转储中获取有用的诊断信息。

 

 

参考资料:

1.《Configure and troubleshoot the Docker daemon》地址:https://docs.docker.com/config/daemon/

作者简介:
季向远,本文版权归原作者所有。

CNCF调查:自2018年3月以来,亚洲云使用率增长135%

中文社区阅读(3972)评论(0)

一年两次的 CNCF 调查让社区紧跟时代脉搏,更好地了解云原生技术的采用情况。这是 CNCF 第二次用普通话进行云原生调查,以更好地衡量亚洲公司如何采用开源和云原生技术。之前的普通话调查已于 2018 年 3 月进行。本文还将与 2018 年 8 月以来北美/欧洲最新的同文调查版本进行比较。

重要结论

  • 自 2018 年 3 月以来,亚洲公共云和私有云的使用量增长 135%,而本地使用量下降 48%。
  • 亚洲几乎所有容器管理工具的使用率都有所增长,现成商业解决方案总体增长 58%,本土解决方案增长 690%。Kubernetes 增长 11%。
  • Kubernetes 集群在生产中的数量正在增加。运行 1-5 个生产集群的亚洲组织减少 37%,而运行 11-50 个集群的受访者增加 154%。
  • 在亚洲,无服务器技术的使用率激增了 100%,29% 的受访者使用可安装软件,21% 的受访者使用托管平台。

300 人回复了中文版调查,其中 83% 来自亚洲,相比之下,我们 2018 年 3 月的调查中有 187 人回复。

CNCF 在中国, 日本和韩国共有 42 位会员,其中包括 4 位白金会员:阿里云, 富士通, 华为和京东 (JD.com)。其中 某些成员也是终端用户,包括:

  • 京东 (JD.com),第一家跻身全球财富 500 强的中国互联网公司,从 OpenStack 迁移至 Kubernetes,资源利用率提高 30%。
  • 华为,作为世界上最大的电信设备制造商,迁移至云原生环境后,运营成本削减 20-30%。
  • 据《福布斯》报道,2018 年世界上最具创新性的公司之一,雅虎日本利用 Kubernetes 自动进行生产部署 。
  • 中国移动是中国最大的运营商之一,其使用容器代替虚拟机在平台上运行各种应用程序,利用 Kubernetes 提高资源利用率。

容器的增长

在开发周期的所有阶段均使用容器已经成为常态利用容器进行测试的人数大幅增加,从 2018 年 3 月的 24% 增加到 42%,另外 27% 的受访者提到未来计划采用。用于概念验证的容器使用也有所增加(从 8% 上升到 14%)。

 

随着容器的使用在所有开发阶段日益普遍,容器管理工具的使用也越来越多。自 2018 年 3 月以来,几乎所有容器管理工具的使用都大幅增加。

自 2018 年 3 月以来, Kubernetes 的使用量增长 11%。其他工具的使用也有所增加:

  • Amazon ECS:从 13% 上升至 22%
  • CAPS:从 1% 上升至 13%
  • Cloud Foundry:从 1% 上升至 20%
  • Docker Swarm:从 16% 上升至 27%
  • Shell Scripts:从 5% 上升至 14%

也有 2018 年 3 月的调查中没有提及的两个新工具。16% 的受访者使用 Mesos,另外 8% 使用 Noman 进行容器管理。

 

现成的商业解决方案(Kubernetes, Docker Swarm, Mesos 等)总体增长 58%,而本土管理(Shell Scripts 和 CAPS)增长 690%,这表明本土解决方案在亚洲仍然很受欢迎,而北美和欧洲市场则不再青睐 COTS 解决方案。

云与本地部署

虽然北美和欧洲市场广泛使用本地解决方案 (64%),但在亚洲市场,这一数字似乎在下降。在本次调查中,只有 31% 的受访者报告了使用本地解决方案,相比之下,2018 年 3 月这一比例为 60%。云使用率正在增长,43% 的受访者使用私有云(从 24% 上升,51% 的受访者使用公共云(从 16% 上升。

Kubernetes

至于在何处运营  Kubernetes,阿里巴巴仍是第一,38% 的受访者报告正在使用,但低于 2018 年 3 月的 52%。紧随阿里巴巴之后的是亚马逊网络服务 (AWS),24% 的受访者提到使用,略低于 26%。

以前未报告过,但正在占据额外市场份额的新环境是华为云 (13%), VMware (6%), 百度云 (21%), 腾讯云 (7%),IBM 云 (8%) 和 Packet (5%)。

这些回应中也显示,本地使用量下降,24% 的受访者报告说,他们在本地运行 Kubernetes,而 2018 年 3 月这一比例为 38%。OpenStack 的使用率也大幅下降,从 2018 年 3 月的 26% 降至 9%。

对于运行 Kubernetes 的组织而言,生产集群的数量也在增加。运行 1-5 个生产集群的受访者减少 37%,而运行 11-50 个集群的受访者增加 154%。尽管如此,受访者大多运营 6-10 个生产容器,29% 的受访者报告这一数字。

我们还向受访者询问了他们用于管理应用程序各个方面的工具:

封装

封装 Kubernetes 应用程序最流行的方法是 Managed Kubernetes Offerings (37%),其次是 Ksonnet (27%) 和 Helm (24%)。

自动扩展

受访者主要对任务和队列处理应用程序 (44%) 和 Java 应用程序 (44%) 使用自动扩展。其次是无状态应用程序 (33%) 和有状态数据库 (29%)。

受访者未使用 Kubernetes 自动扩展功能的最大原因是因为,其使用第三方自动扩展解决方案 (32%),不知道这些功能存在 (30%),或者已经构建了自己的自动扩展解决方案 (26%)。

入口提供商 (Ingress Providers)

据报告,Kubernetes 最大的入口提供商是 F5 (36%), nginx (34 %) 和 GCP (22%)。

公开集群外部服务 (Cluster External Services)

公开集群外部服务最流行的方式是负载平衡器服务 (43%), 与第三方负载平衡器的集成 (37%)和 L7 入口 (35%)。

在拥有多个团队的组织中分离 Kubernetes

受访者使用命名空间 (49%), 单独集群 (42%)和仅使用标签 (34 %),将组织内的多个团队分开。

分离 Kubernetes 应用程序

受访者主要使用单独的集群 (45%), 命名空间 (46%) 和标签 (33%),分离他们的 Kubenetes 应用程序。

云原生项目

云原生项目在生产中有什么优点?受访者列举了前四个原因:

  • 提高可用性 (47%)
  • 改进可扩展性 (46%)
  • 云便携性 (45%)
  • 提高开发人员的工作效率 (45%)

与北美和欧洲市场相比,提高可用性和开发人员工作效率在亚洲市场更为重要,而更快的部署时间则不那么重要(只有 38% 的受访者提到了这一点,而在本调查的英文版本中这一比例为 50%。

至于生产和评估中使用的云原生项目:

自 2018 年 3 月以来,许多云原生项目的生产使用率有所增长。生产使用率最高的项目是:gRPC(从 13% 上升至 22%, Fluentd(从 7% 上升至 11%, Linkerd(从 7% 上升至 11%,OpenTracing(从 20% 上升至 27%。

评估云原生项目的受访者数量也在增长:gRPC(从 11% 上升到 20%), OpenTracing(从 18% 上升到 27%)和 Zipkin(从 9% 上升到 12%。

未来的挑战

随着云原生技术不断被采用,尤其是在生产中,仍然有挑战需要解决。受访者面临的最大挑战是:

  • 缺乏培训 (46%)
  • 难以选择编排解决方案 (30%)
  • 复杂性 (28%)
  • 寻找供应商支持 (28 %)
  • 监控 (25%)

我们注意到一个有趣的现象,自 2018 年 3 月的上一次调查以来,随着更多资源用于解决这些问题,许多挑战已经显著减少。出现的一个新挑战是缺乏培训。虽然 CNCF 在过去的一年中在Kubernetes 培训方面投入了大量资金,包括 Kubernetes 管理员和应用程序开发人员的课程和认证,但我们仍在积极努力使这些课程和认证的翻译版本在亚洲更容易访问。CNCF 还与 Kubernetes 培训合作伙伴的全球网络合作,以扩展这些资源,并与Kubernetes 认证服务提供商]合作,帮助支持复杂的组织踏上云原生之旅。

无服务

无服务器技术的使用在使用此技术的组织中激增 50%,而 2018 年 3 月这一比例为 25%。在这 50% 中,29% 使用可安装软件,21% 使用托管平台。另外 17% 的受访者计划在未来 12-18 个月内采用这项技术。

对于可安装的无服务器平台,Apache openshill 最受欢迎,有 11% 的受访者提到正在使用。其次是 Dispatch (6%), FN (5%) 和 OpenFaaS, Kubeless,和 Fission,并列 4%。

对于托管式无服务器平台,AWS Lambda 最受欢迎,有 11% 的受访者提到正在使用。其次是 Azure Functions (8%),阿里云 Compute Functions, 谷歌云 Functions 和Cloudflare Functions 并列 7%。

亚洲的无服务器使用量高于北美和欧洲市场,其中,38% 的组织使用无服务器技术。与可安装软件 (6%) 相比,托管平台 (32%) 也更受欢迎,而在亚洲,这两种选择的使用更均匀。使用的解决方案也多种多样,而 AWS Lambda 和 kubeness 显然是北美和欧洲的领导者。

关于回到 CNCF 项目,一小部分受访者现在正在评估 (3%)或在生产中使用 CloudEvents(2%)。CloudEvents 是由 CNCF 无服务器工作组 组织的一项工作,旨在创建以一种通用方式描述事件数据的规范。

云原生在中国生根发芽

随着云原生在中国的持续增长,学习有关这些技术的方法变得越来越重要。以下是受访者了解云原生技术的主要方式:

文档

50% 的受访者通过文档学习。 每个 CNCF 项目在网站上都有大量文档,可以在此处找到。尤其是 Kubernetes,目前正致力于采用多种语言翻译其文档和网站,包括日语, 韩语, 挪威语和汉语。

技术播客

48% 的受访者通过技术播客学习。有各种各样的云原生播客可供学习,例如,谷歌的 Kubernetes 播课和 Red Hat 的PodCTL b。此外,可以查看 您应当留意的 10 个中国技术播客。

技术网络研讨会

29% 的受访者通过技术网络研讨会学习。CNCF 每周星期二上午 10 点到 11 点举办一次网络研讨会系列。您可以查看即将到来的时间表,或查看 之前网络研讨会的录音和幻灯片。

商业案例研究

27% 的受访者通过商业案例学习。CNCF 收集了终端用户案例研究 ,而 Kubernetes 也保留了大量的Kubernetes 特定用户案例研究列表。

中国的云原生社区

随着云原生技术在亚洲的持续增长,CNCF 很期待本周在上海举办首届 KubeCon + CloudNativeCon 年会。有 1,500 多名与会者参加开幕式,我们期待看到云原生技术在全球范围内的持续增长。

若要了解最新的新闻和项目,请参加我们在亚洲举办的 22 场云原生交流会。我们期待着在即将举行的会议上与您见面!

衷心感谢每一位调查参与人员!

您也可以在这里查看过去调查的结果:

  • 2018 年 8 月:生产中使用云原生技术增长 200%
  • 2018 年 3 月:云技术在中国遍地开花
  • 2017 年 12 月:云原生技术正在扩展生产应用程序
  • 2017 年 6 月:调查显示,Kubernetes 是领先的编排平台
  • 2017 年 1 月:Kubernetes 从测试走向生产
  • 2016 年 6 月:容器调查
  • 2016 年 3 月:容器调查结果

关于调查方法和受访者

受访者代表各种公司规模,其中大多数在 50-499 名员工范围内 (48%)。至于工作职能,受访者大多数为开发人员 (22%), 开发经理 (15%) 和 IT 经理 (12%)。

受访者代表了 31 个不同的行业,主要为软件 (13%) 和金融服务 (11%) 行业。

此项调查采用普通话进行。下列为其他人口学统计数据:

来源:CNCF官微,https://mp.weixin.qq.com/s/GtGICwYzvCJEuMDv5YDKBQ


阿里巴巴全面容器化,支持双11爆量PouchContainer发布1.0,Windows Server 2019正式版来了

中文社区阅读(4577)评论(0)

近日,阿里巴巴揭露了内部架构全面容器化的历程,目前阿里巴巴和蚂蚁金服集团多数事业部门,都已经采用了阿里巴巴去年11月开源的企业级容器平台PouchContainer,这套平台也遵循开源容器标准OCI,可与Docker兼容。阿里巴巴透露,去年双11购物节也是靠PouchContainer才撑过爆量交易的需求,高峰期启动了超过百万个容器来执行交易程序。PouchContainer也针对不同应用场景所需的容器配置进行优化,包括了电商平台、数据库、串流计算、大数据分析等。目前PouchContainer也刚于9月正式发布了1.0版。
阿里巴巴指出,PouchContainer和其他容器平台最大不同是,特别考虑了后续维运的需求,在隔离、镜像推送优化、丰富容器模式、扩充性和核心兼容性(兼容于Docker、Kubernetes等)都有强化。

Windows Server 2019正式版来了,支持KubernetesLinux容器

微软新版企业级操作系统Windows Server 2019正式版正式在10月出炉,主打四大特色,包括了混合云、安全、应用程序平台及超融合基础架构。还新增了以浏览器为基础的服务器管理套件Windows Admin Center(1809版),可支持私有云和Azure的混合云应用架构,更容易将既有的Windows Server部署,连结至云端的Azure服务。而System Center 2019则要等到明年上半年才问世。

另外,在应用平台功能上,Windows Server 2019也将Server Core的容器镜像大小,也从5GB缩减了三分之一,以加速镜像的下载,并改善程序的兼容性,也支持Service Fabric、Kubernetes与Linux容器。另外在超融合基础架构部署上,新版也从过去只支持2个节点,增加到可部署到100个服务器的规模。微软也同时宣布将在2020年终止支持旧版的Windows Server 2008和Windows Server 2008 R2。

参考:https://www.ithome.com.tw/news/126430

https://www.ithome.com.tw/news/126431