深度解析Istio系列之安全模块篇

于 2019-03-13 14:07:58 发布
阅读量589 收藏 1
点赞数
分类专栏： 博云技术社区 文章标签： istio
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/squirrelanimal0922/article/details/88531075
版权

单体应用拆分为微服务之后，提高了开发效率，增加系统系统稳定性，提高运维效率等等一系列的好处，但随之也带来了安全方面的风险，之前都是本地调用，现在都改为走网络协议调用接口，今天着重介绍的是微服务架构中的新贵Istio中安全模块分析，Istio安全的三大目标：

  • 默认安全（Security by default）：应用程序代码和基础结构无需更改。

  • 深度防御（Defense in depth）：与现有安全系统集成，提供多层防御。

  • 零信任网络（Zero-trust network）：在不受信的网络上，构建安全解决方案。

 

架构

 

 

如上图，Istio安全涉及到组件有：

  • Citadel 用于密钥和证书的管理。

  • Proxy 实现客户端与服务器端安全通信。

  • Pilot 将授权策略和安全命名信息分发给代理。

  • Mixer：校验授权和审计。

 

 

Istio 身份

 

身份信息

身份信息是安全基础架构的基本概念，在服务和服务的通信开始前，双方必须用其身份信息交换凭证，以达到相互认证的目的，根据安全信息达到鉴权的目的，同时根据身份信息可以进行审计，在kubernetes的环境下Istio身份标识使用Service Account。

 

PKI

PKI（Public Key Infrastructure）建立在Istio citadel 之上，Istio 使用 X.509 证书来携带 SPIFFE 格式的身份信息，PKI 还可以大规模自动化地进行密钥和证书轮换。

 

证书生成流程

基于kubernetes环境下证书生成流程如下：

 

 

citadel同时也会监听每个证书的生命周期，通过重写 Kubernetes secret 自动轮换证书。Pilot生成安全信息即授权信息，Pilot将授权信息分发给envoy每个命名空间下有个default serviceaccount，citadel会为它创建一个名为istio.default的secret。

[root@kube01 ~]$ kubectl -n foo get secrets 

NAME                  TYPE                                  DATA      AGE 

default-token-bdpmg   kubernetes.io/service-account-token   3         8d 

istio.default         istio.io/key-and-cert                 3         8d

 

默认在该命名空间下新建的istio应用都使用该secret。

istio-certs:

     Type:        Secret (a volume populated by a Secret)

     SecretName:  istio.default

     Optional:    true

 

当为deployment指定了非默认serviceaccount，则秘钥也将使用新的secret。

istio-certs:

     Type:        Secret (a volume populated by a Secret)

     SecretName:  istio.bookinfo-productpage

     Optional:    true

 

 

认证

 

Istio提供两种类型的身份验证：

  • 传输身份验证，也称为服务到服务身份验证：验证直接客户端进行连接。Istio提供相互TLS 作为传输身份验证的完整堆栈解决方案。

  • 源身份验证，也称为最终用户身份验证：验证将请求作为最终用户或设备的原始客户端。

具体信息参见官网，本文章主要介绍第一种。

 

相互 TLS身份验证（mTLS）

mTLS本身流程如下图所示：

 

 

在Istio握手期间，客户端envoy还进行安全命名检查，验证服务器证书中提供的服务账户是否有权限运行目标服务。

 

认证架构

 

通过yaml文件配置身份认证策略，部署后策略保存在Istio配置存储中，Pilot监听配置存储，当发生变化后Pilot将策略转变为适当的配置（envoy识别的配置等），再通知envoy如何执行身份认证机制，Pilot提供Istio系统管理的密钥和证书的路径，并将它们安装到应用程序mesh以进行相互TLS。Istio通过异步发送配置到目标端点，代理收到消息后，新的身份认证立即生效。

 

认证架构如下图所示：

 

 

部署影响

 

在部署Istio平台时，通过yaml则是istio-demo-auth.yaml，该yaml安装为所有控制面板中envoy添加了tls相关信息，在helm中则是global.controlPlaneSecuretyEnable: true，开启后实质是为controlPlaneAuthPolicy: MUTUAL_TLS，分析添加该属性后发生的变化如下：

 

控制面板

Istio-policy,istio-telemetry,istio-pilot，三个组件在istio-proxy中envoy进程启动时会指定配置文件，依次为envoy_policy.yaml,envoy_telemetry.yaml,envoy_pilot.yaml，在这些文件中相同都增加如下：

