您的位置: 首页  >  文章  >  KUBERNETES之入门知识准备

KUBERNETES之入门知识准备

分类: 文章 • 2024-01-30 10:51:04

文章目录

一、容器(云)前生今世

1.云计算概述

1.1 传统数据中心面临的问题

  • 资源利用率低
  • 资源分配不合理
  • 自动化能力差
    • tftp
    • ftp/http
    • PXE
    • dhcp
  • 初始成本高

1.2 云计算是什么

  • 一种资源交付模式
  • 必须通过网络来使用
  • 弹性计算，按需付费，快速扩展

1.3 云计算分类

  • 公有云 阿里云，腾讯云，亚马逊云
  • 私有云 企业定制
  • 混合云 公有+私有

1.4 云计算分层

KUBERNETES之入门知识准备

  • IaaS 基础设施即服务 AWS,阿里云,腾讯云
  • PaaS 平台即服务 新浪云
  • SaaS 软件即服务 云盘，企业邮箱等

2.云计算平台发展

2.1 虚拟化技术

  • KVM

KUBERNETES之入门知识准备

  • VMware

KUBERNETES之入门知识准备

  • Hyper-V
    KUBERNETES之入门知识准备

2.2 Opentack

openstack

KUBERNETES之入门知识准备

2.3 CloudFoundry

CloudFoundry

KUBERNETES之入门知识准备

  • 应用托管
  • 如何为应用打包 cf push ”应用“

2.4 Redhat

Openshift

KUBERNETES之入门知识准备

2.5 CoreOS

KUBERNETES之入门知识准备

Rocket容器（rkt） Fleet集群管理

2.6 Docker

Docker

KUBERNETES之入门知识准备

​

  • 镜像（一次构建，随时运行）

    • docker build
    • docker run

  • 大规模部署？

    • Deis的Flynn

    • 2014年底docker原生Swarm

      • 多机部署容器 docker run -H “xxx” “xx” master node…

    • docker machine 多机部署docker daemon

    • Fig项目

      • 提出容器编排（Orchestration） 编排指用户如何通过某些工具或配置来完成一组虚拟机(容器)以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。

        定义在一个配置文件

        • 应用容器A
        • 数据库容器B
        • 负载均衡容器C

      • 被docker收购，后改名为compose

    • 收购DocketPlane 处理容器网络

    • 收购Tutum 图形化管理界面

2.7 Mesosphere

KUBERNETES之入门知识准备

旨在使用户能够像管理一台机器那样管理万级别物理机集群，并使用docker容器在集群中*地部署应用。

  • 集群管理项目 Mesos
  • 容器调度管理 Marathon
    Twitter

2.8 Kubernetes

KUBERNETES之入门知识准备

​

  • 2014年6月份，google宣告Kubernetes项目诞生。

  • Lmctfy（Let me container that for you）容器

  • 2015年6月，由Docker公司牵头，CoreOS、Google、Redhat等公司宣布，Docker将自己的Libcontainer捐出，交由一个完全中立的基金会管理，改名为RunC项目，共同制定容器和镜像的标准和规范。 OCI（Open Container Initiative）

  • Google、Redhat等开源基础设施领域玩家共同牵头发起一个名为CNCF（Cloud Native Computing Foundation）基金会，来对抗Docker公司为核心的容器商业生态。 目标

    • Kubernetes项目能够在容器编排领域去的足够大的竞争优势 应对方式：Borg&Omega

