第三节 认识kubernetes

一、kubernetes的发展历史

1、容器编排的历史

虽然Docker已经很强大了，但是在实际使用上还是有诸多不便，比如集群管理、资源调度、文件管理等等。

那么在这样一个百花齐放的容器时代涌现出了很多解决方案，比如Mesos.Swarm，Kubernetes等等，其中谷歌推动开源的 kubernetes 为最为强大的存在。

登录后复制

建于Docker之上的Kubernetes可以构建一个容器的调度服务，其目的是让用户透过Kubernetes集群来进行云端容器集群的管理，而无需用户进行
复杂的设置工作，系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。

其核心概念是Container Pod。一个Pod由一组工作于同一物理工作节点的容器构成。
这些组容器拥有相同的网络命名空间、IP以及存储配额，也可以根据实际情况对每一个Pod进行端口映射。
此外，Kubernetes工作节点会由主系统进行管理，节点包含了能够运行Docker容器所用到的服务。


我们可以看到多种服务方式
阿里云=> Infrastructure as a service
新浪云=> Platform as a service 
Office365 => Software as a service 

Apache推出的Mesos已经有7年之久。Docker Swarm虽然是比Kubernetes更年轻，但是它的背后是来自于Docker官方容器中心的全方位支持。
但是，因为是谷歌开源出来的，并且拥有十多年的容器化的经验，所以还是有很多人在使用。

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.

2、云原生的对比

Apache Mesos

Apache Mesos是一个分布式系统内核的开源集群管理器，Apache Mesos的出现要远早于Docker Swarm和Kubernetes。再加上Marathon这个基于容器的应用程序的编排框架，它为Docker Swarm和Kubernetes提供了一个有效的替代方案。Mesos 同时可以使用其他框架来同时支持容器化和非容器化的工作负载。

Mesos能够在同样的集群机器上运行多种分布式系统类型，可以更加动态高效的共享资源。而且Messos也提供服务失败检查，服务发布，服务跟踪，服务监控，资源管理和资源共享。

Messos可以扩展伸缩到数千个节点。如果你拥有很多的服务器而且想构建一个大的集群的时候，Mesos就派上用场了。很多的现代化可扩展性的数据处理应用都可以在Mesos上运行，包括大数据框架Hadoop、Kafka、Spark。但是大而全，往往就是对应的复杂和困难，这一点体现在Messos上是完全正确，与Docker和Docker Swarm使用同一种API不同的，Mesos和Marathon都有自己的API，这使得它们比其他编排系统更加的复杂。Apache Mesos是混合环境的完美编配工具，由于它包含容器和非容器的应用，虽然Messos很稳定，但是它的使用户快速学习应用变得更加困难，这也是在应用和部署场景下难于推广的原因之一。

Docker Swarm  

Docker Swarm是Docker公司的容器编排系统，使用的是标准Docker API接口，容器使用命令和docker命令是一套，简单方便。Docker Swarm基本架构简单直接，每个主机运行一个Docker Swarm代理，一个主机运行一个Docker Swarm管理者，这个管理者负责指挥和调度这些主机上的容器，Docker Swarm以高可用性模式运行，Docker Swarm中的一个节点充当其他节点的管理器，包括调度程序和服务发现组件的容器。Docker Swarm的优点和缺点都是使用标准的Docker接口，因为使用简单，容易集成到现有系统，所以在支持复杂的调度系统时候就会比较困难了，特别是在定制的接口中实现的调度。这也许就是成也 Docker，败也 Docker 的原因所在。

Kubernetes  

Kubernetes作为一个容器集群管理系统，用于管理云平台中多个主机上的容器应用，Kubernetes的目标是让部署容器化的应用变得简单且高效，所以Kubernetes提供了应用部署，规划，更新维护的一整套完整的机制。

Kubernetes没有固定要求容器的格式，但是Kubernetes使用它自己的API和命令行接口来进行容器编排。

除了Docker容器之外，Kubernetes还支持其他多种容器，如rkt、Coreos等。

Kubernetes是自成体系的管理工具，可以实现容器调度，资源管理，服务发现，健康检查，自动伸缩，更新升级等，也可以在应用模版配置中指定副本数量，服务要求(IO优先；性能优先等)，资源使用区间，标签(Labels等)来匹配特定要求达到预期状态等，这些特征便足以征服开发者，再加上Kubernetes有一个非常活跃的社区，它为用户提供了更多的选择以方便用户扩展编排容器来满足他们的需求。

但是由于Kubernetes使用了自己的API接口，所以命令系统是另外一套系统，这也是kubernetes门槛比较高的原因所在。

大部分的应用程序我们在部署的时候都会适当的添加监控，对于运行载体容器则更应该如此。

kubernetes提供了liveness probes来检查我们的应用程序，它是由节点上的kubelet定期执行的。

