企业级kubernetes(K8s)入门学习

参考链接:https://weread.qq.com/web/reader/98f32600716bc23e98f6d96

容器编排概念

1、Docker通过"镜像"机制极富创造性地解决了应用程序打包的根本性难题,它推动了容器技术的快速普及生产落地
2、容器本身仅提供了托管运行应用的底层逻辑,而容器编排才是真正产生价值的位置所在

什么是容器编排

容器编排就是管理容器的生命周期,特别是在大型动态环境中，软件团队使用容器编排来控制和自动化许多任务:
1、容器的供应和部署
2、容器的冗余和可用性
3、扩展或删除容器,以便在主机基础设施上均匀地分布应用程序负载
4、在主机资源短缺或主机死亡时,将容器从一个主机移动到另一个主机
5、在容器之间分配资源
6、对外公开在容器中运行的服务
7、容器之间服务发现的负载平衡
8、容器和主机的运行状况监视
9、与运行应用程序的容器相关的应用程序配置
简单来说,容器编排是指容器应用的自动布局、协同及管理、它主要负责完成以下具体任务:
1、Service Discovery:服务注册和服务发现
2、Load Balancing:负载均衡
3、Secrets/configuration/storage management:配置和存储管理
4、Health checks:健康状态检测
5、Auto-[scaling/restart/healing] of containers and nodes:容器和节点的[扩容缩容/重启/修复]
6、Zero-downtime deploys:零宕机部署

kubernetes

K8S简介

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

K8S的特性

kubernetes是一种用于在一组主机上运行和协同容器化应用程序的系统,旨在提供可预测性、可扩展性与高可用性的方法来完全管理容器化应用程序和服务的生命周期的平台,用户可以定义应用程序的运行方式,以及与其他应用程序或外部世界交互的途径,并能实现服务的扩容和缩容，执行平滑滚动更新，以及在不同版本的应用程序之间调度流量以测试功能或回滚有问题的部署。Kubernetes提供了接口和可组合的平台原语，使得用户能够以高度的灵活性和可靠性定义及管理应用程序

1、自动装箱
构建于容器之上,基于资源依赖及其他约束自动完成容器部署且不影响其可用性,并通过调度机制混合关键型应用和非关键型应用的工作负载于同一节点以提升资源利用率
2、自我修复(自愈)
支持容器故障后自动重启、节点故障后重新调度容器,以及可用节点、健康状态检查失败后关闭容器
并重新创建等自我修复机制

3、水平扩展
支持通过简单命令或UI手动水平扩展，以及基于CPU等资源负载率的自动水平扩展机制
4、服务发现和负载均衡
Kubernetes通过其附加组件之一的KubeDNS(或CoreDNS)为系统内置了服务发现功能,它会每个Service配置
DNS名称,并允许集群内的客户端直接使用此名称发出请求,而Service则通过iptables或ipvs内建了负载均衡机制

5、自动发布和回滚
Kubernets支持"灰度"更新应用程序或其配置信息,它会监控更新过程中应用程序的监控状态,以确保它不会在同一时刻杀掉所有实例,而此过程中一旦有故障发生,就会立即自动执行回滚操作

6、存储编排
Kubernetes支持Pod对象按需自动挂载不同类型的存储系统,这包括节点本地存储、公有云服务商的云存储
(如AWS和GCP等)，以及网络存储系统(例如:NFS、ISCSI、Ceph、GlusterFS等)

7、批量处理执行
除了服务型应用,Kubernetes还支持批处理作业及CI(持续集成),如果需要,一样可以实现容器故障后恢复

K8S的概念和术语

Kubernetes使用共享网络将多个物理机或虚拟机汇集到一个集群中,在各服务器之间进行通信，该集群是配置Kubernetes的所有组件、功能和工作负载的物理平台。集群中一台服务器(或高可用部分中的一组服务)用作Master,负责管理整个集群,余下的其他机器用作worker Node,它们是使用本地和外部资源接收和运行工作负责的服务器

