Kubernetes

隧道技术概要 隧道技术（Tunneling）是网络基础设置在网络之间传递数据的方式，使用隧道技术传递可以是不同协议的数据包，隧道协议将这些其他协议的数据包重新封装在新的包头中发送。被封装的数据包在隧道的两个端点之间通过网络进行路由，被封装数据包在网络上传递时所经历的逻辑路径称为隧道。 简单来说，隧道技术是一类网络协议，是将一个数据包封装在另一个数据包中进行传输的技术；**使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。**通过网络隧道技术，可以使隧道两端的网络组成一个更大的内部网络。（把不支持的协议数据包打包成支持的协议数据包之后进行传输）。 隧道协议 要创建隧道，隧道的客户机和服务器双方必须使用相同的隧道技术，隧道协议有二层隧道协议与三层隧道协议两类。 二层隧道协议对应OSI模型中数据链路层，使用 帧 作为数据交换单位，PPTP、L2TP、L2F都属于二层隧道协议。是将数据封装在点对点协议的帧中通过互联网络发送。 三层隧道协议对应OSI模型中网络层，使用 包 作为数据交换单位，GRE、IPSec 都属于三层隧道协议。都是数据包封装在附加的IP包头中通过IP网络传送。 在例如VxLAN，工作在传输层和网络层之间。具体来说，将运行在用户数据报协议 (UDP) 和网络数据报协议 (IP) 之间，以便在网络中建立安全的通信通道。 网络隧道技术应用 隧道在Linux 中应用 IP隧道是指一种可在两网络间进行通信的通道。在该通道里，会先封装其他网络协议的数据包，之后再传输信息。 Linux原生共支持5种IPIP隧道： ipip: 普通的IPIP隧道，就是在报文的基础上再封装成一个IPv4报文 gre: 通用路由封装（Generic Routing Encapsulation），定义了在任意一种网络层协议上封装其他任意一种网络层协议的机制，所以对于IPv4和IPv6都适用 sit: sit模式主要用于IPv4报文封装IPv6报文，即IPv6 over IPv4 isatap: 站内自动隧道寻址协议（Intra-Site Automatic Tunnel Addressing Protocol），类似于sit也是用于IPv6的隧道封装 vti: 即虚拟隧道接口（Virtual Tunnel Interface），是一种IPsec隧道技术 像IPVS/LVS中的 Virtual Server via IP Tunneling，就是使用了IPIP隧道 SSH隧道技术 SSH提供了一个重要功能，称为转发 forwarding 或者称为隧道传输tunneling，它可以通过加密频道将明文流量导入隧道中，在创建SSH隧道时， SSH客户端要设置并转交一个特定本地端口号到远程机器上；一旦SSH隧道创建，用户可以连到指定的本地端口号以访问网络服务。本地端口号不用与远地端口号一样。 SSH隧道主要使用场景一般为 规避防火墙、加密网络流量 规避防火墙，SSH隧道可以使一个被防火墙阻挡的协议可被包在另一个没被防火墙阻挡的协议里，这技巧可用来逃避防火墙政策。而这种操作符合“数据包封装在另一个数据包中进行传输的技术”，故称为SSH隧道技术。 SSH隧道类型 在ssh连接的基础上，指定 ssh client 或 ssh server 的某个端口作为源地址，所有发至该端口的数据包都会透过ssh连接被转发出去；至于转发的目标地址，目标地址既可以指定，也可以不指定，如果指定了目标地址，称为定向转发，如果不指定目标地址则称为动态转发： 定向转发 定向转发把数据包转发到指定的目标地址。目标地址不限定是ssh client 或 ssh server，既可以是二者之一，也可以是二者以外的其他机器。...