3、Kubernetes的发展

      Kubernetes是希腊语「舵手』的意思，它最开始由Google的几位软件工程师创立，深受公司内部Borg和Omega项目的影响，很多设计都是从Borg中借鉴的，同时也对Borg的缺陷进行了改进，Kubernetes目前是CNCF的项目并且是很多公司管理分布式系统的解决方案。其中比较有意思的一点是，Kubernetes的简写称为k8s，即该单词k和s中间刚好是8个字母组成，所以是一种单词的简写形式。

                      kuberntes的官方文档： https://kubernetes.io/docs/reference/

                      kubernetes的github： https://github.com/kubernetes/kubernetes

                         kubernetes的中文文档： https://kubernetes.io/zh-cn/docs/home/

        十年前的 2014 年 6 月 6 日，Kubernetes 的第一次提交被推送到 GitHub。 第一次提交包含了 250 个文件和 47,501 行的 Go、Bash 和 Markdown 代码， 开启了我们今天所拥有的项目。谁能预测到 10 年后，Kubernetes 会成长为迄今为止最大的开源项目之一， 拥有来自超过 8,000 家公司、来自 44 个国家的 88,000 名贡献者。

二、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。kube-proxy 实质就是通过操作防火墙规则(iptables或者ipvs)来实现 Pod 的映射。它负责将访问到某个服务的请求具体分配给工作节点上同一类标签的 Pod。

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

三、Kubernetes组件详解

1、核心组件

apiserver：所有服务访问的唯一入口，提供认证、授权、访问控制、API注册和发现等机制。

controller manager：负责维护集群的状态，比如副本期望数量、故障检测、自动扩展、滚动更新等。

scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。

etcd：键值对数据库，保存了整个集群的状态。

kubelet：负责维护容器的生命周期，同时也负责volume和网络的管理。

kube-proxy：负责为Service提供cluster 内部的服务发现和负载均衡。

Container runtime：负责镜像管理以及Pod 和容器的真正运行。

2、推荐的插件

CoreDNS：可以为集群中的SVc创建一个域名IP的对应关系解析的DNS服务。

Dashboard：给 K8s 集群提供了一个 B/S 架构的访问入口。

Ingress Controller：官方只能够实现四层的网络代理，而Ingress可以实现七层的代理。

Prometheus：给 K8s 集群提供资源监控的能力。

Federation：提供一个可以跨集群中心多 K8s 的统一管理功能，提供跨可用区的集群。

四、补充说明

1、ISO七层通信

2、k8s网络插件

①网络插件Calico

Calico 是一个开源的容器网络和网络安全解决方案，它广泛应用于 Kubernetes 集群和其他容器编排平台。Calico 的主要特点包括：

1. 高性能：Calico 利用 BGP 协议在主机之间路由数据包，避免了数据包封装和额外的流量打包，因此具有很高的转发效率。
2. 灵活性和全面性：Calico 不仅提供主机和 Pod 之间的网络连接，还涉及网络安全和管理。它支持高级网络策略，允许用户配置规则来控制 Pod 应如何发送和接收流量，提高安全性并控制网络环境。
3. 集成性：Calico 可以与服务网格 Istio 集成，实现集群内工作负载的策略解释和实施，增强了网络安全性。
4. 纯三层网络：Calico 使用虚拟路由代替虚拟交换，通过 BGP 协议传播路由信息，避免了与二层方案相关的数据包封装操作。
5. 易于部署：尽管 Calico 创建的网络环境具有简单和复杂的属性，但其部署过程相对简单，支持多种安装方式，包括在线和离线安装。
6. 兼容性：Calico 与多种 IaaS 平台和容器平台有良好的集成，例如 OpenStack、AWS、GCE 等。 【总结】 Calico 的安装通常涉及下载安装文件和必要的容器镜像，然后将其部署到 Kubernetes 集群中。对于 Kubernetes 1.24 及以上版本，Calico 的离线安装需要适应新的容器运行时环境，例如 containerd。Calico 还提供了 CRD(Custom Resource Definitions)来管理网络策略和 IP 地址分配等资源。总的来说，Calico 是一个功能丰富、性能优异的网络插件，适用于需要高级网络策略和安全控制的 Kubernetes 集群。

②网络插件flannel

Flannel 是一个流行的容器网络接口(CNI)插件，用于 Kubernetes 集群，它提供了一种轻量级且易于部署的网络解决方案。Flannel 通过虚拟网络覆盖技术(overlay network)来连接不同节点上的容器，允许容器之间进行通信。以下是关于 Flannel 的一些关键信息：