Master

1、Master是集群的网关和中枢,负责诸如为用户和客户端暴露API、跟踪其他服务器的健康状态、以最优方式调度工作负载,以及编排其他组件之间的通信等任务,它是用户或客户端与集群之间的核心联络点,
2、并负责Kubernetes系统的大多数中式管控逻辑,单个Master节点即可完成其所有的功能,但出于冗余及负载均衡等目地生产环境中通常需要协同部署多个此类主机。Master节点类似于蜂群中的蜂王

Node

1、Node是Kubernetes集群的工作节点,负责接收来自Master的工作指令并根据指令相应地创建或销毁Pod对象,以及调整网络规则以合理地路由和转发流量等。理论上讲,Node可以是任何形式的计算设备,不过Master会统一将其抽象为Node对象进行管理。Node类似于蜂群中的工蜂、生产环境中,它们通常数量众多
2、Kubernetes将所有Node的资源集结于一处形成一台更加强大的"服务器",在用户将应用部署于其上时,Master会使用调度算法将其自动指派至某个特定的Node运行，在Node加入集群或从集群中移除时,Master也会按需重新编排影响到的Pod(容器),于是用于无需关心其应用究竟运行于何处,此图是node组成的虚拟资源池

Kubernetes还有众多的组件来支撑其内部的业务逻辑，包括运行应用、应用编排、服务暴露、应用恢复等，
它们在Kubernetes中被抽象为Pod、Service、Controller等资源类型:

Pod

1、Kubernetes并不直接运行容器,而是使用一个抽象的资源对象来封装一个或多少容器,这个抽象即为Pod,它是Kubernetes的最小调度单元。

资源标签

1、标签(Label)是将资源进行分类的标识符,资源标签其实就是一个键值型(key/values)数据

标签选择器

标签选择器(Selector)全称为"Label Selector",它是一种根据Label来过滤符合条件的资源对象的机制，例如,将附有标签"role:backend"的所有pod对象挑选出来归为一组就是标签选择器的一种应用

Pod控制器

尽管Pod是Kubernetes的最小调度单元，但用户通常并不会直接部署及管理Pod对象，而是要借助于另一类抽象——控制器（Controller）对其进行管理。用于工作负载的控制器是一种管理Pod生命周期的资源抽象，它们是Kubernetes上的一类对象，而非单个资源对象，包括ReplicationController、ReplicaSet、Deployment、StatefulSet、Job等。

服务资源(Service)

Service是建立在一组Pod对象之上的资源抽象,它通过标签选择器选定一组Pod对象,并为这组Pod对象定义一个统一的固定访问入口(通常是一个IP地址),若Kubernetes集群存储DNS附件,它就会在Service创建时为其自动配置一个DNS名称以便客户端进行服务发现。到达Service IP的请求将被负载均衡至其后的端点——各个Pod对象之上，因此Service从本质上来讲是一个四层代理服务。另外，Service还可以将集群外部流量引入到集群中来。

存储卷

存储卷(Volume)是独立容器文件系统之外的存储空间,常用于扩展容器的存储空间并为它提供持久存储能力。Kubernetes集群上的存储卷大体可分为临时卷、本地卷和网络卷。临时卷和本地卷都位于Node本地,一旦Pod被调度至其他Node,此种类型的存储卷将无法访问到,因此临时卷和本地卷通常用于数据缓存持久化的数据则需要放置于持久卷之上

Name和Namespace

1、名称(Name)是Kubernetes集群中资源对象的标识符,它们的作用域通常是名称空间(Namespace),因此名称空间是名称的额外的限定机制。在同一个名称空间中,同一类型资源对象的名称必须具有唯一性。名称空间通常用于实现租户或项目的资源隔离,从而形成逻辑分组，创建的Pod和Service等资源对象都属于名称空间级别,未指定时,它们都属于默认的名称空间"default"

