ansible：运用级别的多机编列东西
docker：容器引擎
docker compose：单机编列东西

多机编列东西

  • docker swarm：Docker容器多机编列东西，完成Docker容器的集群办理调度的东西
  • k8s：容器多机编列东西，占据80%以上的市场份额
  • mesos + marathon：散布式资管办理结构
    • mesos：能够对集群中机器的硬件资源进行一致的调度和分配
    • marathon：mesos的容器编列结构，用来调度和运转容器服务

kubernetes概述

kubernetes理论基础

K8S是什么?

K8S的全称为 Kubernetes ，由于k和s间有8个字母(K12345678s)，所以为了方便，叫做k8s。

效果

  • 用于主动布置、扩展和办理”容器化（containerized）运用程序”的开源体系。
  • 能够了解成K8S 是担任主动化运维办理多个容器化程序（比方 Docker）的集群，是一个生态极其丰富的容器编列结构东西。

由来
K8S由google的Borg体系（博格体系，google内部运用的大规划容器编列东西）作为原型，后经go语言延用Borg的思路重写并捐献给CNCF基金会开源。

云原生基金会（CNCF）于2015年12月建立，隶归于Linux基金会。CNCF孵化的第一个项目便是Kubernetes，随着容器的广泛运用，Kubernetes已经成为容器编列东西的事实标准。

含义：词根源于希腊语的舵手、飞行员

K8S官网（官网可查看运用教程）：kubernetes.io/zh-cn/docs/…

下载地址GitHub：github.com/kubernetes/…

为什么要用 K8S?

传统的后端布置办法：把程序包（包括可执行二进制文件、装备文件等）放到服务器上，接着运转发动脚本把程序跑起来，同时发动守护脚本定期查看程序运转状况，必要的话从头拉起程序。

假如服务的恳求量上来，已布置的服务呼应不过来怎么办?传统的做法往往是，假如恳求量、内存、CPU超越阈值做了告警，运维人员马上再加几台服务器，布置好服务之后，接入负载均衡来分担已有服务的压力。

这样问题就呈现了：从监控告警到布置服务，中心需求人力介入!那么，有没有办法主动完成服务的布置、更新、卸载和扩容、缩容呢?
而这便是K8S要做的事情：主动化运维办理容器化（Docker）程序。

K8S功用

K8S是Google开源的容器集群办理体系，在Docker等容器技能的基础上，为容器化的运用供给布置运转、资源调度、服务发现和动态弹性等一系列完好功用，提高了大规划容器集群办理的便捷性。

Kubernetes首要功用如下

  • 跨主机编列容器。
  • 更充分地利用硬件资源来最大化地满足企业运用的需求。
  • 操控与主动化运用的布置与晋级。
  • 为有状况的运用程序挂教和增加存储器。
  • 线上扩展或减缩容器化运用程序与它们的资源。
  • 声明式的容器办理，确保所布置的运用依照咱们布置的方法运作。
  • 经过主动布局、主动重启、主动复制、主动弹性完成运用的状况查看与自我修正。
  • 为多个容器供给服务发现和负载均衡，使得用户无需考虑容器IP问题。

补充：有状况服务和无状况服务的差异

k8s的StatefullSet是为了处理有状况服务的问题（对应Deployments和ReplicaSets 是为无状况服务而设计）

有状况和无状况服务的差异

  • 有状况
    • 有实时的数据需求存储
    • 集群服务中，把某一台服务器抽离出去，过一段时间再加入到集群中，假如服务集群无法正常作业（相互之间需求数据同步）
  • 无状况
    • 没有实时的数据需求存储
    • 集群服务中，把某一台服务器抽离出去，过一段时间再加入到集群中，假如服务集群还是正常作业（相互之间不用数据同步）

Kubernetes集群架构与组件