什么是 Helm Helm 是一个用于管理 Kubernetes 应用程序的包管理工具。它允许您定义、安装和升级 Kubernetes 应用程序，以简化应用程序部署和管理的过程。 在 Kubernetes 中，应用程序被打包为一个或多个称为 “Charts” 的 Helm 资源。一个 Chart 是一个预定义的目录结构，包含了用于部署应用程序的 Kubernetes 资源清单模板。Chart 可以包含 Deployment、Service、ConfigMap、Ingress 等 Kubernetes 资源的定义。 使用 Helm，您可以将应用程序打包为一个 Chart，并使用 Helm 客户端来安装和管理 Chart。这使得应用程序的部署过程更加简单、可重复和可扩展。您可以根据需要部署多个实例，轻松地进行升级和回滚操作，并使用 Helm 提供的值覆盖机制来自定义每个实例的配置。 最重要的是，Helm 支持使用 Helm 仓库来共享和发布 Charts。Helm 仓库是一个集中存储 Charts 的地方，供用户从中搜索和安装 Charts。Helm 仓库可以是公共的，也可以是私有的，您可以自己搭建私有仓库来管理自己的 Charts。 Helm 所作的事情 Helm 管理名为 chart 的Kubernetes包的工具。故 Helm 可以做以下的事情： 创建一个新的 chart 将 chart 打包成归档 (tgz) 文件 与存储 chart 的仓库进行交互 在现有的 Kubernetes 集群中安装和卸载 chart 管理与Helm一起安装的 chart 的发布周期 Helm中的术语 chart：类似于rpm包，deb包，包含Kubernetes资源所需要的必要信息。 repo：chart仓库，类似于yum的仓库，chart仓库是一个简单的HTTP服务。 values：提供了自定义信息用来覆盖模板中的默认值。 release ：chart安装后的版本记录。 Helm 与 YAML 资源清单比有什么优势？ 模板化和参数化: Helm 使用 Go 的模板引擎来创建 Kubernetes 资源清单。这使得您可以在 Chart 中使用模板来定义资源配置的部分内容，例如标签、名称、端口等。同时，Helm 还支持使用参数化的值，允许您根据不同的环境或需求来自定义 Chart 的配置。这样一来，您可以根据需要生成不同的 Kubernetes 资源清单，而无需手动编辑每个清单文件。 可重用性: Helm 提供了一种将应用程序打包为 Chart 的方式，可以将 Chart 存储在 Helm 仓库中进行共享和重用。这样，您可以使用其他人创建的 Charts 来快速部署常见的应用程序，避免从头开始编写和管理 Kubernetes 资源清单。同时，您也可以将自己的应用程序打包为 Chart，方便自己和团队在不同环境中部署和管理。 版本管理和升级: 使用 Helm，您可以对已安装的 Chart 进行版本管理和升级。当应用程序的配置或代码发生变化时，您可以通过升级 Chart 来自动应用这些更改，而无需手动修改和重新部署 Kubernetes 资源清单。Helm 还提供了回滚功能，允许您在升级出现问题时快速回退到之前的版本。 依赖管理: Helm 允许您在 Chart 中定义和管理依赖关系。这意味着您可以在部署应用程序时自动解析和安装它所依赖的其他 Charts。这样，您可以轻松地管理应用程序所需的其他资源，减少手动处理依赖关系的工作。 部署的一致性和标准化: Helm 提供了一种标准的部署方式，使得不同团队或开发者之间可以使用相同的工具和流程来管理应用程序的部署。这样可以确保在不同环境中的一致性，并降低由于不同部署方式导致的错误和配置差异。 可管理的 Charts: Helm Charts 是可管理的，您可以在 Chart 中定义预先配置的模板、默认值、钩子和配置验证。这使得管理应用程序的配置和部署过程更加灵活和可控。 社区支持和生态系统: Helm 是一个活跃的开源项目，拥有庞大的用户社区和丰富的生态系统。这意味着您可以轻松地找到文档、示例、教程和问题解答，并从社区中获取支持和贡献。 可扩展性和插件支持: Helm 提供了插件机制，允许您扩展 Helm 的功能。您可以使用插件来添加自定义的命令、功能和工作流程，以满足特定需求或自动化常见的任务。 可视化界面和用户友好性: Helm 可以与各种第三方工具和平台集成，提供可视化界面和用户友好的操作方式。这使得非技术人员或不熟悉命令行的开发人员也能够方便地部署和管理应用程序。 安装helm Helm 安装主要官方提供了几种安装方式...

