欢迎来到小居数码网-一家分享数码知识,生活小常识的网站,希望可以帮助到您。

当前位置:生活小常识 > 数码知识 >
优质

k8s从入门到放弃(k8s很难学吗)

数码知识

周泽改优秀作者

原创内容 来源:小居数码网 时间:2024-08-17 15:15:01 阅读() 收藏:51 分享:64

导读:您正在阅读的是关于【数码知识】的问题,本文由科普作家协会,生活小能手,著名生活达人等整理监督编写。本文有5832个文字,大小约为23KB,预计阅读时间15分钟。

为什么要学习 Kubernetes?虽然 Docker 已经很强大了,但是在实际使用上还是有诸多不便,比如集群管理、资源调度、文件管理等等。在这样一个百花齐放的容器时代涌现出了很多解决方案,比如 Mesos、Swarm、Kubernetes 等等,其中谷歌开源的 Kubernetes 是作为老大哥的存在。也可参考:k8s 和 Docker 关系简单说明

k8s很难学吗

为什么要学习 Kubernetes?

kubernetes 已经成为容器编排领域的王者,它是基于容器的集群编排引擎,具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。

kubernetes 介绍

Kubernetes 解决的核心问题

  • 服务发现和负载均衡
  • Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。
  • 存储编排
  • Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。
  • 自动部署和回滚
  • 您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。
  • 自动二进制打包
  • Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。
  • 自我修复
  • Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。
  • 密钥与配置管理
  • Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。
  • Kubernetes 的出现不仅主宰了容器编排的市场,更改变了过去的运维方式,不仅将开发与运维之间边界变得更加模糊,而且让 DevOps 这一角色变得更加清晰,每一个软件工程师都可以通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且能够快速实现水平扩容、蓝绿部署等在过去复杂的运维操作。

    Kubernetes 知识图谱

    主要介绍学习一些什么知识

    Kubernetes 软件架构

    传统的客户端服务端架构

  • 架构说明
  • Kubernetes 遵循非常传统的客户端/服务端的架构模式,客户端可以通过 RESTful 接口或者直接使用 kubectl 与 Kubernetes 集群进行通信,这两者在实际上并没有太多的区别,后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供出来。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成,其中 Master 节点主要负责存储集群的状态并为 Kubernetes 对象分配和调度资源。

  • 主节点服务 - Master 架构
  • 作为管理集群状态的 Master 节点,它主要负责接收客户端的请求,安排容器的执行并且运行控制循环,将集群的状态向目标状态进行迁移。Master 节点内部由下面三个组件构成:

    API Server: 负责处理来自用户的请求,其主要作用就是对外提供 RESTful 的接口,包括用于查看集群状态的读请求以及改变集群状态的写请求,也是唯一一个与 etcd 集群通信的组件。

    etcd: 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。

    Scheduler: 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

    controller-manager: 在主节点上运行控制器的组件,从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。这些控制器包括:节点控制器(负责在节点出现故障时进行通知和响应)、副本控制器(负责为系统中的每个副本控制器对象维护正确数量的 Pod)、端点控制器(填充端点 Endpoints 对象,即加入 Service 与 Pod))、服务帐户和令牌控制器(为新的命名空间创建默认帐户和 API 访问令牌)。

  • 工作节点 - Node 架构
  • 其他的 Worker 节点实现就相对比较简单了,它主要由 kubelet 和 kube-proxy 两部分组成。

    kubelet: 是工作节点执行操作的 agent,负责具体的容器生命周期管理,根据从数据库中获取的信息来管理容器,并上报 pod 运行状态等。

    kube-proxy: 是一个简单的网络访问代理,同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上同一类标签的 Pod。kube-proxy 实质就是通过操作防火墙规则(iptables或者ipvs)来实现 Pod 的映射。

    Container Runtime: 容器运行环境是负责运行容器的软件,Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI(容器运行环境接口)。

    Kubernetes 组件说明

    主要介绍关于 K8s 的一些基本概念

    主要由以下几个核心组件组成:

  • apiserver
  • 所有服务访问的唯一入口,提供认证、授权、访问控制、API 注册和发现等机制
  • controller manager
  • 负责维护集群的状态,比如副本期望数量、故障检测、自动扩展、滚动更新等
  • scheduler
  • 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上
  • etcd
  • 键值对数据库,保存了整个集群的状态
  • kubelet
  • 负责维护容器的生命周期,同时也负责 Volume 和网络的管理
  • kube-proxy
  • 负责为 Service 提供 cluster 内部的服务发现和负载均衡
  • Container runtime
  • 负责镜像管理以及 Pod 和容器的真正运行
  • 除了核心组件,还有一些推荐的插件:

  • CoreDNS
  • 可以为集群中的 SVC 创建一个域名 IP 的对应关系解析的 DNS 服务
  • Dashboard
  • 给 K8s 集群提供了一个 B/S 架构的访问入口
  • Ingress Controller
  • 官方只能够实现四层的网络代理,而 Ingress 可以实现七层的代理
  • Prometheus
  • 给 K8s 集群提供资源监控的能力
  • Federation
  • 提供一个可以跨集群中心多 K8s 的统一管理功能,提供跨可用区的集群
  • 以上内容参考链接: https:// 重新将时间调整正确,重新启动 etcd,发现还是起不来,报错如下:

    Mar 05 14:27:15 k8s-node2 etcd[3248]: etcd Version: 3.3.13Mar 05 14:27:15 k8s-node2 etcd[3248]: Git SHA: 98d3084Mar 05 14:27:15 k8s-node2 etcd[3248]: Go Version: go1.10.8Mar 05 14:27:15 k8s-node2 etcd[3248]: Go OS/Arch: linux/amd64Mar 05 14:27:15 k8s-node2 etcd[3248]: setting maximum number of CPUs to 4, total number of available CPUs is 4Mar 05 14:27:15 k8s-node2 etcd[3248]: the server is already initialized as member before, starting as etcd member...Mar 05 14:27:15 k8s-node2 etcd[3248]: peerTLS: cert = /opt/etcd/ssl/server.pem, key = /opt/etcd/ssl/server-key.pem, ca = , trusted-ca = /opt/etcd/ssl/ca.pem, client-cert-auth = false, crl-file =Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for peers on https://192.168.25.226:2380Mar 05 14:27:15 k8s-node2 etcd[3248]: The scheme of client url http://127.0.0.1:2379 is HTTP while peer key/certfiles are presented. Ignored key/cert files.Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 127.0.0.1:2379Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 192.168.25.226:2379Mar 05 14:27:15 k8s-node2 etcd[3248]: member 9c166b8b7cb6ecb8 has already been bootstrappedMar 05 14:27:15 k8s-node2 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILUREMar 05 14:27:15 k8s-node2 systemd[1]: Failed to start Etcd Server.Mar 05 14:27:15 k8s-node2 systemd[1]: Unit etcd.service entered failed state.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service holdoff time over, scheduling restart.Mar 05 14:27:15 k8s-node2 systemd[1]: Starting Etcd Server...Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_NAME, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_PEER_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_ADVERTISE_CLIENT_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER, but unused: shadowedby corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_TOKEN, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_STATE, but unused: shadowed by corresponding flag

    解决方法:

    检查日志发现并没有特别明显的错误,根据经验来讲,etcd 节点坏掉一个其实对集群没有大的影响,这时集群已经可以正常使用了,但是这个坏掉的 etcd 节点并没有启动,解决方法如下:

    进入 etcd 的数据存储目录进行备份 备份原有数据:

    cd /var/lib/etcd/default.etcd/member/cp *  /data/bak/

    删除这个目录下的所有数据文件

    rm -rf /var/lib/etcd/default.etcd/member/*

    停止另外两台 etcd 节点,因为 etcd 节点启动时需要所有节点一起启动,启动成功后即可使用。

    #master 节点systemctl stop etcdsystemctl restart etcd#node1 节点systemctl stop etcdsystemctl restart etcd#node2 节点systemctl stop etcdsystemctl restart etcd

    CentOS下配置主机互信

    在每台服务器需要建立主机互信的用户名执行以下命令生成公钥/密钥,默认回车即可

    ssh-keygen -t rsa

    可以看到生成个公钥的文件。

    互传公钥,第一次需要输入密码,之后就OK了。

    ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.199.132 (-p 2222)

    -p 端口 默认端口不加-p,如果更改过端口,就得加上-p. 可以看到是在.ssh/下生成了个 authorized_keys的文件,记录了能登陆这台服务器的其他服务器的公钥。

    测试看是否能登陆:

    ssh 192.168.199.132 (-p 2222)

    CentOS 主机名的修改

    hostnamectl set-hostname k8s-master1

    Virtualbox 实现 CentOS 复制和粘贴功能

    如果不安装或者不输出,可以将 update 修改成 install 再运行。

    yum install updateyum update kernelyum update kernel-develyum install kernel-headersyum install gccyum install gcc make

    运行完后

    sh VBoxLinuxAdditions.run

    删除Pod一直处于Terminating状态

    可以通过下面命令强制删除

    kubectl delete pod NAME --grace-period=0 --force

    删除namespace一直处于Terminating状态

    可以通过以下脚本强制删除

    [root@k8s-master1 k8s]# cat delete-ns.sh#!/bin/bashset -euseage(){    echo "useage:"    echo " delns.sh NAMESPACE"}if [ $# -lt 1 ];then    useage    exitfiNAMESPACE=$1JSONFILE=${NAMESPACE}.jsonkubectl get ns "${NAMESPACE}" -o json > "${JSONFILE}"vi "${JSONFILE}"curl -k -H "Content-Type: application/json" -X PUT -->容器包含有效的 CPU/内存 requests 且没有指定 limits 可能会出现什么问题?</h1><p>下面我们创建一个对应的容器,该容器只有 requests 设定,但是没有 limits 设定,</p><pre><code>- name: busybox-cnt02    image: busybox    command: ["/bin/sh"]    args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]    resources:      requests:        memory: "100Mi"        cpu: "100m"

    这个容器创建出来会有什么问题呢?

    其实对于正常的环境来说没有什么问题,但是对于资源型 pod 来说,如果有的容器没有设定 limit 限制,资源会被其他的 pod 抢占走,可能会造成容器应用失败的情况。可以通过 limitrange 策略来去匹配,让 pod 自动设定,前提是要提前配置好limitrange 规则。

    来源:https:///passzhang

    Kubernetes 上对应用程序进行故障排除的 6 个技巧 推荐给大家,日常排错必备。分享一份阿里云内部超全K8s实战手册,免费下载!

    Kubernetes 面试题

    一个目标:容器操作;两地三中心;四层服务发现;五种 Pod 共享资源;六个 CNI 常用插件;七层负载均衡;八种隔离维度;九个网络模型原则;十类 IP 地址;百级产品线;千级物理机;万级容器;相如无亿,k8s 有亿:亿级日服务人次。

    一个目标:容器操作

    Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署、调度和节点集群间扩展。

    具体功能:

  • 自动化容器部署和复制。
  • 实时弹性收缩容器规模。
  • 容器编排成组,并提供容器间的负载均衡。
  • 调度:容器在哪个机器上运行。
  • 组成:

  • kubectl:客户端命令行工具,作为整个系统的操作入口。
  • kube-apiserver:以 REST API 服务形式提供接口,作为整个系统的控制入口。
  • kube-controller-manager:执行整个系统的后台任务,包括节点状态状况、Pod 个数、Pods 和Service 的关联等。
  • kube-scheduler:负责节点资源管理,接收来自 kube-apiserver 创建 Pods 任务,并分配到某个节点。
  • etcd:负责节点间的服务发现和配置共享。
  • kube-proxy:运行在每个计算节点上,负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。
  • kubelet:运行在每个计算节点上,作为 agent,接收分配该节点的 Pods 任务及管理容器,周期性获取容器状态,反馈给 kube-apiserver。
  • DNS:一个可选的 DNS 服务,用于为每个 Service 对象创建 DNS 记录,这样所有的 Pod 就可以通过 DNS 访问服务了。
  • 下面是 k8s 的架构拓扑图:

    两地三中心

    两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。

    两地三中心要解决的一个重要问题就是数据一致性问题。

    k8s 使用 etcd 组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。

    它作为一个受到 Zookeeper 和 doozer 启发而催生的项目。除了拥有他们的所有功能之外,还拥有以下 4 个特点:

  • 简单:基于 HTTP+JSON 的 API 让你用 curl 命令就可以轻松使用。
  • 安全:可选 SSL 客户认证机制。
  • 快速:每个实例每秒支持一千次写操作。
  • 可信:使用 Raft 算法充分实现了分布式。
  • 四层服务发现

    先一张图解释一下网络七层协议:

    k8s 提供了两种方式进行服务发现:

  • 环境变量:当创建一个 Pod 的时候,kubelet 会在该 Pod 中注入集群内所有 Service 的相关环境变量。需要注意的是,要想一个 Pod 中注入某个 Service 的环境变量,则必须 Service 要先比该 Pod 创建。这一点,几乎使得这种方式进行服务发现不可用。比如,一个 ServiceName 为 redis-master 的 Service,对应的 ClusterIP:Port 为 10.0.0.11:6379,则对应的环境变量为:
  • DNS:可以通过 cluster add-on 的方式轻松的创建 KubeDNS 来对集群内的 Service 进行服务发现。
  • 以上两种方式,一个是基于 TCP,DNS 基于 UDP,它们都是建立在四层协议之上。

    五种 Pod 共享资源

    Pod 是 k8s 最基本的操作单元,包含一个或多个紧密相关的容器。

    一个 Pod 可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个 Pod 中的多个容器应用通常是紧密耦合的,Pod 在 Node 上被创建、启动或者销毁;每个 Pod 里运行着一个特殊的被称之为 Volume 挂载卷,因此他们之间通信和数据交换更为高效。在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中。

    同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。

    一个 Pod 中的应用容器共享五种资源:

  • PID 命名空间:Pod 中的不同应用程序可以看到其他应用程序的进程 ID。
  • 网络命名空间:Pod 中的多个容器能够访问同一个IP和端口范围。
  • IPC 命名空间:Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
  • UTS 命名空间:Pod 中的多个容器共享一个主机名。
  • Volumes(共享存储卷):Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes。
  • Pod 的生命周期通过 Replication Controller 来管理;通过模板进行定义,然后分配到一个 Node 上运行,在 Pod 所包含容器运行结束后,Pod 结束。

    Kubernetes 为 Pod 设计了一套独特的网络配置,包括为每个 Pod 分配一个IP地址,使用 Pod 名作为容器间通信的主机名等。

    六个 CNI 常用插件

    CNI(Container Network Interface)容器网络接口是 Linux 容器网络配置的一组标准和库,用户需要根据这些标准和库来开发自己的容器网络插件。CNI 只专注解决容器网络连接和容器销毁时的资源释放,提供一套框架。所以 CNI 可以支持大量不同的网络模式,并且容易实现。

    下面用一张图表示六个 CNI 常用插件:

    七层负载均衡

    提负载均衡就不得不先提服务器之间的通信。

    IDC(Internet Data Center)也可称数据中心、机房,用来放置服务器。IDC 网络是服务器间通信的桥梁。

    上图里画了很多网络设备,它们都是干啥用的呢?

    路由器、交换机、MGW/NAT 都是网络设备,按照性能、内外网划分不同的角色。

  • 内网接入交换机:也称为 TOR(top of rack),是服务器接入网络的设备。每台内网接入交换机下联 40-48 台服务器,使用一个掩码为 /24 的网段作为服务器内网网段。
  • 内网核心交换机:负责 IDC 内各内网接入交换机的流量转发及跨 IDC 流量转发。
  • MGW/NAT:MGW 即 LVS 用来做负载均衡,NAT 用于内网设备访问外网时做地址转换。
  • 外网核心路由器:通过静态互联运营商或 BGP 互联美团统一外网平台。
  • 先说说各层负载均衡:

  • 二层负载均衡:基于 MAC 地址的二层负载均衡。
  • 三层负载均衡:基于 IP 地址的负载均衡。
  • 四层负载均衡:基于 IP+端口 的负载均衡。
  • 七层负载均衡:基于 URL 等应用层信息的负载均衡。
  • 这里用一张图来说说四层和七层负载均衡的区别:

    上面四层服务发现讲的主要是 k8s 原生的 kube-proxy 方式。k8s 关于服务的暴露主要是通过 NodePort 方式,通过绑定 minion 主机的某个端口,然后进行 Pod 的请求转发和负载均衡,但这种方式有下面的缺陷:

  • Service 可能有很多个,如果每个都绑定一个 Node 主机端口的话,主机需要开放外围的端口进行服务调用,管理混乱。
  • 无法应用很多公司要求的防火墙规则。
  • 理想的方式是通过一个外部的负载均衡器,绑定固定的端口,比如 80;然后根据域名或者服务名向后面的 Service IP 转发。

    Nginx 很好的解决了这个需求,但问题是如果有的新的服务加入,如何去修改并且加载这些 Nginx 配置?

    Kubernetes 给出的方案就是 Ingress。这是一个基于七层的方案。

    八种隔离维度

    k8s 集群调度这边需要对上面从上到下、从粗粒度到细粒度的隔离做相应的调度策略。

    九个网络模型原则

    k8s 网络模型要符合四个基础原则、三个网络要求原则、一个架构原则、一个 IP 原则。

    每个 Pod 都拥有一个独立的 IP 地址,而且假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中,不管是否运行在同一 Node 上都可以通过 Pod 的 IP 来访问。

    k8s 中的 Pod 的 IP 是最小粒度 IP。同一个 Pod 内所有的容器共享一个网络堆栈,该模型称为 IP-per-Pod 模型。

  • Pod 由 docker0 实际分配的 IP。
  • Pod 内部看到的 IP 地址和端口与外部保持一致。
  • 同一个 Pod 内的不同容器共享网络,可以通过localhost来访问对方的端口,类似同一个虚拟机内不同的进程。
  • IP-per-Pod 模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看,Pod 可以看做是一台独立的虚拟机或物理机。

  • 所有容器都可以不用 NAT 的方式同别的容器通信。
  • 所有节点都可以在不同 NAT 方式下同所有容器通信,反之亦然。
  • 容器的地址和别人看到的地址是同一个地址。
  • 要符合下面的架构:

    由上图架构引申出来 IP 概念从集群外部到集群内部:

    十类IP地址

    大家都知道 IP 地址分为 ABCDE 类,另外还有五类特殊用途的 IP。

    第一类

    A 类:1.0.0.0-1226.255.255.255,默认子网掩码/8,即255.0.0.0。B 类:128.0.0.0-191.255.255.255,默认子网掩码/16,即255.255.0.0。C 类:192.0.0.0-223.255.255.255,默认子网掩码/24,即255.255.255.0。D 类:224.0.0.0-239.255.255.255,一般用于组播。E 类:240.0.0.0-255.255.255.255(其中255.255.255.255为全网广播地址)。E 类地址一般用于研究用途。

    第二类

    0.0.0.0严格来说,0.0.0.0 已经不是一个真正意义上的 IP 地址了。它表示的是这样一个集合:所有不清楚的主机和目的网络。这里的不清楚是指在本机的路由表里没有特定条目指明如何到达。作为缺省路由。127.0.0.1 本机地址。

    第三类

    224.0.0.1 组播地址。如果你的主机开启了IRDP(internet路由发现,使用组播功能),那么你的主机路由表中应该有这样一条路由。

    第四类

    169.254.x.x使用了 DHCP 功能自动获取了 IP 的主机,DHCP 服务器发生故障,或响应时间太长而超出了一个系统规定的时间,系统会为你分配这样一个 IP,代表网络不能正常运行。

    第五类

    10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 私有地址。大量用于企业内部。保留这样的地址是为了避免亦或是哪个接入公网时引起地址混乱。

    上面就是小居数码小编今天给大家介绍的关于(k8s很难学吗)的全部内容,希望可以帮助到你,想了解更多关于数码知识的问题,欢迎关注我们,并收藏,转发,分享。

    94%的朋友还想知道的:

    (374)个朋友认为回复得到帮助。

    部分文章信息来源于以及网友投稿,转载请说明出处。

    本文标题:k8s从入门到放弃(k8s很难学吗):http://sjzlt.cn/shuma/156457.html

    猜你喜欢