K8S 是归于主从设备模型（Master-Slave 架构），即由Master节点担任集群的调度、办理和运维，Slave 节点是集群中的运算作业负载节点。
在 K8S 中，主节点一般被称为Master节点，而从节点则被称为Worker Node 节点，每个 Node 都会被Master 分配一些作业负载。

Master组件能够在群会集的任何核算机上运转，但建议 Master节点占据一个独立的服务器。由于 Master是整个集群的大脑，假如Master 地点节点宕机或不可用，那么一切的操控命令都将失效。除了Master，在 K0s集群中的其他机器被称为Worker Node 节点，当某个Node宕机时，其上的作业负敬会被Master主动转移到其他节点上去。

中心组件

kubernetes理论基础

Master组件

Kube-apiserver

用于露出Kubernetes API，任何资源恳求或调用操作都是经过kube-apiserver供给的接口进行。以HTTP Restful API供给接口服务，一切目标资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd存储。

能够了解成API Server 是 K8S 的恳求进口服务。API Server担任接纳K8S 一切恳求（来自UI界面或许CLI 命令行东西），然后依据用户的具体恳求，去告诉其他组件干活。能够说 API Server是 K8S集群架构的大脑。

apiserver一切服务的恳求进口。Master是整个集群的大脑，apiserver为Master中枢神经。

Kube-controller-manager

运转办理操控器，是K8S 集群中处理惯例使命的后台线程，是K8S集群里一切资源目标的主动化操控中心。
在K8S集群中，一个资源对应一个操控器，而Controller manager便是担任办理这些操控器的。

由一系列操控器组成，经过 API Server 监控整个集群的状况，并确保集群处于预期的作业状况，比方当某个 Node意外宕机时，Controller Manager会及时发现并执行主动化修正流程，确保集群一直处于预期的作业状况。

这些操控器首要包括

  • Node Controller（节点操控器）：担任在节点呈现毛病时发现和呼应。
  • Replication Controller（副本操控器）：担任确保集群中一个RC（资源目标Replication Controller）所相关的 Pod副本数一直保持预设值。能够了解成确保集群中有且仅有N个 Pod实例，N是 RC中界说的 Pod副本数量。
  • Endpoints Controller（端点操控器）：填充端点目标（即连接Services和 Pods），担任监听 Service和对应的 Pod副本的变化。能够了解端点是一个服务露出出来的拜访点，假如需求拜访一个服务，则有必要知道它的endpoint。
  • Service Account & Token Controllers（服务帐户和令牌操控器）：为新的命名空间创立默许帐户和 API拜访令牌。
  • ResourceQuota Controller（资源配额操控器）：确保指定的资源目标在任何时分都不会过量占用体系物理资源
  • Namespace Controller（命名空间操控器）：办理namespace 的生命周期
  • Service Controller（服务操控器）：归于K8S集群与外部的云渠道之间的一个接口操控器。

Kube-scheduler

是担任资源调度的进程，依据调度算法为新创立的 Pod挑选一个适宜的Node节点。

能够了解成K8s一切Node节点的调度器。当用户要布置服务时，Scheduler会依据调度算法挑选最适宜的 Node 节点来布置Pod。

  • 预选战略（predicate）
  • 优选战略（priorities）
扼要作业原理
  • API Server 接纳到恳求创立一批Pod，API Server 会让 Controller-manager 依照所预设的模板去创立Pod，Controller-manager 会经过 API Searver 去找Scheduler为新创立的 pod挑选最适合的 Node节点。
    • 比方运转这个 Pod需求2C4G 的资源，Scheduler会经过预选战略过滤掉不满足战略的 Node 节点（预选战略）。
  • Node节点中还剩多少资源是经过报告给API Server存储在etcd 里，API Server 会调用一个办法找到etcd里一切 Node 节点的剩余资源，再对比 Pod所需求的资源，假如某个Node节点的资源不足或许不满足预选战略的条件则无法经过预选。
  • 预选阶段筛选出的节点，在优选阶段会依据优先战略为经过预选的 Node节点进行打分排名，挑选得分最高的Node。
    • 例如，资源越富裕、负载越小的Node或许具有越高的排名（优选战略）。