Kubernetes Ingress Kubernetes Ingress是路由规则的集合，这些规则控制外部用户如何访问Kubernetes集群中运行的服务。 在Kubernetes中，有三种方式可以使内部Pod公开访问。 NodePort：使用Kubernetes Pod的NodePort，将Pod内应用程序公开到每个节点上的端口上。 Service LoadBalancer：使用Kubernetes Service，改功能会创建一个外部负载均衡器，使流量转向集群中的Kubernetes Pod。 Ingress Controller： Node Port是在Kubernetes集群中每个节点（Node）上开放端口，Kubernetes直接将流量转向集群中Pod。Kubernetes集群中使用NodePort，则需要编辑防火墙规则，但是NodePort是范围在Kubernetes集群中默认设置的范围为 30000–32767，最终导致流量端口暴露在非标准端口之上。 LoadBalancer一般应用于云厂商提供的Kubernetes服务，如果自行在机器上部署Kubernetes集群，则需要自行配置LoadBalancer的实现， Kubernetes Ingress，为Kubernetes中的抽象概念，实现为第三方代理实现，这种三方实现集合统称为Ingress Controller。Ingress Controller负责引入外部流量并将流量处理并转向对应的服务。 Kubernetes IngressController功能实现 上面只是说道，在Kubernetes集群中，如何将外部流量引入到Kubernetes集群服务中。 负载均衡 无论在Kubernetes集群中，无论采用什么方式进行流量引入，都需要在外部负载均衡完成，而后负载均衡将流量引入Kubernetes集群入口或内部中， 通常情况下，NodePort方式管理繁琐，一般不用于生产环境。 服务的Ingress选择 Kubernetes Ingress是选择正确的方法来管理引入外部流量到服务内部。一般选择也是具有多样性的。 Nginx Ingress Controller，Kubernetes默认推荐的Ingress，弊端①最终配置加载依赖config reload，②定制化开发较难，配置基本来源于config file。 Envoy & traefik api网关，支持tcp/udp/grpc/ws等多协议，支持流量控制，可观测性，多配置提供者。 云厂商提供的Ingress。AWS ALB，GCP GLBG/GCE，Azure AGIC Traefik介绍 traefik-现代反向代理，也可称为现代边缘路由；traefik原声兼容主流集群，Kubernetes，Docker，AWS等。官方的定位traefik是一个让开发人员将时间花费在系统研发与部署功能上，而非配置和维护。并且traefik官方也提供自己的服务网格解决方案 作为一个 modern edge router ，traefik拥有与envoy相似的特性 基于go语言研发，目的是为了简化开发人员的配置和维护 tcp/udp支持 http L7支持 GRPC支持 服务发现和动态配置 front/ edge prory支持 可观测性 流量管理 … traefik 术语 要了解trafik，首先需要先了解一下 有关trafik中的一些术语。 EntryPoints 入口点，是可以被下游客户端连接的命名网络位置，类似于envoy 的listener和nginx的listen services 服务，负载均衡，上游主机接收来自traefik的连接和请求并返回响应。 类似于nginx upstream envoy的clusters Providers 提供者，提供配置文件的后端，如file，kubernetes，consul，redis，etcd等，可使traefik自动更新 routers 路由器，承上启下，分析请求，将下游主机的请求处理转入到services middlewares: 中间件，在将下游主机的请求转入到services时进行的流量调整 在Kubernetes中使用traefik网关作为Ingress Traefik于2019年9月发布2....

