k8s的认知与学习

关于 K8s 的基本概念咱们将会围绕以下七点展开:web

  • Docker 的管理痛点
  • 什么是 K8s?
  • 云架构 & 云原生
  • K8s 架构原理
  • K8s 核心组件
  • K8s 的服务注册与发现
  • 关键问题

Docker 的管理痛点

若是想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。算法

因而,咱们迫切须要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。后端

Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。api

Google 在 2014 年开源了 Kubernetes 项目,创建在 Google 在大规模运行生产工做负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。浏览器

K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文咱们将使用简称。服务器

什么是 K8s ?

K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工做负载和服务,可促进声明式配置和自动化。

K8s 拥有一个庞大且快速增加的生态系统。K8s 的服务、支持和工具普遍可用。网络

经过 K8s 咱们能够:架构

  • 快速部署应用
  • 快速扩展应用
  • 无缝对接新的应用功能
  • 节省资源,优化硬件资源的使用

K8s 有以下特色:app

  • 可移植:支持公有云,私有云,混合云,多重云 multi-cloud。
  • 可扩展:模块化,插件化,可挂载,可组合。
  • 自动化:自动部署,自动重启,自动复制,自动伸缩/扩展。

云架构 & 云原生

①云和 K8s 是什么关系负载均衡

云就是使用容器构建的一套服务集群网络,云由不少的大量容器构成。K8s 就是用来管理云中的容器。

②常见几类云架构

常见几类云架构如上图所示:

  • On-Premises(本地部署)
  • IaaS(基础设施即服务):用户:租用(购买|分配权限)云主机,用户不须要考虑网络,DNS,硬件环境方面的问题;运营商:提供网络,存储,DNS,这样服务就叫作基础设施服务。
  • PaaS(平台即服务-中间件):MySQL/ES/MQ/...
  • SaaS(软件即服务-浏览器页面):钉钉,财务管理。
  • Serverless:无服务,不须要服务器。站在用户的角度考虑问题,用户只须要使用云服务器便可,在云服务器所在的基础环境,软件环境都不须要用户关心。

若是以为很差理解,推荐阅读这篇文章:如何通俗解释 IaaS、PaaS、SaaS 的区别:

https://www.zhihu.com/question/21641778/answer/62523535

能够预见:将来服务开发都是 Serverless,企业都构建了本身的私有云环境,或者是使用公有云环境。③云原生

为了让应用程序(项目,服务软件)都运行在云上的解决方案,这样的方案叫作云原生。

云原生有以下特色:

  • 容器化,全部服务都必须部署在容器中
  • 微服务,Web 服务架构式服务架构
  • CI/CD
  • DevOps

K8s 架构原理

①K8s 架构

k8s架构解释:

归纳来讲 K8s 架构就是一个 Master 对应一群 Node 节点。下面咱们来逐一介绍 K8s 架构图中的 Master 和 Node。

Master 节点结构以下:

  • apiserver 即 K8s 网关,全部的指令请求都必需要通过 apiserver。
  • Scheduler调度器,使用调度算法,把请求资源调度到某一个 Node 节点。
  • Controller 控制器,维护 K8s 资源对象。
  • etcd: 存储资源对象。

Node 节点结构以下:

  • Kubelet 在每个 Node 节点都存在一份,在 Node 节点上的资源操做指令由 Kubelet 来执行。
  • Kube-proxy 代理服务,处理服务间负载均衡。
  • Pod 是 K8s 管理的基本单元(最小单元),Pod 内部是容器,K8s 不直接管理容器,而是管理 Pod。
  • Docker 运行容器的基础环境,容器引擎。
  • Fluentd 日志收集服务。

在介绍完 K8s 架构后,咱们又引入了不少技术名词。不要着急,先有总体概念,再各个击破。请耐心阅读下文,相信你必定会有不同的收获。

K8s 核心组件

①K8s 组件

K8s 是用来管理容器,可是不直接操做容器,最小操做单元是 Pod (间接管理容器):

  • 一个 Master 有一群 Node 节点与之对应。
  • Master 节点不存储容器,只负责调度、网管、控制器、资源对象存储。
  • 容器的存储在 Node 节点,容器是存储在 Pod 内部的)。
  • Pod 内部能够有一个容器,或者多个容器。
  • Kubelet 负责本地 Pod 的维护。
  • Kube-proxy 负责负载均衡,在多个 Pod 之间来作负载均衡。