装备存储中心

etcd

K8S 的存储服务。etcd是散布式键值存储体系，存储了K8S的要害装备和用户装备，K8S 中仅 API Server才具有读写权限，其他组件有必要经过 API Server的接口于能读写数据。

Node组件

Kubelet

Kubelet是Node 节点的监视器，以及与 Master节点的通讯器。Kubelet 是 Master节点安插在 Node节点上的眼线，它会守时向 API Server报告自己 Node节点上运转的服务的状况，并接受来自 Master节点的指示采纳调整办法。

从Master 节点获取自己节点上 pod 的希望状况（比方运转什么容器、运转的副本数量、网络或许存储怎么装备等，直接跟容器引擎交互完成容器的生命周期办理，假如自己节点上 Pod 的状况与希望状况不一致，则调用对应的容器渠道接口（即 docker 的接口）达到这个状况。

办理镜像和容器的清理作业，确保节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源。

Kubelet把这些容器拉扯大，还要给它们送终。

总结：在Kubernetes集群中，在每个Node （又称Worker Node）上都会发动一个 kubelet服务进程。该进程用于处理 Master下发到本节点的使命，办理Pod 及 Pod中的容器。每个kbelet进程都会在 API Server 上注册节点自身的信息，定期向句 Master报告节点资源的运用情况，并经过cAdvisor监控容器和节点资源。

Kube-Proxy

Kube-Proxy在每个 Node 节点上完成 Pod 网络署理，是Kubernetes Service资源的载体，担任保护网络规矩和四层负载均衡作业。
担任写入规矩至iptables、 ipvs完成服务映射拜访的。

Kube-Proxy本身不是直接给 Pod 供给网络，Pod的网络是由Kubelet供给的，Kube-Proxy 实际上保护的是虚拟的 Pod 集群网络。
Kube-apiserver经过监控Kube-Proxy 进行对 Kubernetes Service 的更新和端点的保护。

在K8S 集群中微服务的负载均衡是由 Kube-proxy 完成的。Kube-proxy 是K8S 集群内部的负载均衡器。它是一个散布式署理服务器，在K8S 的每个节点上都会运转一个Kube-proxy组件。

容器引擎（如docker或rocket）

容器引擎，运转容器，担任本机的容器创立和办理作业。

当kubernetes把pod调度到节点上，节点上的 kubelet会指示 docker发动特定的容器。接着，kubelet 会经过docker继续地收集容器的信息， 然后提交到主节点上。docker 会如往常相同拉取容器镜像、发动或停止容器。不同点只是在于这是由主动化体系操控而非办理员在每个节点上手动操作的。

K8S创立pod的作业流程

kubernetes理论基础

  1. 用户经过客户端发送创立pod的恳求到master节点上的apiserver
  2. apiserver会先将相关的恳求信息写入到etcd中，然后找controller-manager依据预设的资源模板创立pod清单
  3. controller-manager会经过apiserver去找scheduler为新创立的pod挑选最适合的node节点
  4. scheduler经过调度算法的预选战略和优选战略筛选出最适合的node节点
  5. 然后再经过apiserver找到对应的node节点上的kubelet去创立和办理pod
  6. kubelet直接跟容器引擎交互，来办理容器的生命周期
  7. 用户经过创立承载在kube-proxy上的service资源，写入相关的网络规矩，完成对pod的服务发现和负载均衡

Kubernetes 中心概念

Kubernetes包括多种类型的资源目标：Pod、Label、Service、Replication Controller等。

一切的资源目标都能够经过 Kubernetes 供给的 kubectl 东西进行增、删、改、查等操作，并将其保存在 etcd 中耐久化存储。

Kubernets其实是一个高度主动化的资源操控体系，经过跟踪对比etcd存储里保存的资源希望状况与当时环境中的实际资源状况的差异，来完成主动操控和主动纠错等商级功用。