Ingress

1、Kubernetes将Pod对象和外网网络环境进行了隔离,Pod和Service等对象的通信都使用其内部专用地址进行如若需要开放某些Pod对象提供给外部用户访问,则需要为其请求流量打开一个通往Kubernetes集群内部的通道,除了Service之外,Ingress也是这类通道的实现方式之一

Kubernetes集群组件

一个典型的Kubernetes集群由多个工作节点(worker node)和一个集群控制平面(control plane,即Master),以及一个集群状态存储系统(etcd)组成,其中Master节点负责整个集群的管理工作,为集群提供管理接口,并监控和编排集群中的各个工作节点。各节点负责以Pod的形式运行容器,因此,各节点需要事先配置好容器运行依赖到的所有服务和资源，如容器运行时环境等

Master节点主要由apiserver、controller-manager和scheduler三个组件,以及一个用于集群状态存储的etcd存储服务组成,而每个Node节点则主要包含kubelet、kube-proxy及容器引擎(Docker)等组件。此外,完整的集群服务还依赖于一些附加组件,如kuberDNS等

Master组件

API Server

1、API Server负责输出RESTful风格的Kubernetes API,它是发往集群的所有REST操作命令的接入点,并负责接收、校验并响应所有的REST请求,结果状态都被持久存储于etcd中,因此,API Server是整个集群的网关

控制器管理器(Controller Manager)

Kubernetes中,集群级别的大多数功能都是由几个被成为控制器的进程实现的,这几个进程被集成于
Kube-controller-manager守护进程中。由控制器完成的功能主要包括生命周期功能和API业务逻辑,
具体如下:
1、生命周期功能：包括Namespace创建和生命周期、Event垃圾回收、Pod终止相关的垃圾回收、级联垃圾回收及Node垃圾回收等
2、API业务逻辑：例如，由ReplicaSet执行的Pod扩展等

调度器（Scheduler）

1、Kubernetes是用于部署和管理大规模容器应用的平台,根据集群规模的不同,其托管的容器可能会数以千计甚至更多。API Server确认Pod对象的创建请求之后,便需要由Scheduler根据集群内各节点的可用资源状态,以及要运行的容器的资源需要做出调度决策

Node组件

Node负责提供运行容器的各种依赖环境，并接受Master的管理。每个Node主要由以下几个组件构成
1、Node的核心代理程序kubelet

Node的核心代理程序kubelet

Node的核心代理程序kubelet

1、Kubelet是运行于工作节点之上的守护进程,它从API Server接收关于Pod对象的配置信息并确保它们处于期望的状态。Kubelet会在API Server上注册当前工作节点,定期向Master汇报节点资源使用情况,并通过cAdvisor监控容器和节点的资源占用状况

容器运行时环境

每个Node都要提供一个容器运行时(Container Runtime)环境,它负责下载镜像并运行容器,Kubelet并未固定链接至某容器运行时环境,而是以插件的方式载入配置的容器环境。这种方式清晰地定义了各组件的边界目前,Kubernetes支持的容器运行环境至少包括Docker、RKT、Cri-o和Fraki等

kube-proxy

每个工作节点都需要运行一个kube-proxy守护进程,它能够按需为Service资源对象生成iptables或ipvs规则从而捕获访问当前Service的ClusterIP的流量并将其转发至正确的后端Pod对象

核心附件

1、KubeDNS:在Kubernetes集群中调度运行提供DNS服务的Pod,同一集群中的其他Pod可使用此服务解决主机名
2、Kubernetes Dashboard:Kubernetes集群的全部功能都要基于Web的UI,来管理集群中的应用甚至集群自身
3、Heapster:容器和节点的性能监控与分析系统,它收集并解析多种指标数据,如资源利用率、生命周期事件等,新版本的Kubernetes中，其功能会逐渐由Prometheus结合其他组件所取代
4、Ingress Controller:Service是一种工作于传统层的负载均衡器，而Ingress是在应用层实现的HTTP（s）负载均衡机制。不过，Ingress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前，此类的可用项目有Nginx、Traefik、Envoy及HAProxy等。

