您的位置：首页 > 数码常识数码常识
k8s从入门到放弃（k8s很难学吗）
2025-05-10人已围观
k8s从入门到放弃（k8s很难学吗）
为什么要学习 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，发现还是起不来，报错如下：
解决方法：
检查日志发现并没有特别明显的错误，根据经验来讲，etcd 节点坏掉一个其实对集群没有大的影响，这时集群已经可以正常使用了，但是这个坏掉的 etcd 节点并没有启动，解决方法如下：
进入 etcd 的数据存储目录进行备份 备份原有数据：
删除这个目录下的所有数据文件
停止另外两台 etcd 节点，因为 etcd 节点启动时需要所有节点一起启动，启动成功后即可使用。
CentOS下配置主机互信
在每台服务器需要建立主机互信的用户名执行以下命令生成公钥/密钥，默认回车即可
可以看到生成个公钥的文件。
互传公钥，第一次需要输入密码，之后就OK了。
-p 端口 默认端口不加-p，如果更改过端口，就得加上-p. 可以看到是在.ssh/下生成了个 authorized_keys的文件，记录了能登陆这台服务器的其他服务器的公钥。
测试看是否能登陆：
CentOS 主机名的修改
Virtualbox 实现 CentOS 复制和粘贴功能
如果不安装或者不输出，可以将 update 修改成 install 再运行。
运行完后
删除Pod一直处于Terminating状态
可以通过下面命令强制删除
删除namespace一直处于Terminating状态
可以通过以下脚本强制删除
这个容器创建出来会有什么问题呢？
其实对于正常的环境来说没有什么问题，但是对于资源型 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。
第一类
第二类
第三类
第四类
第五类
上面就是小居数码小编今天给大家介绍的关于（k8s很难学吗）的全部内容，希望可以帮助到你，想了解更多关于数码知识的问题，欢迎关注我们，并收藏，转发，分享。
94%的朋友还想知道的：
excel入门基础和怎样制作表格（excel入门基础知识）
AutoCAD2008入门级纯净安装教程（autocad2008安装步骤）
零基础怎么学好cad制图（cad制图零基础入门教程）
excel表格入门基础教程（excel新手入门教程）
156457
为什么要学习 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，发现还是起不来，报错如下：
解决方法：
检查日志发现并没有特别明显的错误，根据经验来讲，etcd 节点坏掉一个其实对集群没有大的影响，这时集群已经可以正常使用了，但是这个坏掉的 etcd 节点并没有启动，解决方法如下：
进入 etcd 的数据存储目录进行备份 备份原有数据：
删除这个目录下的所有数据文件
停止另外两台 etcd 节点，因为 etcd 节点启动时需要所有节点一起启动，启动成功后即可使用。
CentOS下配置主机互信
在每台服务器需要建立主机互信的用户名执行以下命令生成公钥/密钥，默认回车即可
可以看到生成个公钥的文件。
互传公钥，第一次需要输入密码，之后就OK了。
-p 端口 默认端口不加-p，如果更改过端口，就得加上-p. 可以看到是在.ssh/下生成了个 authorized_keys的文件，记录了能登陆这台服务器的其他服务器的公钥。
测试看是否能登陆：
CentOS 主机名的修改
Virtualbox 实现 CentOS 复制和粘贴功能
如果不安装或者不输出，可以将 update 修改成 install 再运行。
运行完后
删除Pod一直处于Terminating状态
可以通过下面命令强制删除
删除namespace一直处于Terminating状态
可以通过以下脚本强制删除
这个容器创建出来会有什么问题呢？
其实对于正常的环境来说没有什么问题，但是对于资源型 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。
第一类
第二类
第三类
第四类
第五类
上面就是小居数码小编今天给大家介绍的关于（k8s很难学吗）的全部内容，希望可以帮助到你，想了解更多关于数码知识的问题，欢迎关注我们，并收藏，转发，分享。
94%的朋友还想知道的：
excel入门基础和怎样制作表格（excel入门基础知识）
AutoCAD2008入门级纯净安装教程（autocad2008安装步骤）
零基础怎么学好cad制图（cad制图零基础入门教程）
excel表格入门基础教程（excel新手入门教程）
156457
很赞哦！ ()
下一篇：返回列表