Pod

Pod是 Kubernetes 创立或布置的最小/最简略的基本单位，一个 Pod 代表集群上正在运转的一个进程。
能够把Pod了解成豌豆荚，而同一Pod内的每个容器是一颗颗豌豆。

一个Pod由一个或多个容器组成，Pod中容器同享网络、存储和核算资源，在同一台 Docker 主机上运转。
一个 Pod里能够运转多个容器，又叫边车形式（SideCar）。而在生产环境中一般都是单个容器或许具有强相关互补的多个容器组成一个Pod。

同一个 Pod 之间的容器能够经过 localhost 互相拜访，而且能够挂载Pod 内一切的数据卷；可是不同的Pod 之间的容器不能用localhost拜访，也不能挂载其他 Pod的数据卷。

kubernetes理论基础

Pod操控器

Pod 操控器是 Pod 发动的一种模版，用来确保在K8S里发动的 Pod应一直依照用户的预期运转（副本数、生命周期、健康状况查看等）。

K8S 内供给了许多的 Pod操控器，常用的有以下几种

  • Deployment：无状况运用布置。Deployment 的效果是办理和操控 Pod 和ReplicaSet，管控它们运转在用户希望的状况中。
  • ReplicaSet：确保预期的 Pod副本数量。Replicaset 的效果便是办理和操控 Pod，管控他们好好干活。可是，ReplicaSet 受控于Deployment。
    • 能够了解成Deployment便是总包工头，首要担任监督底下的工人 Pod干活，确保每时每刻有用户要求数量的 pod 在作业。假如一旦发现某个工人pod不行了，就赶忙新拉一个 Pod过来替换它。而Replicaset便是总包工头手下的小包工头。
    • 从K8S运用者视点来看，用户会直接操作Deployment布置服务，而当Deployment被布置的时分，K8S会主动生成要求的Replicaset和Pod。用户只需求关心Deployment，而不操心ReplicaSet。
    • 资源目标Replication Controller 是 ReplicaSet 的前身，官方引荐用Deployment替代 Replication Controller来布置服务。

kubernetes理论基础

  • Daemonset：确保一切节点运转同一类Pod，确保每个节点上都有一个此类 Pod 运转，一般用于完成体系级后台使命。
  • Statefulset：有状况运用布置
  • Job：一次性使命。依据用户的设置，Job办理的 Pod把使命成功完成果主动退出了。
  • Cronjob：周期性计划性使命

Label

标签，是 K8S特征的办理方法，便于分类办理资源目标。

Label能够附加到各种资源目标上，例如 Node、Pod、Service、Rc等，用于相关目标、查询和筛选。
一个 Label是一个 key-value的键值对，其间key 与 value 由用户自己指定。

一个资源目标能够界说恣意数量的Label，同一个Label 也能够被增加到恣意数量的资源目标中，也能够在目标创立后动态增加或许删去。能够经过给指定的资源目标绑缚一个或多个不同的Label，来完成多维度的资源分组办理功用。

与Label类似的，还有 Annotation（注释）。
差异在于有用的标签值有必要为63个字符或更少，而且有必要为空或以字母数字字符([a-z0-9A-Z])最初和结束，中心能够包括横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度约束。

Label挑选器(Label selector)

给某个资源目标界说一个Label，就相当于给它打了一个标签；随后能够经过标签挑选器（Label selector）查询和筛选具有某些 Label的资源目标。
标签挑选器目前有两种：根据等值联系（等于、不等于）和根据集合联系（归于、不归于、存在)。

Service

在K8S的集群里，尽管每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的（它们能够被创立，而且毁掉之后不会再发动），随时或许会由于事务的变更，导致这个IP地址也会随着 Pod的毁掉而消失。（pod的IP是随机分配的）

Service便是用来处理这个问题的中心概念。