②Pod 是什么?解释以下:

  • Pod 也是一个容器,这个容器中装的是 Docker 建立的容器,Pod 用来封装容器的一个容器,Pod 是一个虚拟化分组。
  • Pod 至关于独立主机,能够封装一个或者多个容器。
  • Pod 有本身的 IP 地址、主机名,至关于一台独立沙箱环境。

**③Pod 到底用来干什么?

一般状况下,在服务部署时候,使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务,要么部署一组有关系的服务。一组相关的服务是指:在链式调用的调用连路上的服务。

**④Web 服务集群如何实现?

**实现服务集群:只须要复制多方 Pod 的副本便可,这也是 K8s 管理的先进之处,K8s 若是继续扩容,只须要控制 Pod 的数量便可,缩容道理相似。

**⑤Pod 底层网络,数据存储是如何进行的?

具体以下:

  • Pod 内部容器建立以前,必须先建立 Pause 容器。
  • 服务容器之间访问 localhost ,至关于访问本地服务同样,性能很是高。

⑥ReplicaSet 副本控制器

  • 控制 Pod 副本「服务集群」的数量,永远与预期设定的数量保持一致便可。
  • 当有 Pod 服务宕机时候,副本控制器将会立马从新建立一个新的 Pod,永远保证副本为设置数量。

副本控制器:标签选择器-选择维护一组相关的服务(它本身的服务)

  • ReplicationController 副本控制器:单选。
  • ReplicaSet 副本控制器:单选,复合选择。
selector:
    app = web
    Release = stable

在新版的 K8s 中,建议使用 ReplicaSet 做为副本控制器,ReplicationController 再也不使用了。

⑦Deployment 部署对象

Deployment 部署对象以下:

  • 服务部署结构模型
  • 滚动更新

ReplicaSet 副本控制器控制 Pod 副本的数量。可是,项目的需求在不断迭代、不断的更新,项目版本将会不停的的发版。版本的变化,如何作到服务更新?
部署模型:

  • ReplicaSet 不支持滚动更新,Deployment 对象支持滚动更新,一般和 ReplicaSet 一块儿使用。
  • Deployment 管理 ReplicaSet,RS 从新创建新的 RS,建立新的 Pod。

⑧MySQL 使用容器化部署,存在什么样的问题?

问题以下:

  • 容器是生命周期的,一旦宕机,数据丢失
  • Pod 部署,Pod 有生命周期,数据丢失

Deployment与StatefulSet(有状态与无状态部署策略)

对于 K8s 来讲,不能使用 Deployment 部署有状态服务。一般状况下,Deployment 被用来部署无状态服务,那么对于有状态服务的部署,使用 StatefulSet 进行有状态服务的部署。

什么是有状态服务?
  • 有实时的数据须要存储。
  • 有状态服务集群中,把某一个服务抽离出去,一段时间后再加入机器网络,若是集群网络没法使用。
什么是无状态服务?
  • 没有实时的数据须要存储。
  • 无状态服务集群中,把某一个服务抽离出去,一段时间后再加入机器网络,对集群服务没有任何影响。

⑨StatefulSet

为了解决有状态服务使用容器化部署的一个问题:

  • 部署模型
  • 有状态服务

StatefulSet 保证 Pod 从新创建后,Hostname 不会发生变化,Pod 就能够经过 Hostname 来关联数据。

K8s 的服务注册与发现

①Pod 的结构是怎样的?

结构以下:

  • Pod 至关于一个容器,Pod 有独立 IP 地址,也有本身的 Hostname,利用 Namespace 进行资源隔离,独立沙箱环境。
  • Pod 内部封装的是容器,能够封装一个,或者多个容器(一般是一组相关的容器)。

②Pod 网络具体以下:

  • Pod 有本身独立的 IP 地址。
  • Pod 内部容器之间访问采用 Localhost 访问。
  • Pod 内部容器访问是 Localhost,Pod 之间的通讯属于远程访问(集群内部服务可见)。

**③Pod 是如何对外提供服务访问的?