1. 开发与维护：Flannel 由 CoreOS 开发，是一个成熟的项目，被广泛认为是 Kubernetes 容器编排系统中最直接的网络结构之一 。
2. 安装与配置：Flannel 相对容易安装和配置，通常作为 Kubernetes 集群部署的一部分默认安装 。
3. 依赖性：Flannel 可以使用 Kubernetes 集群的现有 etcd 集群来存储其状态信息，因此不需要专用的数据存储 。
4. 网络模型：Flannel 配置第 3 层 IPv4 overlay 网络，每个节点都有一个子网，用于在内部分配 IP 地址 。
5. 通信机制：同一主机中的 Pod 可以使用 Docker 桥接进行通信，而不同主机上的 Pod 会使用 flanneld 将其流量封装在 UDP 数据包中，以便路由到适当的目标 。
6. 后端类型：Flannel 支持多种后端，包括 VXLAN(默认和推荐的方法)、UDP 和 Host-GW 等 。
7. 适用场景：Flannel 提供了一个简单的网络模型，适合大多数基本的 Kubernetes 网络需求，特别是对于初期使用是一个稳妥安全的选择 。
8. 性能考量：虽然 Flannel 的性能通常是足够的，但在特定场景下可能会因为 overlay 网络的额外封装导致一些性能损失 。
9. 可靠性：Flannel 的可靠性取决于底层网络和 etcd 的稳定性。如果 etcd 出现问题，可能会影响 Flannel 的功能 。
10. 网络策略：Flannel 默认情况下，所有容器之间都是互通的，但可以使用 Kubernetes 的网络策略功能来实现更精细的访问控制 。 【总结】 Flannel 是 Kubernetes 网络插件中的一个常见选项，以其简单性和易用性而受到用户的青睐。然而，对于需要更高性能和更复杂网络策略的场景，可能需要考虑其他解决方案，如 Calico 或 Cilium 等 。

③网络插件kube-ovn

Kube-OVN 是一个基于 Open vSwitch (OVS) 构建的 Kubernetes 网络插件，它提供了丰富的网络功能和高性能的网络解决方案。以下是关于 Kube-OVN 的一些关键信息：

1. 基本概念：Kube-OVN 通过集成 OVS 与 Kubernetes，简化了虚拟网络的创建和管理。它支持 Kubernetes 的网络策略、服务发现和负载均衡等功能，并能与其他网络插件如 Flannel 无缝集成。
2. 安装：安装 Kube-OVN 需要确保 Kubernetes 集群已安装并正常运行。安装命令可以通过 kubectl apply 执行，例如使用 kubectl apply -f https://github.com/ovn-org/kube-ovn/releases/download/v1.12.0/install.yaml 来安装 Kube-OVN。
3. 功能特性：

• 支持 Namespace 和子网的绑定以及子网间访问控制。
• 支持静态 IP 分配和动态 QoS 调整。
• 支持分布式和集中式网关，以及内嵌的 LoadBalancer。
• 提供了 kubectl 插件工具，方便日常运维操作，如查看 OVN 数据库信息、备份和恢复、OVS 相关信息查看等。

4. 架构：Kube-OVN 使用 OVN 的北向接口创建和调整虚拟网络，将网络概念映射到 Kubernetes 内。所有相关组件都打包成镜像，在 Kubernetes 中运行。
5. IPAM 能力：从 v1.1 版本开始，Kube-OVN 可以为其他 CNI 网络插件提供集群级别的 IPAM 能力，支持子网以及固定 IP 功能。
6. 网络策略和隔离：Kube-OVN 支持基于子网的 IP 隔离，用户可以轻松实施基本的网络隔离策略。
7. 社区和开发：Kube-OVN 已经在 GitHub 上开源，社区活跃，致力于实现网络功能的增强和优化，如集中式网关的高可用性、内嵌 DNS 支持等。 【总结】 Kube-OVN 作为一个成熟的网络插件，因其强大的功能和易用性，在 Kubernetes 社区中受到欢迎。

④网络插件cilium

Cilium 是一种高性能的 Kubernetes 网络插件，它利用 eBPF(扩展的 Berkeley Packet Filter)技术来实现容器间的快速通信和网络策略的实施。以下是关于 Cilium 的一些关键点：

1. 工作原理：Cilium 通过 eBPF 技术实现对容器网络流量的监控和转发，同时提供丰富的网络策略和安全功能。
2. 特点：

• 高性能：避免了传统网络方案中的性能瓶颈。
• 安全性：提供 IPSec 加密、TLS 加密、访问控制列表等网络安全功能。
• 灵活性：支持 overlay 和直连模式等多种网络模式。
• 可扩展性：提供丰富的 API 和插件机制，方便扩展功能和集成其他工具。

3. 安装与集成：Cilium 需要与 Kubernetes 集群进行集成，包括安装、配置网络策略、部署应用以及监控与调试。
4. 实际应用：Cilium 允许通过定义网络策略来控制 Pod 之间的网络流量，并集成了 Hubble 进行网络流量的监控和分析。
5. 实践经验：在部署 Cilium 之前，确保 Kubernetes 集群环境满足 Cilium 的要求，特别是 Linux 内核版本。 【总结】 Cilium 作为一种高性能的 Kubernetes 网络和安全解决方案，为 Kubernetes 管理员提供了一个理想的选择，帮助他们实现快速的容器间通信和细粒度的网络安全控制。