Kubernetes集群的构成 Master Node (Control plane) Master 是整个 Kubernetes 集群构成的基础，它负责整个集群的管理，例如处理集群的状态；组件包含 API Server, Controller manager, Scheduller, Etcd API server API 服务器是 Master 的统一前端入口，负责集群内其他组件的 协调 与 通信。该组件用于定义集群的状态。可以通过命令行, HTTP API, 第三方托管平台（dashboard, Rancker, Kuboard等）与 Kubernetes API 进行交互。 Scheduler 调度程序 Scheduler 负责根据可用资源来决定如何去部署容器，部署到哪里？确保所有 Pod（容器组）都分配给某一组节点。 Controller Manager Controller manager，又分为Controller 和 Manager，Controller的组要作用是用于协调各种控制器(Deployment, Daemonset…)，这些控制器可确保在节点发生故障时采取适当的措施。而 Manager 则管理的众多Controller；更一般地说，CM 负责随时将集群的当前状态调整到所需状态（Kubernetes设计基石）。 etcd etcd 是控制平面内的一个组件，他提供了 Kubernetes 资源的存储，并为集群内组件提供了 Watch 的功能，这将意味着，etcd 在 kubernetes 集群中作为存储与分布式协调的功能。 Worker nodes 每个集群中至少需要存在一个工作节点，但是通常会有大量的节点；而工作节点包括的组件不限于 Kubelet, Kube-proxy, CNI Plugin。 Kubelet kubelet是工作节点中管理运行时的组件，负责整个Pod （容器组）进程的生命周期 Kube-proxy Kube-proxy 为整个集群内提供了 service 的功能，如果这个组件无法正常工作，那么整个集群内的网络通信将不能正常，因为 service 是作为集群内服务的访问入口，包含 Kubernetes API service。...

概述 etcd 是兼具一致性和高可用性的键值数据库，为云原生架构中重要的基础组件，由CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现，还可以作为 key-value 存储的中间件。 先决条件 运行的 etcd 集群个数成员为奇数。 etcd 是一个 leader-based 分布式系统。确保主节点定期向所有从节点发送心跳，以保持集群稳定。 保持稳定的 etcd 集群对 Kubernetes 集群的稳定性至关重要。因此，请在专用机器或隔离环境上运行 etcd 集群，以满足所需资源需求]。 确保不发生资源不足。 集群的性能和稳定性对网络和磁盘 IO 非常敏感。任何资源匮乏都会导致心跳超时，从而导致集群的不稳定。不稳定的情况表明没有选出任何主节点。在这种情况下，集群不能对其当前状态进行任何更改，这意味着不能调度新的 pod。 相关术语 Raft：etcd所采用的保证分布式系统强一致性的算法。 Node：节点 ，Raft状态机的一个实例，具有唯一标识。 Member： 成员，一个etcd实例。承载一个Node，且可为客户端请求提供服务。 Cluster：集群，由多个Member构成可以协同工作的etcd集群。 Peer：同伴，Cluster中其他成员。 Proposal ：提议，一个需要完成 raft 协议的请求(例如写请求，配置修改请求)。 Client： 向etcd集群发送HTTP请求的客户端。 WAL：预写式日志，etcd用于持久化存储的日志格式。 snapshot：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。 Proxy：etcd的一种模式，为etcd集群提供反向代理服务。 Leader：Raft算法中通过竞选而产生的处理所有数据提交的节点。 Follower：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。 Candidate：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。 Term：某个节点成为Leader到下一次竞选时间，称为Ubuntu一个Term。 Index：数据项编号。Raft中通过Term和Index来定位数据。 ETCD 部署 源码安装 基于master分支构建etcd bash 1 2 3 git clone https://github.com/etcd-io/etcd.git cd etcd ./build # 如脚本格式为dos的，需要将其格式修改为unix，否则报错。 启动命令 --listen-client-urls 于 --listen-peer-urls 不能为域名...