KUBERNETES之入门知识准备

  • CNCF社区必须以Kubernetes项目为核心，覆盖足够多的场景。 应对方式 ：添加各种容器生态知名工具和项目

    • Fluentd
    • OpenTracing
    • CNI

  • 2016年，Docker放弃现由Swarm项目，将容器编排和集群管理功能全部内置到Docker项目中

  • Kubernetes反其道而行之，开始在整个社区推进”*化“架构：从API到容器运行时的每一层，都为开发者暴露出可以扩展的插件机制，鼓励用户通过代码的方式接入K8s的每个阶段。 成果

    • 目前热度极高的微服务治理项目Istio
    • 被广泛采用的有状态应用部署框架Operator
    • Rook，Ceph容器存储插件

  • 2017年开始，Docker公司将容器运行时Containerd捐给CNCF社区，Docker公司宣布将Docker项目改名为Moby，然后交给社区维护。但仍占用docker注册商标 docker ce docker ee

  • 2017年10月，在自己主打产品Docker企业版中内置Kubernetes项目，标志着”编排之战“落幕

  • 2018年1月30日，Redhat斥资2.5亿美元收购CoreOS

  • 2018年3月，Docker公司CTO solomon辞职

3.传统、虚拟化、容器部署发展

KUBERNETES之入门知识准备

3.1 传统部署时代

早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果，其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但是，这并没有随着资源利用不足而扩展，并且组织维护许多物理服务器的成本很高。

3.2 虚拟化部署时代

作为解决方案，引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。虚拟化允许应用程序在VM之间隔离，并提供一个安全级别，因为一个应用程序的信息不能被另一应用程序*访问。

虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性，因为可以轻松地添加或更新应用程序，降低硬件成本等等。借助虚拟化，您可以将一组物理资源呈现为一组一次性虚拟机。

每个VM都是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

3.3 容器部署时代

容器类似于VM，但是它们具有轻松的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻质的。与VM相似，容器具有自己的文件系统，CPU，内存，进程空间等。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。

3.4 容器的好处

容器之所以受欢迎，是因为它们提供了额外的好处，例如：

  • 敏捷的应用程序创建和部署：与使用VM映像相比，容器映像创建的简便性和效率更高。
  • 持续的开发，集成和部署：通过快速简单的回滚（由于图像不可更改），提供可靠且频繁的容器映像构建和部署。
  • 开发和运营的关注点分离：在构建/发布时而不是在部署时创建应用程序容器映像，从而将应用程序与基础架构分离。
  • 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他信号。
  • 跨开发，测试和生产的环境一致性：在笔记本电脑上与在云中一样在笔记本电脑上运行。
  • 云和操作系统分发的可移植性：可在Ubuntu，RHEL，CoreOS，本地，主要公共云以及其他任何地方运行。
  • 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行操作系统到使用逻辑资源在操作系统上运行应用程序。
  • 松散耦合，分布式，弹性，解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理–而不是在一台大型单机上运行的整体堆栈。
  • 资源隔离：可预测的应用程序性能。
  • 资源利用：高效率和高密度。

二、容器&K8s

1.什么是容器？

1.1 一系列隔离运行的进程，提供了一种轻量操作系统层面的虚拟化技术

1.2 每个容器拥有自己的PID，User，Network栈namespace等

1.3 与传统VM比具有启动快、性能损耗小、更轻量等优点

  • docker早期
    • dotdocker
  • docker现在版本

1.4 容器化系统面临的挑战

  • 容器解决了应用打包、部署、运行的问题 一次构建，随处运行
  • 容器的挑战
    • 跨机器部署
    • 资源调度
    • 负载均衡
    • 自动伸缩
    • 容错处理
    • 服务发现

2.什么是K8s？

一切以服务为中心，一切围绕服务运转

通常我们会把Kubernetes看作Docker的上层架构，就好像Java与J2EE的关系一样: J2EE 是以Java为基础的企业级软件架构，而Kubernetes则以Docker 为基础打造了一个云计算时代 的全新分布式系统架构。但Kubernetes与Docker之间还存在着更为复杂的关系，从表面上看， 似乎Kubernetes 离不开Docker,但实际上在Kubernetes的架构里，Docker 只是其目前支持的两种底层容器技术之一，另一个容器技术则是Rocket, 后者来源于CoreOS这个Docker昔日的“恋人”所推出的竞争产品。

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件.

 
 

k8s

​ 首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征：

  • 拥有一个唯一指定的名字（比如my-mysql-server）
  • 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
  • 能够体统某种远程服务能力
  • 被映射到了提供这种服务能力的一组容器应用上

Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内置的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们队服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，我们不用为了服务的IP地址的变化问题而头疼了。