K8S中的 Service并不是咱们常说的”服务”的含义，而更像是网关层，能够看作一组供给相同服务的Pod的对外拜访接口、流量均衡器。
Service 效果于哪些Pod是经过标签挑选器来界说的。

在K8S集群中，Service能够看作一组供给相同服务的Pod的对外拜访接口。客户端需求拜访的服务便是service目标。每个Service 都有一个固定的虚拟ip （这个ip 也被称为Cluster IP），主动而且动态地绑定后端的 Pod，一切的网络恳求直接拜访Service 的虚拟ip，Service 会主动向后端做转发。

Service的cluster ip只能在集群内部被拜访。

Service 除了供给安稳的对外拜访方法之外，还能起到负载均衡（Load Balance）的功用，主动把恳求流量散布到后端一切的服务上，Service能够做到对客户透明地进行水平扩展（scale）。

而完成 service这一功用的要害，便是kube-proxy。 kube-proxy 运转在每个节点上，监听API Server 中服务目标的变化，可经过以下三种流量调度形式：userspace（抛弃）、iptables（濒临抛弃）、ipvs（引荐，性能最好）来完成网络的转发。

Service 是K8S服务的中心，屏蔽了服务细节，一致对外露出服务接口，真正做到了”微服务”。比方咱们的一个服务A，布置了3个副本，也便是个Pod；关于用户来说，只需求关注一个 Service 的进口就能够，而不需求操心终究应该恳求哪一个 Pod。
优势十分明显：一方面外部用户不需求感知由于 Pod 上服务的意外崩溃、K8S从头拉起Pod而形成的IP变更；外部用户也不需求感知因晋级、变更服务带来的 pod替换而形成的IP变化。

kubernetes理论基础

service的功用总结

（k8s集群内）

  1. service资源经过标签挑选器相关具有相同标签的Pod
  2. 每个service都有一个固定的cluster ip，可供在k8s集群内部被拜访
  3. service能够把经过cluster ip发来的恳求负载均衡4层署理转发到它所相关的后端pod上

Ingress

Service首要担任K8S 集群内部的网络拓扑，那么集群外部怎么拜访集群内部呢?
这个时分就需求Ingress 了。 Ingress 是整个 K8S 集群的接入层，担任集群内外通讯。Ingress 是 K8S集群里作业在OSI网络参考模型下，第7层的运用，对外露出的接口，典型的拜访方法是http/https。

Service只能进行第四层的流量调度，表现形式是 ip + port。Ingress则能够调度不同事务域、不同URL拜访途径的事务流量。
比方：客户端恳求www.abc.com:port —> Ingress —> Service —> Pod

Ingress的功用总结

（k8s集群外）

  1. ingress能够作为k8s对外露出的网关接口接纳k8s集群外部发来的恳求流量
  2. ingress支持7层署理转发，它能够经过依据不同的域名或许URL拜访途径把恳求流量转发到不同的service上

Name资源称号

由于K8S 内部，运用”资源”来界说每一种逻辑概念（功用），所以每种”资源”，都应该有自己的”称号”。
“资源”有api版别（apiversion）、类别（kind）、元数据（metadata）、界说清单（spec）、状况（status）等装备信息。
“称号”一般界说在”资源”的“元数据”信息里。在同一个namespace空间中有必要是仅有的。

Namespace

随着项目增多、人员增加、集群规划的扩大，需求一种能够逻辑上隔离K8S内各种”资源”的办法，这便是 Namespace。Namespace是为了把一个 K8S集群划分为若干个资源不可同享的虚拟集群组而诞生的。
不同Namespace 内的”资源”称号能够相同，相同 Namespace内的同种”资源”，”称号”不能相同。

合理的运用K8S 的 Namespace，能够使得集群办理员能够更好的对交付到K8S里的服务进行分类办理和阅读。K8S里默许存在的 Namespace 有：default、kube-system、kube-public等。
查询 K8S里特定“资源”要带上相应的 Namespace；假如不指定命名空间，会运用default。