"tls_context": {

         "common_tls_context": {

 "alpn_protocols": "h2", 

"tls_certificates": {

 "certificate_chain": {

 "filename": "/etc/certs/cert-chain.pem"

 },

 "private_key": {

 "filename": "/etc/certs/key.pem"

 }

 }, 

"validation_context": { 

"trusted_ca": { 

"filename": "/etc/certs/root-cert.pem"

 }, "verify_subject_alt_name": [

 "spiffe://cluster.local/ns/istio-system/sa/istio-pilot-service-account"

 ] 

} 

}

 

在模板文件地址 实质判断controlPlaneAuthPolicy的值，如果这个值设置None，则当开启网格策略mtls后，控制面板各个组件不支持tls，导致转发失败，必须设置到控制面板目标规则mode为DISABLE才可以，否则会导致握手失败，报错503，如下所示：

[2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/network/connection_impl.cc:466] [C127] connected 

[2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:113] [C127] handshake error: 2 

[2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:113] [C127] handshake error: 5 

[2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/network/connection_impl.cc:133] [C127] closing socket: 0

 

数据面板

数据面板中该值controlPlaneAuthPolicy：None不影响mtls功能使用（如果有误请联系更改）。

 

认证策略

 

Istio可以在命名空间范围或网格范围中存储身份认证策略，使用官网实例sleep访问httpbin进行测试，访问过程如下图所示：

 

 

部署官网示例，步骤1：

$ kubectl create ns foo 

$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo 

$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo 

$ kubectl create ns bar 

$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar 

$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar 

$ kubectl create ns legacy 

$ kubectl apply -f samples/httpbin/httpbin.yaml -n legacy 

$ kubectl apply -f samples/sleep/sleep.yaml -n legacy

此时执行，步骤2：

for from in "foo" "bar"; do for to in "foo" "bar"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done

 

返回结果皆为200，目前是未开启mtls。

 

网格范围策略

 

使用MeshPolicy，没有目标选择器部分。可以有最多一个网格范围的策略在网格中，启用mtls配置如下：

cat <<EOF | kubectl apply -f - 

apiVersion: "authentication.istio.io/v1alpha1" 

kind: "MeshPolicy" 

metadata:

   name: "default" 

spec:

   peers:

   - mtls: {} 

EOF

 

此时再次执行步骤2则结果都为503，需要增加目标规则配置，如下所示：

cat <<EOF | kubectl apply -f - 

apiVersion: "networking.istio.io/v1alpha3" 

kind: "DestinationRule" 

metadata:

   name: "default"

   namespace: "default" 

spec:

   host: "*.local"   trafficPolicy:

     tls:

       mode: ISTIO_MUTUAL 

EOF

 

此时再次执行步骤2则结果为200正常。

 

分析开启mtls后envoy发生的变化，在listeners的filter链中增加了tlsContext相关配置。

//使用istioctl proxy-config分析envoy istioctl proxy-config listeners -n foo httpbin-66dc4dd499-8fjgb --port 8000 -o json 



//输出如下： 

... 

"filterChains": [

             {

                 "tlsContext": {

                     "commonTlsContext": {

                         "tlsCertificates": [

                             {

                                 "certificateChain": {

                                     "filename": "/etc/certs/cert-chain.pem"

                                 },

                                "privateKey": {

                                     "filename": "/etc/certs/key.pem"

                                 }

                             }

                         ],

                         "validationContext": {

                             "trustedCa": {

                                 "filename": "/etc/certs/root-cert.pem"

                             }

                         },

                         "alpnProtocols": [

                             "h2",

                             "http/1.1"

                         ]

                     },

                     "requireClientCertificate": true

                 } 

...

 

注意：当controlPanleAuth配置为None时，只是配置这两个配置访问依然为503，原因是控制面板不支持tls配置，如部署影响中有讲到，如果为None时也想让该示例生效，需要增加目标规则，目标规则中指定到控制面板的数据流不开启mtls，使用明文访问，如下所示：

cat <<EOF | kubectl apply -f - 

apiVersion: "networking.istio.io/v1alpha3" 

kind: "DestinationRule" 

metadata:

   name: "istio-system-manage-dr"

   namespace: "istio-system" 

spec:

   host: "*.istio-system.svc.cluster.local"

   trafficPolicy:

     tls:

       mode: DISABLE 

EOF

 

当拥有sidecar的应用开启mtls后想要访问非Istio服务，也是需要配置tls：DISABLE，如下所示：

cat <<EOF | kubectl apply -f - 

apiVersion: networking.istio.io/v1alpha3 

kind: DestinationRule 

metadata:

  name: "httpbin-legacy" 

spec:

  host: "httpbin.legacy.svc.cluster.local"

  trafficPolicy:

    tls:

      mode: DISABLE 

EOF

 

命名空间范围策略

 

具有名称default且没有目标选择器部分。每个命名空间最多只能有一个名称空间范围的策略。它使用kind “Policy”，需要指定命名空间名称，如下所示：

cat <<EOF | kubectl apply -f - 

apiVersion: "authentication.istio.io/v1alpha1" 

kind: "Policy" 

metadata:

   name: "default"

   namespace: "foo" 

spec:

   peers:

   - mtls: {} 

EOF

 

与网格范围策略一样，也需要指定目标规则，如下所示：

cat <<EOF | kubectl apply -f - 

apiVersion: "networking.istio.io/v1alpha3" 

kind: "DestinationRule" metadata:

   name: "default"

   namespace: "foo" 

spec:

   host: "*.foo.svc.cluster.local"

   trafficPolicy:

     tls:

       mode: ISTIO_MUTUAL 

EOF

 

开启命名空间范围策略只是针对当前命名空间，对于控制面板下的服务没有任何影响，还是使用明文访问。

 

 

授权

 

Istio授权功能，基于角色的访问控制（RBAC），为Istio中服务提供命名空间级别、服务级别、方法级别的访问控制，特点是：

  • 基于角色的语义，简单易用。

  • 服务到服务和最终用户到服务授权。

  • 通过自定义属性支持（例如条件，角色和角色绑定）提供灵活性。

  • 高性能，因为Istio授权在Envoy上本地执行。

 

授权架构

 

 

用户使用.yaml配置Istio授权策略，部署完成后同样存储在Istio配置存储，Pilot监听Istio授权变化，如果发生变化Pilot获取更新的授权策略，将Istio授权策略分发给与服务实例位于同一位置的Envoy代理，每个Envoy代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果，ALLOW或DENY。

 

启用授权

 

使用RbacConfig对象启用Istio授权，是一个单例，固定名称为default，在RbacConfig中可以指定一个mode值，该值可以是：

  • OFF：禁用Istio授权。

  • ON：为网格中的所有服务启用了Istio授权。

  • ON_WITH_INCLUSION：仅对inclusion字段中指定的服务和命名空间启用Istio授权。

  • ON_WITH_EXCLUSION：对网格中的所有服务启用Istio授权，但exclusion 字段中指定的服务和命名空间除外。

 

开启授权，如下所示：

apiVersion: "rbac.istio.io/v1alpha1"

kind: RbacConfig 

metadata:

   name: default 

spec:

   mode: 'ON_WITH_INCLUSION'

   inclusion:

     namespaces: ["default"]

 

当开启rbacconfig后，正常的bookinfo示例已经不可以访问，提示“RBAC: access denied“。

 

授权策略

 

使用bookinfo测试授权策略，配置策略，使用ServiceRole和ServiceRolebinding：

  • ServiceRole：定义一组访问服务的权限。

  • ServiceRoleBinding：将权限授权给特定主体，例如用户，组，服务。

 

ServiceRole

每条规则都以以下标准字段：

  • services：服务名称列表。您可以将值设置*为包括指定命名空间中的所有服务。

  • methods：HTTP方法名称列表，对于gRPC请求的权限，HTTP谓词始终是POST。您可以将值设置*为包括所有HTTP方法。

  • paths：HTTP路径或gRPC方法。gRPC方法必须采用以下形式/packageName.serviceName/methodName并且区分大小写。

 

具体参考官网。

 

创建一个ServiceRole，如下所示：

apiVersion: "rbac.istio.io/v1alpha1" 

kind: ServiceRole 

metadata:

   name: service-viewer

   namespace: default 

spec:   rules:

   - services: ["*"]

     methods: ["GET"]

     constraints:

     - key: "destination.labels[app]"

       values: ["productpage", "details", "reviews", "ratings"]

 

允许只读访问default命名空间下所有带有指定标签的服务。

 

ServiceRoleBinding

ServiceRoleBinding规范包括两个部分：

  • roleRef指的是ServiceRole同一名称空间中的资源。

  • subjects分配给该角色的列表。

 

如下所示：

apiVersion: "rbac.istio.io/v1alpha1" 

kind: ServiceRoleBinding 

metadata:

   name: bind-service-viewer

   namespace: default 

spec:

   subjects:

   - properties:

       source.namespace: "istio-system"

   - properties:

       source.namespace: "default"

   roleRef:

     kind: ServiceRole

     name: "service-viewer"

 

将ServiceRole授权给命名空间为“istio-system”和“default”。

 

至此Istio安全模块分析到此结束，其中还有很多点本文未涉及，请到官网学习（https://istio.io/docs/concepts/security/），官网是第一手资料，同时如果本文中存在的问题，请随时联系马上改正，谢谢。

博云技术社区
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
博客
【博云2023】乘龙一跃腾云海，侧目抬手摘星河
02-08 902
在这个既是挑战也是机遇的新时代，博云愿与所有追梦人共同携手，不仅为客户提供更加优质的产品和服务，更要为社会的持续发展贡献力量。在未来的征途中，博云公司将继续以技术创新为核心动力，以客户需求为导向，不断探索和突破新技术、新模式、新领域。此外，AIOS对主流的分布式AI深度学习框架提供了支持，实现了算法、模型及组件的可视化开发，并全面覆盖了从数据管理到模型训练、在线推理的整个生命周期。我们坚信，通过不断的努力和探索，博云将能够在技术创新的大潮中乘风破浪，与所有伙伴们一起，开创属于我们的星辰大海。
博客
博云科技与中科可控全面合作，探索前沿金融科技新机遇
01-30 412
江苏博云将与中科可控携手在昆山高新区并肩前行，建立长期、稳定、互惠、互利的全面合作关系，共同推动国产软硬件技术的创新与发展，为客户提供更优质的产品与服务。
博客
博云科技加入阿里云“金融先锋联盟”，携手共创金融AI蓝图
01-26 154
博云加入阿里云金融先锋联盟，成为阿里云AI蓝图的合作伙伴，双方联合发布【云原生一体化平台】既具备阿里云大厂夯实的技术能力，又具备博云专业厂商的个性化服务能力。
博客
连续四年入选！三项荣耀！博云科技强势上榜Gartner ICT技术成熟度曲线
08-08 253
2020年，当容器云还处在萌芽阶段，市场渗透率仅为5%-20%阶段，作为国内最早一批容器技术厂商，博云科技首次进入Gartner视野，被选入《2020年中国ICT技术成熟度曲线报告》，于2020年、2021连续评为 CaaS 容器云代表性厂商（ Sample Vendor ）；）此次能够在Gartner报告中同时获得三项重要认可，无疑是对公司三大核心产品线（博云容器云产品族、云管理平台、牧繁DevOps平台）技术创新能力和市场影响力的极大认可，是对博云科技在业内的领先地位的重要肯定。
博客
代码示范【FabEdge v0.8.0】配置 connector 公开端口
05-30 865
FabEdge是博云在2021年8月发起，基于Kubernetes 构建的专注于边缘计算场景的容器网络方案，支持 KubeEdge 、SuperEdge、OpenYurt 等主流边缘计算框架。旨在解决边缘计算场景下容器网络配置管理复杂、网络割裂互不通信、缺少拓扑感知能力、无法提供就近访问等问题，适用于物联网，车联网、智慧城市、智慧园区等多种边缘场景。
博客
双案入选！博云助力金融信创，百尺竿头，更进一步！
03-27 213
博云金融信创云平台可为企业提供可信赖的云环境、全面应用管控、完备安全防护，为客户实现主流信创芯片、操作系统的广泛适配，满足企业对信创安全可控的要求，满足客户从开发层面、运维层面、管理层面等多维度的业务需求及信创安全要求。
博客
大规模异构物理机如何管理？BeyondHMP了解下
02-07 253
随着数据大爆炸和应用服务的多样性，企业业务的快速发展，IT设备的规模越来越大，伴着云计算、大数据、云原生等技术的迭代更新，企业IT技术架构、技术路线、运营规模随之发生了较大变化，同时国家对企业技术自主可控能力提升要求，各大企业对技术路线也提出重大战略转变，大多企业提出以开源自主可控并依托云计算、大数据等技术向科技型、数据型公司的转型。，可提供裸机自动化安装、资源纳管、资源监控、维保管理、设备下线功能等功能，解决大规模异构物理机管理难题，助力企业构建构建一套高效的服务器运维解决方案。
博客
三步走！高效建设企业级容器云平台
02-07 573
近十年，企业 IT 架构经历了从集中式架构，到SOA、微服务架构，再到云原生架构的技术演变，容器、微服务、DevOps等云原生核心技术不断演进，让云计算变得更简单、更高效、更标准，这都让企业更加聚焦业务创新，企业生产效率与创新效率得到爆发式增长。基于此，作为最早进入容器技术领域之一的专业服务商，博云基于自身对容器底层技术的深度理解，十年容器云产品打磨，以及丰富的企业客户容器云落地实践经验，给出了自己的理解、思考和总结，然而，对于还在云原生转型初期阶段的企业来说，如何建设容器云平台依然是个难题。
博客
博云荣获证券基金信创联盟年度优秀成员
01-18 743
1月12日，证券基金行业信息技术应用创新联盟（以下简称“联盟”）2022年度峰会在上海顺利举行。会上，联盟为2022年积极参与联盟工作的成员单位进行了颁奖，博云获评信创联盟年度优秀成员奖。联盟是在中国证券监督管理委员会科技监管局、上海市经济和信息化委员会、上海证券交易所理事会科技发展委员会指导下，于 2021 年 5 月由上海证券交易所发起设立，旨在促进证券基金行业信息技术应用创新关键技术研究和应用，服务于成员单位的需求，攻关共性问题，降低自主创新技术产品的应用门槛，为加快相关工作的整体进程发挥积极作用。作
博客
雄关漫道真如铁，而今迈步从头越 | 挥别2022，再战2023！
01-12 671
2022年5月23日，在“容耀新生，大器所成”2022博云容器云产品族发布会上，围绕“以应用中心，为应用赋能”的理念，博云正式发布全新博云容器云产品族，实现了从单一容器云平台到涵盖5大子产品的容器云产品族的全新升级。2022年4月，博云 BeyondCMP 云管理平台迎来了 5.6 版本的重磅升级，针对不同行业客户对云管理平台的多样化需求，在资源纳管、资源运维、平台综合展示、易用性友好性等方面进行了全面提升。目前，从底层芯片、服务器、操作系统、中间件、数据库等层面，实现了全面国产化兼容适配。
博客
为有状态应用而生，云原生本地存储Carina正式进入CNCF沙箱
12-30 603
12月14日，云原生本地存储开源项目 Carina 通过了全球顶级开源基金会 CNCF 技术监督委员会（TOC）的评定，正式成为 CNCF 沙箱级项目（Sandbox Projects）。Carina是由博云于2021年10月主导发起的云原生本地存储开源项目，旨在为云原生环境中的有状态应用提供高性能、免运维的本地存储解决方案，具有存储卷生命周期管理、本地设备管理、智能调度等能力。Carina 是有状态应用而生的本地存储方案，已在多个金融机构的生产环境中稳定运行多年。Sandbox 是 CNCF 创建的旨在为
博客
kubernetes 1.26发布，这十项新特性值得关注！
12-12 780
在等待了三个月之后，kubernetes 1.26 如期发布，这个版本引入了很多新功能，让我们通过这篇文章一睹为快。推荐读者将自己的测试集群升级到 1.26 体验这些新功能，因为这是一个十分值得尝试的版本！V1.26总计带来了37项增强功能。在这37项增强功能中，有11项功能成为稳定版，有10项是对现有功能的改进，有多达16项功能是全新的，有1项功能被废弃。
博客
精彩回顾 | 云原生系统软件的产业应用
11-30 376
我们通过反思微服务来看，会发现微服务的优势并不是所有的业务都需要，单体应用也会长期存在，架构上单体、微服务、虚拟化应用与云原生体系应用会长期并存，因此在实际落地中，我们需要考虑敏态与稳态长期并存可能会带来的影响，以及我们需要考虑如何将这两者做好融合，实际上，云原生一个核心的价值恰恰是提升应用的稳定性。据 Gartner 调研显示，到2025年跑在云原生技术平台上的应用将占到新开发应用的95%，据 IDC 调研显示，到2024年新增的生产级云原生应用在新增应用的占比将从2020年的10%增加到60%。
博客
精彩回顾 | 苏州农商银行新一代云原生信息科技架构体系实践
11-29 1224
在互联网时代的全新业务模式下，传统的金融IT架构已经难以满足“互联网+普惠金融”的业务发展需要，必须开展跨界融合，以互联网行业擅长的“高弹性、高性能和低成本“和传统金融行业对于”高可用、高标准、低风险”相融合，以尽量低的成本保障业务快速增长的无限潜力。在创新方面，我行也在不断进行金融创新，引流互联网+场景，从服务理念、服务模式、服务对象、科技诉求等方面共同创新，为社会大众、小微企业提供高效、便捷、普惠的金融服务与价值。因此，在金融科技人才短缺、业务变革较快的情况下，这就对银行的科技支撑提出了更高的要求。
博客
K8S 故障排错新手段：kubectl debug 实战
10-19 1198
因此，我们只要启动一个进程，并且让这个进程加入到目标容器的各种 namespace 中，这个进程就能 “进入容器内部”（注意引号），与容器中的进程 “看到” 相同的根文件系统、虚拟网卡、进程空间了 —— 这也正是 docker exec 和 kubectl exec 等命令的运行方式。这种精简主义有很多好处，而且在大多数情况下运行良好，但是一旦需要在生产中排除一些故障时，这就变得很困难了，因为精简后的容器普遍缺失常用的排障工具，有些甚至连 bash/sh 解释器都没有。
博客
聚焦六大典型应用场景，博云金融行业容器解决方案更新发布！
10-14 971
通过建设容器云平台，实现开发、测试、生产环境一致性，提升敏捷开发的能力，提升自动化运维的水平。容器云作为 PaaS 平台的基础，可以实现资源的集中管理、动态分配、监控、共享和调度，实现应用的统一部署和业务连续性保障，实现多数据中心的高可用，推动应用架构及流程的演进。针对上述情况，用户可以采用。四方面，打造了金融行业容器云解决方案，可提供安全稳定的企业级容器引擎，提供支撑多应用场景的一致性云原生体验，提供面向云原生架构的自运维能力，提供端到端的容器安全解决方案，以及全方位信创兼容和提供金融级容灾方案。
博客
想要优化 K8S 集群管理？Cluster API 帮你忙 | K8S Internals 系列第 5 期
09-27 545
我们以（bootstrap-provider）以及（Infrastructure Provider）组件，资源版本 v1beta1 为例，梳理一下 Cluster API 的自定义资源关系图。在 Cluster API 中对于工作集群的控制平面节点和工作节点的控制是独立分开的，由此对应的资源关系又可划分为控制平面节点机器关系和工作节点机器关系。控制平面节点机器关系图对于，工作集群控制平面节点由资源控制。该资源直接控制了一组Machine资源，每一个Machine资源又分别关联了一个和资源。
博客
云原生数字化转型与金融信创建设，鱼和熊掌可兼得
09-22 1087
信创建设的核心是技术创新，云原生架构可以帮助金融 IT 基础设施建设实现新技术替换老技术，新架构替换老架构，实现支撑业务应用实现在全信创环境的运行，是博云信创云解决方案的核心。为主题进行了分享，从博云自身深耕云计算领域的实践经验，论及对数字化的理解、自身云原生体系层面、三大云原生案例等方面，分享了博云在信创产品和技术上的成果。未来，博云将继续发挥自身在云原生领域的能力优势，持续深入信创创新发展，协同产业合作伙伴，共同繁荣信创生态建设，助力我国数字经济自立自强的高质量发展。华为、宝德、中科可控、曙光、长城；
博客
直播回顾｜容器如何提升应用的稳定性？
09-09 344
随着数字化转型的深入，越来越多业务由线下转向线上，衍生出丰富的业务场景。这些场景驱动着软件系统进行敏态转型，同时也对实际承载业务的底层 IT 资源提出了新的要求，如何保证：既“快”又“稳”，成为整个敏态业务转型面临的新挑战。今天主要和大家聊一聊，容器在当下数字化转型日益深入的背景下，是如何保证应用的稳定性的，分享内容主要包含容器特点、应用容器化后的关注点、稳定性保障机制等方面。本文是 9 月 1 日“CloudTech 博云说”第七期分享内容《容器如何提升应用的稳定性？》的回顾整理。扫描上方或。
博客
博云 Kubernetes 开源榜单贡献度进入全球前十
09-07 607
博云通过以上开源关键贡献和开源项目，坚持向开源生态贡献创新技术力量，将自身多年来在云原生领域积累的丰富经验，与广大用户和开发者共同分享，保持与世界前沿 IT 技术的共振，在促进云原生技术不断进步的同时，致力于为用户提供更加优秀的使用体验。Kubernetes 作为引领云原生技术和云原生生态发展的“舵手”，正在成为云原生的操作系统。今年，博云容器云产品全面升级为容器云产品族，正是定位于以应用为中心，以容器为底座，面向多种应用类型支撑的云原生操作系统。基于此，实现博云容器云产品族的能力全景图。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值