容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。

在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

  • 目标Pod的定义
  • 目标Pod需要运行的副本数量（Replicas）
  • 要监控的目标Pod标签（Label）

在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，知道Pod实例的数量达到预定目标，这个过程完全是自动化。

2.1 功能

容器编排

  • 自动化容器的部署和复制
  • 随时扩展或收缩容器规模
  • 将容器组织成组，并且提供容器间的负载均衡
  • 自动发布和回滚
  • **和配置管理
  • 存储编排

2.2 容器编排相关工具介绍

  • docker自身
    • 容器编排 docker compose
    • 容器集群管理 docker swarm
    • 多机docker部署 docker machine
  • mesos + marathon 资源调度+服务信息管理
  • kubernetes
    • Pod
    • Sidecar

三、K8s全局架构

KUBERNETES之入门知识准备

1.Master节点

​ k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程

KUBERNETES之入门知识准备

​

1.1 kube-apiserver

​ APIServer负责对外提供RESTful的kubernetes API的服务，它是系统管理指令的统一接口，任何对资源的增删改查都要交给APIServer处理后再交给etcd，如图，kubectl(kubernetes提供的客户端工具，该工具内部是对kubernetes API的调用）是直接和APIServer交互的。

关于RESTful参考 http://www.ruanyifeng.com/blog/2011/09/restful.html

1.2 kube-scheduler

​ scheduler负责调度Pod到合适的Node上，如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定。 kubernetes目前提供了调度算法，同样也保留了接口。用户根据自己的需求定义自己的调度算法。

1.3 controller-manager

​ 如果APIServer做的是前台的工作的话，那么controller manager就是负责后台的。每一个资源都对应一个控制器。而control manager就是负责管理这些控制器的，比如我们通过APIServer创建了一个Pod，当这个Pod创建成功后，CM的任务就算完成了。

1.4 Etcd

​ etcd是一个高可用的key-value键值存储系统，kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。

 
 
 

2.Node节点

Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.

  • 每个Node节点都运行着以下一组关键进程
  • kubelet：负责对Pod对于的容器的创建、启停等任务
  • kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
  • Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。

2.1 kubelet

​ kubelet是Master在每个Node节点上面的agent，是Node节点上面最重要的模块，它负责维护和管理该Node上的所有容器，但是如果容器不是通过kubernetes创建的，它并不会管理。本质上，它负责使Pod的运行状态与期望的状态一致。

2.2 kube-proxy

​ 该模块实现了kubernetes中的服务发现和反向代理功能。kube-proxy支持TCP和UDP连接转发，默认基Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面，kube-proxy使用etcd的watch机制监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响

2.3 CRI

​ Container Runtime Interface,在k8s中,kubelet主要负责同容器运行时(Docker)打交道,这个交互过程依赖于CRI

2.4 OCI

​ Open Cantainer Initiative,Docker项目一般通过OCI这个容器运行时规范底层的linux操作系统进行交互,即把CRI请求翻译成对Linux操作系统的调用(Namespace和Cgroups等)

2.5 gRPC

​ kubelet 还通过 gRPC 协议同一个叫作 Device Plugin的插件进行交互,这个插件是用来管理宿主物理设备的主要组件

2.6 CNI&CSI

​ Container调用网络插件和存储插件为容器配置网络和持久化存储,通过CNI和CSI交互

 
 
 
 

3.kubernetes调用流程

1.用户通过kubectl来进行操作，例如部署新应用
2.API Server请求，并将其存储到Etcd
3.Watcher和Controllers检测到资源状态的变化，并进行操作
4.ReplicaSet wacher/controller检测到新的app，创建新的pod期望的实例个数
5.Scheduler将新的pod分配到kubelet
6.kebelet检测到pods，并通过容器运行时部署它们
7.kubeproxy管理Pod的网络，包括服务发现、负载均衡

相关推荐