常见的K8s依照布置方法

  • Minikube

    • Minikube是一个东西，能够在本地快速运转一个单节点微型K8S，仅用于学习、预览xes的一些特性运用。
    • 布置地址：kubernetes.io/docs/setup/…

  • Kubeadm

    • Kubeadm也是一个东西，供给kubeadm init和kubeadm join，用于快速布置K8S集群，相对简略。
    • kubernetes.io/docs/refere…

  • 二进制装置布置

    • 生产首选，从官方下载发行版的二进制包，手动布置每个组件和自签TLS证书，组成K8S集群，新手引荐。
    • github.com/kubernetes/…

Kubeadm降低布置门槛，但屏蔽了许多细节，遇到问题很难排查。假如想更容易可控，引荐运用二进制包布置Kubernetes集群，尽管手动布置费事点，期间能够学习许多作业原理，也利于后期保护。

k8s布置二进制与高可用的差异

  • 二进制布置

    • 布置难，办理方便，集群伸展性能好
    • 更安稳，集群规划抵达一定的规划(几百个节点、上万个Pod)，二进制安稳性是要高于kubeadm布置
    • 遇到毛病，宿主机起来了，进程也会起来

  • kubeadm布置

    • 布置简略，办理难
    • 是以一种容器办理容器的方法答应的组件及服务，毛病康复时间比二进制慢
    • 遇到毛病，发动宿主机，再发动进程，最后去发动容器，集群才干康复，速度比二进制慢

总结

K8S有哪些组件？组件的效果？

k8s有master和worker node两类节点

  • master节点上有apiserver、controller-manager、scheduler以及运用etcd做k8s集群存储
    • apiserver：一切服务恳求的一致拜访进口
    • controller-manager：担任为pod副本集、命名空间、端点等资源目标以及布置供给操控器
    • scheduler：担任Pod资源调度，经过调度算法（预选战略、优选战略）为布置的pod挑选最适合的node节点
  • etcd：K8S集群数据库，是键值对存储结构的散布式数据库，存储K8S集群一切重要信息。只要apiserver能有读写权限
  • node节点上有kubelet、kube-proxy、容器引擎（比方docker）
    • kubelet：创立和办理pod中的资源，跟容器引擎交互完成容器的生命周期；收集节点的资源信息和pod运转状况报告给master的apiserver
    • kube-proxy：作为service资源的载体，完成 Pod 网络署理，保护网络规矩和四层负载均衡作业
    • 容器引擎：运转容器

K8S创立pod的作业流程？

  1. 用户经过客户端发送创立pod的恳求到master节点上的apiserver
  2. apiserver会先将相关的恳求信息写入到etcd中，然后找controller-manager依据预设的资源模板创立pod清单
  3. controller-manager会经过apiserver去找scheduler为新创立的pod挑选最适合的node节点
  4. scheduler经过调度算法的预选战略和优选战略筛选出最适合的node节点
  5. 然后再经过apiserver找到对应的node节点上的kubelet去创立和办理pod
  6. kubelet直接跟容器引擎交互，来办理容器的生命周期
  7. 用户经过创立承载在kube-proxy上的service资源，写入相关的网络规矩，完成对pod的服务发现和负载均衡

k8s常见的资源目标

  • pod
  • pod操控器
  • 标签label
  • 标签挑选器label selector
  • selector
  • service
  • ingress
  • 资源称号name
  • 命名空间namespace

pod操控器有哪些？

  • deployment：布置无状况运用。同时也办理replicaset（维持pod副本希望数目）和pod（k8s创立的最小单元，一个容器化的运用进程）
  • statefulset：布置有状况运用
  • daemonset：在一切的node节点上布置同一种pod
  • job：布置一次性使命的pod, pod执行完使命就会主动退出，只布置一次
  • cronjob：周期性的布置一次性使命的pod