精华内容
下载资源
问答
  • k8s概述及申威k8s生态构建.pptx
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...

    「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/container )。

    1

       

    Docker v19.03.11 发布

    距离 v19.03.10 发布仅一周时间,Docker 又发布了新版本 v19.03.11 。此版本是一个安全修复版本,通过禁用了 IPv6 路由地址广播(RA)从而防止地址欺骗,对应的漏洞为 CVE-2020-13401 ( https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13401 ) 。

    在 Docker 的默认配置中,容器网络接口是指向主机(veth 接口)的虚拟以太网链接,在此配置下,如果一个攻击者可以在容器中以 root 身份运行进程的话,那么他是可以使用 CAP_NET_RAW 能力,向主机任意发送和接收数据包的。

    例如:在容器内使用 root 用户,可以正常执行 ping 命令

    (MoeLove) ➜  ~ docker run --rm -it -u root redis:alpine sh
    /data # whoami
    root
    /data # ping -c 1 moelove.info
    PING moelove.info (185.199.108.153): 56 data bytes
    64 bytes from 185.199.108.153: seq=0 ttl=49 time=54.389 ms
    
    
    --- moelove.info ping statistics ---
    1 packets transmitted, 1 packets received, 0% packet loss
    round-trip min/avg/max = 54.389/54.389/54.389 ms
    

    在容器内使用非 root 用户,执行 ping 命令会提示无权限

    (MoeLove) ➜  ~ docker run --rm -it -u redis redis:alpine sh
    /data # whoami
    redis
    /data $ ping -c 1 moelove.info
    PING moelove.info (185.199.109.153): 56 data bytes
    ping: permission denied (are you root?)
    

    如果没有在主机上完全禁用 IPv6 (通过内核参数 ipv6.disable=1), 那么主机上的网络接口可以自己进行配置。如果配置项为 /proc/sys/net/ipv6/conf/*/forwarding == 0 那表示该接口禁用了 IPv6 转发。全局的静态配置可以在以下位置看到:

    (MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/forwarding
    1
    

    另外,还有一个默认配置是关于是否接收 RA 消息的,如果配置项为 /proc/sys/net/ipv6/conf/*/accept_ra == 1,则表示该接口默认接收 RA 消息。全局的静态配置可以在以下位置看到:

    (MoeLove) ➜  ~ cat /proc/sys/net/ipv6/conf/all/accept_ra 
    1
    

    上述的两个系统默认配置的组合,表示系统接受路由广播(RA)消息,并且使用它配置 IPv6 网络栈(SLAAC)。如果熟悉 IETF RFC 4861 的小伙伴应该知道,ICMPv6 RA 虽然本意是好的,但它确实存在安全风险。

    在尚未使用 IPv6 的网络中,双栈主机处于休眠状态,并等待最终的 RA 消息来唤醒其 IPv6 连接。攻击者可以制作恶意的 RA 消息,获取网络中的双协议节点以配置其 IPv6 地址,并利用攻击者的系统作为其默认的网关。这样便可很简单的实施中间人攻击了。在 RFC 6104 中其实早就记录过这个问题,也有很多相关的解决方案,此处就不展开了,涉及的东西太多了。

    对应到此次漏洞中,如果攻击者通过容器发送恶意 RA 消息(rogue RA),则可以重新配置主机,将主机的部分或者全部 IPv6 通信都重定向到攻击者控制的容器。

    即使之前没有 IPv6 流量,如果 DNS 服务器返回 A(IPv4)和 AAAA(IPv6)记录的话,很多 HTTP 库将会首先尝试进行 IPv6 连接,然后再回退到 IPv4 。这就为攻击者提供了制造响应的机会。

    如果主机恰好有类似去年 apt 的 CVE-2019-3462 ( https://nvd.nist.gov/vuln/detail/CVE-2019-3462 ) 这种漏洞的话,则攻击者便可能获取主机权限。

    总体而言,Docker 容器默认没有配置 CAP_NET_ADMIN 能力,所以攻击者无法直接将其配置为中间人攻击的 IP,无法使用 iptables 进行 NAT 或者 REDIRECT 流量,也不能使用 IP_TRANSPARENT。但是攻击者仍然可以使用 CAP_NET_RAW 能力,并在用户空间实现 TCP/IP 堆栈。

    聊完 Docker 相关的这个漏洞,这里就顺便展开聊聊相关的一些其他问题吧。

    与此漏洞类似的,受影响的还有 Kubernetes , 但并不是 Kubernetes 自身的漏洞,而是官方安装源仓库中,kubelet 依赖的 kubernetes-cni CNI 包,也存在漏洞 CVE-2020-10749 ( https://nvd.nist.gov/vuln/detail/CVE-2020-10749 )

    受影响版本为:

    • kubelet v1.18.0-v1.18.3

    • kubelet v1.17.0-v1.17.6

    • kubelet v1.16.11 之前版本

    第三方组件相关的漏洞信息:

    • Calico 和 Calico Enterprise (CVE-2020-13597) 漏洞信息 TTA-2020-001 可在此处 https://www.projectcalico.org/security-bulletins/ ( https://www.projectcalico.org/security-bulletins/ ) 查看;

    • CNI Plugins v0.8.6 之前版本 (CVE-2020-10749),详情见 https://github.com/containernetworking/plugins/pull/484 ( https://github.com/containernetworking/plugins/pull/484 );

    • Flannel 全部版本;

    • Weave Net v2.6.3 之前版本;

    以下第三方组件目前未受此次漏洞影响:

    • Cilium

    • Juniper Contrail Networking

    • OpenShift SDN

    • OVN-Kubernetes

    • Tungsten Fabric

    结合前面我对此漏洞的说明,想必你也看到了,解决此漏洞最简单的方法是:

    • 更新相关组件到最新(包含修复内容)的版本(截至目前,相关受影响组件中,除 Flannel 外,均已发布新版本来解决此漏洞);

    • 可以在系统中禁止接收 RA 消息(如果你不需要 RA 消息的话);

    • 也可以禁用容器的 CAP_NET_RAW 能力,例如:

    (MoeLove) ➜  ~ docker run --cap-drop CAP_NET_RAW --rm -it -u root redis:alpine sh
    /data # ping -c 1 moelove.info
    PING moelove.info (185.199.108.153): 56 data bytes
    ping: permission denied (are you root?)
    

    2

       

    Docker Compose v1.26.0 发布

    Docker Compose 是一个很方便灵活的工具,大家应该不会陌生。前段时间 Docker 将 Compose 规范开源后,社区在逐步成长中。

    本次发布的 v1.26.0 中,包含了很多值得注意的内容:

    • 添加了对 doker context 的支持,context 非常好用!Docker Inc. 在今年的 Docker Con 之前还和 Azure 达成了合作,加速从本地到云的开发/部署等,具体操作上也都是通过 context 实现的;

    • 支持通过 COMPOSE_COMPATIBILITY 环境变量配置其能力;

    对此版本感兴趣的朋友请参考其 ReleaseNote ( https://docs.docker.com/compose/release-notes/#1260 )

    3

       

    Kube-OVN v1.2 发布

    Kube-OVN 是首次出现在「K8S 生态周报」中的项目,稍微做下介绍。它是一款基于 OVN 的 Kubernetes 网络组件,通过将 OpenStack 领域成熟的网络功能平移到 Kubernetes,来应对更加复杂的基础环境和应用合规性要求。

    Kube-OVN 主要具备五大主要功能:Namespace 和子网的绑定,以及子网间访问控制,静态 IP 分配,动态 QoS,分布式和集中式网关,内嵌 LoadBalancer。

    本次发布的 v1.2 中包含了以下重要更新:

    • 开始支持 OVS-DPDK 以便于支持高性能 dpdk 应用;

    • 支持使用 BGP 将 Pod IP 路由宣告到外部网络;

    • 在创建后,支持修改子网 CIDR (我个人觉得这个功能特别有用,网络规划也有动态调整的实际需求);

    • 当子网网关修改后,路由可以自动更改;

    对此版本感兴趣的朋友请参考其 RelaseNote ( https://github.com/alauda/kube-ovn/releases/tag/v1.2.0 )

    4

       

    上游进展

    本周 Kubernetes v1.19.0-beta1 已经发布!

    • #91113 ( https://github.com/kubernetes/kubernetes/pull/91113 ) 和 #91481 ( https://github.com/kubernetes/kubernetes/pull/91481 ) 在 kubectl create deployment 时,增加了 --port 的选项;

    另一个值得开心的变更来自 etcd :

    • #11946 ( https://github.com/etcd-io/etcd/pull/11946 ) 为 etcd 添加了一个 --unsafe-no-fsync 的选项,可以禁止文件同步。这对于本地开发/CI 测试都是非常好的!


    欢迎订阅我的文章公众号【MoeLove】

    展开全文
  • 欢迎订阅知乎专栏「k8s生态」。 ”Helm v2 将正式废弃本周,Helm v2 系列发布了 v2.16.10 版本, 这是 Helm v2 的最后一个 bugfix 版本,此后不会再为 Helm v2 提供错误修复。并且在三个月后,将停止为 Helm v2 提供...

    371bce005678dec887515426d941fb09.png
    “ 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。

    Helm v2 将正式废弃

    本周,Helm v2 系列发布了 v2.16.10 版本, 这是 Helm v2 的最后一个 bugfix 版本,此后不会再为 Helm v2 提供错误修复。并且在三个月后,将停止为 Helm v2 提供安全补丁。届时, Helm v2 也就完全废弃,不会再去维护了。

    如果有在使用 Helm v2 的小伙伴,请尽快升级至 Helm v3, 社区也提供了 Helm 2to3[1] 的工具,可以帮助迁移。

    另外,还有个别厂商绑定 Helm v2 提供应用安装/部署服务的,也建议尽快迁移了。

    我统计了下,我发布的文章中,有 25 篇与 Helm 相关。包括 Helm v3 的尝试,Helm v2 的废弃计划,从 Helm v2 迁移到 v3 等内容,感兴趣的小伙伴可以看看历史文章。

    DockerHub 修改了定价和 TOS

    DockerHub 本周对其服务收费以及 TOS(Terms of Service)[2]。我们重点来看看本次的修改对我们会有哪些影响吧。

    这里重点来看看对免费用户/(未登录)匿名用户的影响。

    • 流量限制
      未登录用户每 6 小时,允许 Pull 100 次; 已登录用户每 6 小时,允许 Pull 200 次;
    • 镜像保留策略变更
      非活跃镜像,保留周期为 6 个月。在清理之前,会发送通知告知会进行清理等操作。其中, 非活跃镜像 指的是无 push 或 pull 操作等。

    这个影响有多大呢?首先是流量限制方面,如果你维护着一个包含 20 个 Node 的 Kubernetes 集群,并假设它们的公网出口一致。那你 6 个小时内,平均每个 Node 上只能从 DockerHub 拉取 5 次镜像。

    在镜像保留策略这里,如果你曾经构建过一个镜像,但没什么人用,且很久未更新,那就极有可能被清理掉了。你可以通过 DockerHub 页面上镜像的更新时间来查看下镜像的情况。当然,Docker 团队也宣称会在 DockerHub 上提供一个 Dashboard ,方便查看当前镜像的健康程度。

    这个镜像保留策略的生效时间,是从今年的 11 月 1 日开始实施,届时大家最好关注下自己的镜像。

    最后,说一下 Docker 为何要增加这个“镜像保留策略” 的条款,那是因为当前 DockerHub 保留的镜像数据超过了 15PB,但其中有 4.5PB 左右属于无效镜像,通过此次新的策略,应该可以为 DockerHub 节约不少的(S3)存储支出。

    Rook v1.4.1 发布

    Rook 也迎来了其 v1.4 系列版本,此次版本中有一些非常值得关注的内容:

    • 不再支持来自 Ceph-CSI 驱动的 Alpha 快照,只支持 Beta 快照了;
      • 此版本中默认部署了 Ceph-CSI 3.0[3];
      • 包括多架构的 Docker 镜像支持;
      • 可以为 RBD 创建或删除 Beta 快照,同时移除 Alpha 快照的支持;
      • 可以从 RBD 快照创建 PVC ;
      • 可以为 RDB 和 CephFS 支持 ROX 卷;
    • 如果 dashboard 模块开启,则将会为 ceph 对象存储开启 dashboard;
    • 实验性的增加了一个 admission controller ,可进行 CRD 校验,但是默认是不开启的;
    • CephObjectStore CRD 将其健康状态展示在 Status 字段中了;
    • OSD 可以通过在 storageClassDeviceSet 设置 encrypted: true 进行加密了;

    上游进展

    • #93929[4] 对 Ingress TLS 的 secretName 增加了校验。当创建了一个 networking.k8s.io/v1 的 Ingress 对象,会校验 spec.tls[*].secretName 字段;
    • Kubernetes v1.19 计划于 8 月 25 日发布,届时默认 Go 版本为 v1.15;

    欢迎订阅我的文章公众号【MoeLove】

    参考资料

    [1]

    helm 2to3: https://github.com/helm/helm-2to3

    [2]

    Docker TOS: https://www.docker.com/legal/docker-terms-service

    [3]

    ceph-csi 3.0: https://github.com/ceph/ceph-csi/releases/tag/v3.0.0

    [4]

    #93929: https://github.com/kubernetes/kubernetes/pull/93929

    展开全文
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Kubernetes v1.16.15 发布Kubern...

    「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]

    Kubernetes v1.16.15 发布

    Kubernetes v1.16.15 是 v1.16 系列的最后一个更新,我在之前的周报中也有介绍过。

    是时候考虑将 v1.16 升级至更高版本了!

    以下介绍从 v1.16 升级至 v1.17 需要关注的一些重点。

    etcd

    就外部依赖而言,最主要的变化是 etcd 从 v3.3.13 升级到了 v3.4.3

    在升级 etcd 前,我建议你先阅读下 etcd 的升级文档[2]。我从中说几个重点内容:

    In the general case, upgrading from etcd 3.3 to 3.4 can be a zero-downtime, rolling upgrade:

    • one by one, stop the etcd v3.3 processes and replace them with etcd v3.4 processes

    • after running all v3.4 processes, new features in v3.4 are available to the cluster

    这是 etcd 文档中的内容,看起来是很安全的。

    但也有一些非常关键的信息值得注意, 主要是破坏性变更:

    • ETCDCTL_API=3 etcdctl 成为默认;

    • etcd --enable-v2=false 默认关掉了 v2 支持;

    • etcd --ca-fileetcd --peer-ca-file 已过期;

    整体而言涉及到的内容就是 etcd v2 API 了。

    假如你使用的 CNI 是 Flannel 的话,你需要注意 Flannel 目前还不支持使用 etcd v3 API[3] , 需要自行设置 --enable-v2

    kube-apiserver

    默认的 service IP CIDR 10.0.0.0/24 已经过期,并将在之后版本删除,所以需要注意给 kube-apiserver 设置 --service-cluster-ip-range 选项,以免在之后升级时发生问题。

    kubelet & CSI

    如果你的某个节点使用了 CSI raw block volume ,那么在升级 kubelet 前, 必须 kubectl drain node-x 以避免遇到问题[4]

    最值得关注的问题主要就这些,祝你升级顺利 :)

    Rook v1.4.2 发布

    Rook 本次发布的 v1.4.2 版本,主要集中在对 Ceph 相关内容的改进。我们来看看有哪些值得关注的内容吧:

    • #6118 为 OSD prepare 做了资源限制;

    • #6170 为所有对象存储的 debug 信息增加了完整的 DNS 后缀,比如(.svc.cluster.local);

    更多关于此版本的变更请参考其 ReleaseNote

    Cilium v1.8.3 发布

    关于 Cilium 的介绍可参考我的上一篇文章 Cilium 上手实践 ,这里就不再赘述了。

    本周 Cilium 发布了 v1.8.3 版本,我们来看看有哪些值得注意的变更吧:

    • 为 Cilium operator 增加了 HA 模式[5] , 但是要注意的是 HA 模式由于使用了 coordination.k8s.io/v1 API 所以不支持 Kubernetes v1.14 之前版本的 K8S ;

    • Hubble/relay: 在 ServerStatus 会报告 Node 连接状态了;

    更多关于此版本的变更,请参考其 ReleaseNote[6]

    上游进展

    • #93548 kubectl path 增加了一个 --patch-file 的选项,允许使用 patch 文件;

    • #94309 kubectl get ingress 默认将使用 networking.k8s.io/v1 API 而不是之前的 extensions/v1beta1


    欢迎订阅我的文章公众号【MoeLove】

    TheMoeLove

    参考资料

    [1]

    k8s生态: https://zhuanlan.zhihu.com/container

    [2]

    etcd 升级文档: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_4.md

    [3]

    Flannel 不支持 etcd v3 API: https://github.com/coreos/flannel/issues/1191

    [4]

    kubelet & CSI v1.17: https://github.com/kubernetes/kubernetes/pull/74026

    [5]

    Cilium operator HA mode: https://github.com/cilium/cilium/pull/12409

    [6]

    Cilium v1.8.3 ReleaseNote: https://github.com/cilium/cilium/releases/tag/v1.8.3

    展开全文
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Docker v20.10.6 发布距离上个版本已经过去了...

    「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]

    Docker v20.10.6 发布

    距离上个版本已经过去了一个多月,Docker 于近日发布了 v20.10.6 版本,还有 Docker Desktop 也发布了新版。这个版本中除了带来了 M1 的支持外,还带来了很多值得关注的内容,我们一起来看看吧!

    CLI 和构建器

    在 Docker v1.7 版本之前,Docker CLI 在执行完 docker login 后,会将相关信息存储到本地的 ~/.dockercfg 配置文件中。自从 v1.7 版本开始,Docker 引入了新的配置文件 ~/.docker/config.json,为了保持兼容性,Docker 一直在同时支持这两种配置文件。

    从当前版本开始,如果发现还在用 ~/.dockercfg 则会输出一行警告信息。提醒用户该配置文件将在后续版本中删除,请使用新的配置文件路径&格式。

    此外,从这个版本开始,如果在使用旧版的 builder 并且在 Dockerfile 中有其不支持的命令或参数,则会打印相关报错,并提示使用 BuildKit 来完成构建。这也是 Docker 社区想要将 BuildKit 提升为默认构建器的进一步举措。

    日志

    #42174 · moby/moby修正了 Docker v20.10 版本中,当使用默认的 json-file 日志驱动时,偶发会遇到 io.UnexpectedEOF 的错误。

    在实际测试中,在大量日志持续输出的情况下,比较容易复现此问题。

    网络

    此版本中修正了 v20.10 中,当容器停止后 iptables 规则无法自动清理的问题;同时也解决了 Docker 在有 IPv6 网络机器上,暴露端口时,虽然可以同时通过 IPv4 和 IPv6 的地址访问该端口,但是 docker inspect 的 API 中默认不返回 IPv6 地址信息的问题。

    其他

    在这个版本中,如果使用 Docker 官方源进行 Docker CE 安装的话,默认会建议安装 docker-scan-plugin 包,这是一个 docker CLI 的插件,可用于扫描镜像漏洞。

    该插件我在之前的 K8S 生态周报中已经介绍过了,最初先引入到了 Docker Desktop 中,这个插件还是很方便的。

    另外, 这个版本也解决了一个比较严重的问题 。虽然此问题并非 Docker 自身导致的,但是在使用 Docker In Docker 模式时,会触发到,所以在此进行额外的说明。

    当在 Kubernetes 中使用 Docker In Docker v20.10 版本时候,由于 Kubernetes 有 QoS 的机制,它确定了 Pod 的调度和驱逐优先级。实际上,Kubelet 是通过判断 Pod 的 oom_score_adj 来判定何时对它进行 OOM 。关于容器资源管理的部分,请参考我之前的文章《聊聊容器资源管理》

    如果是 BestEffort QoS 的 Pod,则 Kubernetes 会将它的 oom_score_adj 设置为 1000 ,但是 containerd 为了能避免 shim 不至于在子进程之前推出,所以在 AdjustOOMScore 函数中,进行了对 oom_score_adj 加 1 的行为。会导致如下报错信息:

    docker: Error response from daemon: io.containerd.runc.v2: failed to adjust OOM score for shim: set shim OOM score: write /proc/211/oom_score_adj: invalid argument
    

    前面也已经说到了 Besteffort QoS 为它设置的是 1000, 这已经是该值的最大值啦,要 +1 自然也就报错了。

    对应的修正方法如下:

    diff --git a/sys/oom_unix.go b/sys/oom_unix.go
    index d49d5bc8d..c381e1a7e 100644
    --- a/sys/oom_unix.go
    +++ b/sys/oom_unix.go
    @@ -26,8 +26,12 @@ import (
            "strings"
     )
    
    -// OOMScoreMaxKillable is the maximum score keeping the process killable by the oom killer
    -const OOMScoreMaxKillable = -999
    +const (
    +       // OOMScoreMaxKillable is the maximum score keeping the process killable by the oom killer
    +       OOMScoreMaxKillable = -999
    +       // OOMScoreAdjMax is from OOM_SCORE_ADJ_MAX https://github.com/torvalds/linux/blob/master/include/uapi/linux/oom.h
    +       OOMScoreAdjMax = 1000
    +)
    
    diff --git a/runtime/v2/shim/util_unix.go b/runtime/v2/shim/util_unix.go
    index 2b0d0ada3..9fb7cc573 100644
    --- a/runtime/v2/shim/util_unix.go
    +++ b/runtime/v2/shim/util_unix.go
    @@ -53,6 +53,7 @@ func SetScore(pid int) error {
    
     // AdjustOOMScore sets the OOM score for the process to the parents OOM score +1
     // to ensure that they parent has a lower* score than the shim
    +// if not already at the maximum OOM Score
     func AdjustOOMScore(pid int) error {
            parent := os.Getppid()
            score, err := sys.GetOOMScoreAdj(parent)
    @@ -60,6 +61,9 @@ func AdjustOOMScore(pid int) error {
                    return errors.Wrap(err, "get parent OOM score")
            }
            shimScore := score + 1
    +       if shimScore > sys.OOMScoreAdjMax {
    +               shimScore = sys.OOMScoreAdjMax
    +       }
            if err := sys.SetOOMScore(pid, shimScore); err != nil {
                    return errors.Wrap(err, "set shim OOM score")
            }
    

    可以看到,就是在 AdjustOOMScore 中,如果发现发现调整后的 oom_score_adj 大于了系统默认的最大值,则将它设置为系统的最大值。

    如果在生产环境中使用 containerd 及 Docker In Docker 的,建议升级到此版本进行解决。

    好了,以上就是此版本中需要注意的内容,更多详细的变更,请查看其 ReleaseNote

    kube-state-metrics v2.0 发布

    做 Kubernetes 集群监控的小伙伴,大多对这个项目都不陌生。kube-state-metrics 可以根据 Kubernetes 的资源状态来生成 Prometheus 格式,极大的满足了我们对集群可观测性的要求。

    这个版本主要是将一些 metrics 的名字做了替换,替换成了更加标准和统一的格式。

    同时,将镜像的位置从 Quay.io 迁移到了 k8s.gcr.io/kube-state-metrics/kube-state-metrics 中。

    更多关于此版本的变更,请查看其 ReleaseNote

    上游进展

    • #99839 · kubernetes/kubernetes 修正了 port-forward 的内存泄漏问题;

    • #99963 · kubernetes/kubernetes 确保 job controller 可以在 Pod 完成后清理掉它;

    • #100644 · kubernetes/kubernetes 将 KubeConfig 暴露在 scheduler framework 中,以便于树外插件使用。


    欢迎订阅我的文章公众号【MoeLove】

    TheMoeLove

    参考资料

    [1]

    k8s生态: https://zhuanlan.zhihu.com/container

    展开全文
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。Helm v3.3.4 发布本周 Helm v3.3.4 发...
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。Helm v3.4 正式发布Helm v3.4 是一个特性更...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Istio v1.7.1 发布这是 Istio v1.7...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Kubernetes v1.19 正式发布本周 Kube...
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。Helm 五周岁啦!Helm 于 2015 年,在 Deis...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Trivy v0.17 正式发布Trivy 是一款由 Aq...
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。Docker V2 GitHub Action 已 GADo...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”Docker v20.10 主要特性一览在之前的 K8S...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”KIND v0.11.0 正式发布KIND (Kubern...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”runc v1.0 正式发布从 2016 年 6 月发布 ...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。”Helm v2 将正式废弃本周,Helm v2 系列发布了 v...
  • K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/con...
  • “「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。”KIND v0.9 正式发布KIND 是我很喜欢也一直在...
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。Cilium v1.9.0 正式发布Cilium 本周发布了...
  • 「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。”Istio 1.6.7 发布Istio 1.6.7 是为了解决...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,093
精华内容 3,637
关键字:

K8S生态