Pod 是虚拟的资源对象(进程),没有对应实体(物理机,物理网卡)与之对应,没法直接对外提供服务访问。
那么该如何解决这个问题呢?
Pod 若是想要对外提供服务,必须绑定物理机端口。也就是说在物理机上开启端口,让这个端口和 Pod 的端口进行映射,这样就能够经过物理机进行数据包的转发。归纳来讲:先经过物理机 IP+Port 进行访问,再进行数据包转发。--【NodePort】

④一组相关的 Pod 副本,如何实现访问负载均衡?

咱们先明确一个概念,Pod 是一个进程,是有生命周期的。宕机、版本更新,都会建立新的 Pod。这时候 IP 地址会发生变化,Hostname 会发生变化,使用 Nginx 作负载均衡就不太合适了。因此咱们须要依赖 Service 的能力。

⑤Service 如何实现负载均衡?

简单来讲,Service 资源对象包括以下三部分:

  • Pod IP:Pod 的 IP 地址。
  • Node IP:物理机 IP 地址。
  • Cluster IP:虚拟 IP ,是由 K8s 抽象出的 Service 对象,这个 Service 对象就是一个 VIP 的资源对象。

⑥Service VIP 更深刻原理探讨

具体以下:

  • Service 和 Pod 都是一个进程,Service 也不能对外网提供服务。
  • Service 和 Pod 之间能够直接进行通讯,它们的通讯属于局域网通讯。
  • 把请求交给 Service 后,Service 使用 iptable,ipvs 作数据包的分发。

⑦Service 对象是如何和 Pod 进行关联的?

具体以下:

  • 不一样的业务有不一样的 Service。
  • Service 和 Pod 经过标签选择器进行关联。
selector:
    app=x 选择一组订单的服务 pod ,建立一个 service;
    经过 endpoints 存放一组 pod ip;

Service 经过标签选择器选择一组相关的副本,而后建立一个 Service。

⑧Pod 宕机、发布新的版本的时候,Service 如何发现 Pod 已经发生了变化?

每一个 Pod 中都有 Kube-Proxy,监听全部Pod。若是发现 Pod 有变化,就动态更新(etcd 中存储)对应的 IP 映射关系。

关键问题

①企业使用 K8s 主要用来作什么?

有以下三个方面:

  • 自动化运维平台,创业型公司,中小型企业,使用 K8s 构建一套自动化运维平台,自动维护服务数量,保持服务永远和预期的数据保持一致性,让服务能够永远提供服务。这样最直接的好处就是降本增效。
  • 充分利用服务器资源,互联网企业,有不少服务器资源「物理机」,为了充分利用服务器资源,使用 K8s 构建私有云环境,项目运行在云。这在大型互联网公司尤其重要。
  • 服务的无缝迁移,项目开发中,产品需求不停的迭代,更新产品。这就意味着项目不停的发布新的版本,而 K8s 能够实现项目从开发到生产无缝迁移。

②K8s 服务的负载均衡是如何实现的?

  • Pod 中的容器极可能由于各类缘由发生故障而死掉。Deployment 等 Controller 会经过动态建立和销毁Pod来保证应用总体的健壮性。
  • 换句话说,Pod是脆弱的,但应用是健壮的。每一个 Pod 都有本身的 IP 地址。当 Controller 用新 Pod 替代发生故障的 Pod 时,新 Pod 会分配到新的 IP 地址。这样就产生了一个问题:若是一组 Pod 对外提供服务(好比 HTTP),它们的 IP 颇有可能发生变化,那么客户端如何找到并访问这个服务呢?
  • K8s 给出的解决方案是 Service。Kubernetes Service 从逻辑上表明了一组 Pod,具体是哪些 Pod 则是由 Label 来挑选。Service 有本身 IP,并且这个 IP 是不变的。客户端只须要访问 Service 的 IP,K8s 则负责创建和维护 Service 与 Pod 的映射关系。不管后端 Pod 如何变化,对客户端不会有任何影响,由于 Service 没有变。

③无状态服务通常使用什么方式进行部署?

Deployment 为 Pod 和 ReplicaSet 提供了一个 声明式定义方法,一般被用来部署无状态服务。Deployment 的主要做用:定义 Deployment 来建立 Pod 和 ReplicaSet 滚动升级和回滚应用扩容和索容暂停和继续。Deployment不只仅能够滚动更新,并且能够进行回滚,若是发现升级到 V2 版本后,服务不可用,能够迅速回滚到 V1 版本。

相关文章
相关标签/搜索