Kubernetes网络模型

网络模型基础

云计算的核心是虚拟化技术,网络虚拟化技术又是其最重要的组成部分,用于在物理网络上虚拟多个相互隔离的虚拟网络，实现网络资源切片,提供网络资源利用率,实现弹性化网络。Kubernetes作为容器云技术栈中的容器编排组件,必须需要在多租户(名称空间)的基础上实现弹性网络管理,这也是"基础设施即代码"的要求之一

网络模型概述

Kubernetes的网络中主要存在四种类型的通信:同一Pod内的容器间的通信、各Pod彼此之间的通信、Pod与Service间的通信,以及集群外部的流量同Service之间的通信。Kubernetes为Pod和Service资源对象分别使用了各自的专用网络,Pod网络由Kubernetes的网络插件配置实现,而Service的网络则由Kubernetes集群予以指定。为了提供更灵活的解决方式,Kubernetes的网络模型需要借助外部插件实现,它要求任何实现机制都必须满足以下需求。

1、所有Pod间均可不经NAT机制而直接通信
2、所有节点均可不经NAT机制而直接与所有容器通信
3、容器自已使用的IP也是其他容器或节点直接看到的地址,换句话讲,所有Pod对象都位于同一平面网络中,而且可以使用Pod自身的地址直接通信
Kubernetes使用的网络插件必须能为Pod提供满足以上要求的网络,它需要为每个Pod配置至少一个特定的地址,即Pod IP。Pod IP地址实际存在于某个网卡(可以是虚拟设备)上,而Service的地址却是一个虚拟IP地址,没有任何网络接口配置此地址,它由kube-proxy借助iptables规则或ipvs规则重新定向到本地端口,再将其调度至后端Pod对象。Service的IP地址是集群提供服务的接口,也称为Cluster IP
Pod网络及其IP由Kubernetes的网络插件负责配置和管理,具体使用的网络地址可再管理配置网络插件时指定,如10.244.0.0/16网络。而Cluster网络和IP则是由Kubernetes集群负责配置和管理,如10.96.0.0/12网络

1、一个是各个主机(Master、Node和etcd等)自身所属的网络,其地址配置于主机的网络接口,用于各个主机之间的通信,例如:Master与各Node直接的通信。例如Master与各Node之间的通信,此地址配置于Kubernetes集群构建之前,它并不能由Kubernetes管理，管理员需要于集群构建之前自行确定其地址配置及管理方式。
2、Kubernetes集群上专用于Pod资源对象的网络,它是一个虚拟网络,用于为各Pod对象设定IP地址等网络参数,其地址配置于pod中容器的网络接口之上。Pod网络需要借助kubenet插件或CNI插件实现,该插件可独立部署于Kubernetes集群之外亦可托管于Kubernetes之上,它需要在构建Kubernetes集群时由管理员进行定义,而后在创建Pod对象时由其自动完成各网络参数的动态配置
3、专用于Service资源对象的网络,它也是一个虚拟网络,用于为Kubernetes集群之上的Service配置IP地址,但此地址并不配置于任何主机或容器的网络接口之上,而是通过Node之上的kube-proxy配置为iptables或ipvs规则,从而将发往此地址的所有流量调度至其后端的各Pod对象之上,Service网络在Kubernetes集群创建时予以指定，而各Service的地址则在用户创建Service时予以动态配置

CNI是指容器网络接口（Container Network Interface），是由CNCF（Cloud NativeComputing Foundation）维护的项目，其由一系列的用于编写配置容器网络插件的规范和库接口（libcni）组成，支持众多插件项目

本文地址：https://blog.csdn.net/qinjiamao1/article/details/107399510