本文将从以下6个方面介绍Kubernetes的全栈体系：

1.Kubernetes架构
2.Kubernetes工作负载
3.Kubernetes网络
4.Kubernetes存储
5.Kubernetes运维
6.DevOps

Kubernetes起源

Kubernetes项目来源于谷歌内部的Borg，Borg是集群的管理器，在它的系统中，运行着众多集群，而每个集群可由成千上万的服务器联接组成，Borg每时每刻都在处理来自众多应用程序所提交的成百上千的Job, 对这些Job进行接收、调度、启动、停止、重启和监控。

Kubernetes于2015年7月22日迭代到 v 1.0并正式对外公布，谷歌联合Linux基金会及其他合作伙伴共同成立了CNCF基金会( Cloud Native Computing Foundation)，并将Kuberentes 作为首个编入CNCF管理体系的开源项目，助力容器技术生态的发展进步。

Kubernetes项目凝结了Google过去十年间在生产环境的经验和教训，从Borg的多任务Alloc资源块到Kubernetes的多副本Pod，从Borg的Cell集群管理，到Kubernetes设计理念中的联邦集群，在Docker等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解和新思路。

Docker

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
在这里插入图片描述
几个概念：

  • 镜像（Image）：可以看做是应用的模板，包含了应用依赖的环境和配置
  • 容器（Container）：镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和对象一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。
  • 仓库（Repository）：仓库可看成一个代码控制中心，用来保存镜像。

docker有兴趣的可以详看我的这篇博客：

分享一些我自己的docker使用经验

Kubernetes的特点和特性

谷歌开发的容器集群管理系统。它是基于Docker的容器化技术的，它在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一些列完整功能，提高了大规模容器集群管理的便捷性。
在这里插入图片描述
下面开始进入正题：

1.Kubernetes的架构

在这里插入图片描述

1.1 Kubernetes节点

Master Node

集群的网关和中枢枢纽，主要作用：暴露API接口，跟踪其他服务器的健康状态、以最优方式调度负载，以及编排其他组件之间的通信。
在这里插入图片描述
Worker Node

Kubernetes的工作节点，负责接收来自Master的工作指令，并根据指令相应地创建和销毁Pod对象，以及调整网络规则进行合理路由和流量转发。生产环境中，Node节点可以有N个。
在这里插入图片描述

1.2 Kubernetes组件

在这里插入图片描述
在这里插入图片描述

1.3 Kubernetes资源

在这里插入图片描述

2.Kubernetes工作负载

2.1 Pod

Pod介绍

Kubernetes中最小的调度单位，代表着集群中运行的进程（应用实例）。
一个Pod可以包含多个容器，但通常情况下我们在每个pod中仅使用一个容器。
Pod中可以共享两种资源：网络和存储。

在这里插入图片描述

Pod和Controller

Controller 可以创建和管理多个 Pod，提供副本管理、滚动升级
和集群级别的自愈能力。
两者通过label-selector进行关联。
在这里插入图片描述
Pod生命周期
在这里插入图片描述
重试策略（restartPolicy）：Always、OnFailure、Never

Controller
在这里插入图片描述

3.Kubernetes网络

3.1 IP和Port

在这里插入图片描述
在这里插入图片描述

3.2 内部访问

SVC

通过Label关联Pod

服务发现方式：

  • 环境变量
export MYSQL_SERVICE_HOST='xx.xxx.x.xxx'
export MYSQL_SERVICE_PORT='3306'
export MYSQL_SERVICE_PORT_MYSQL='3306'
export MYSQL_USER=''
export MYSQL_VERSION='5.7.14-1debian8'
  • DNS
    组件：CoreDNS
    同namespace访问：svc_name
    跨namespace访问：svc_name.namespace_name.svc

在这里插入图片描述

[root@test-209 log]# netstat -anp | grep kube-proxy
tcp6    0   0 :::30010        :::*          LISTEN   10165/kube-proxy 
unix 2   [ ]     DGRAM          36395  10165/kube-proxy


[root@test-209 log]# iptables -S -t nat | grep mysql
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/wordpress-mysql:" -m tcp --dport 30010 -j KUBE-MARK-MASQ 
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/wordpress-mysql:" -m tcp --dport **30010** -j KUBE-SVC-GJ6HULPZPPQIKMS7 
-A KUBE-SEP-7KXQQUXVSZ2LFV44 -s 10.0.45.6/32 -m comment --comment "default/wordpress-mysql:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-7KXQQUXVSZ2LFV44 -p tcp -m comment --comment "default/wordpress-mysql:" -m tcp -j DNAT --to-destination 10.0.45.6:3306 
-A KUBE-SEP-J7SZJXRP24HRFT23 -s 10.0.3.2/32 -m comment --comment "default/wordpress-mysql:" -j KUBE-MARK-MASQ 
-A KUBE-SEP-J7SZJXRP24HRFT23 -p tcp -m comment --comment "default/wordpress-mysql:" -m tcp -j DNAT --to-destination 10.0.3.2:3306 
-A KUBE-SERVICES -d **10.254.67.85**/32 -p tcp -m comment --comment "default/wordpress-mysql: **cluster IP**" -m tcp --dport 3306 -j KUBE-SVC-GJ6HULPZPPQIKMS7 
-A KUBE-SVC-GJ6HULPZPPQIKMS7 -m comment --comment "default/wordpress-mysql:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-J7SZJXRP24HRFT23
-A KUBE-SVC-GJ6HULPZPPQIKMS7 -m comment --comment "default/wordpress-mysql:" -j KUBE-SEP-7KXQQUXVSZ2LFV44

3.3 Flannel

在这里插入图片描述
Flannel原理：

数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端（Flannel通过Etcd服务维护了一张节点间的路由表）；

源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡；

最后就像本机容器通信一下的有docker0路由到达目标容器，这样整个数据包的传递就完成了。

3.3 外部访问

NodePort

  • nodeIP+nodeport

lngress

  • Ingress Controller和Ingress服务组成

  • Ingress Controller会动态感知集群中的Ingress的规则变化，然后读取，动态生成Nginx的配置文件，最后注入到运行nginx的pod的中，然后会自动reload，配置生效。

LoadBalancer

  • LoadBalancer在nodeport基础上，k8s可以请求底层云平台创建一个负载均衡器，将每个node作为后端，进行服务分发，该模式需要底层云平台（例如GCE）支持
    在这里插入图片描述

4.Kubernetes存储

4.1 存储卷

Kubernetes对存储抽象了两种存储卷：Volume，Persistent Volume

Volume： 与Pod之间静态绑定

与Docker的存储卷类似，使用的是Pod所在Kubernetes节点的本地目录，分为三种：

  • 1.emptyDir：一个匿名的空目录，在创建Pod时创建，删除Pod时删除。

  • 2.hostPath：在Pod之外独立存在，由用户指定宿主机上的文件或目录。

  • 3.跨节点卷： 独立于Kubernetes节点存在，可在多个节点上访问使用。

4.2 Kubernetes存储定义

Kubernetes对存储提供了三个定义：Volume，Persistent Volume 和动态存储供应(dynamic provisioning)。

Persistent Volume(PV)：与Pod之间动态绑定

  • PV是kubernetes的资源对象，可以单独创建PV，借助Persistent Volume Claim(PVC)与Pod实现动态绑定，PV先创建分类，PVC请求已创建的某个类（StorageClass）的资源。

Access Modes（访问模式）

  • ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。

  • ReadOnlyMany：该卷能够以只读模式加载到多个节点上。

  • ReadWriteMany：该卷能够以读写模式被多个节点同时加载。

Dynamic provisioning：动态存储供应

  • 动态卷供给是一个 Kubernetes 独有的功能，这一功能允许按需创建存储卷。动态方式是通过StorageClass来完成的。

PV 和 PVC 的生命周期：
在这里插入图片描述

5.Kubernetes运维

5.1 Kubernetes监控

监控维度

  • 集群本身的监控，主要是Kubernetes的各个组件

  • 集群中Pod的监控，Pod的CPU、内存、网络、磁盘等

  • 集群内部应用的监控，针对应用本身的监控

监控方案
在这里插入图片描述
Prometheus
Prometheus 是一套开源的系统监控报警框架，可以用来监控像物理机cpu、内存、数据库服务等性能参数，并把参数传到可视化页面（例如Grafana），这个有时间再开一篇详细讲解
整体架构方案：
在这里插入图片描述
Granfana：
在这里插入图片描述

5.2 Kubernetes日志收集

可以采用ELK的方式来做，详见博主ELK系列博客：

【ELK】logstash安装、使用其收集日志并展示
【ELK】filebeat安装和使用其收集日志
【ELK】elasticsearch分词器介绍和使用
【ELK】elasticsearch集群分片管理
【ELK】elasticsearch安装和配置
【ELK】elasticsearch采集的数据借助kibana进行报表分析
【ELK】elasticsearch集群部署
【ELK】elasticsearch简单使用
【ELK】elasticsearch集群健康管理
【ELK】elasticsearch的snapshot快照备份

6.DevOps

服务编排

Kubernetes虽然提供了多种容器编排对象，但是一个应用往往有多个服务，有的可能还要依赖持久化存储，当这些服务之间直接互相依赖，需要有一定的组合的情况下，使用YAML文件的方式配置应用往往十分繁琐还容易出错，这时候就需要服务编排工具。

服务编排管理工具构建在Kubernetes的基础Object之上，统筹各个服务之间的关系和依赖。

目前常用到的工具是 Helm。

Helm是一个Kubernetes应用的包管理工具，用来管理chart预先配置好的安装包资源）

有兴趣的读者可以去了解一下这个工具。

在这里插入图片描述

最后用一张云原生的全栈架构图作为本文的结束：

在这里插入图片描述

# kubernetes # docker # 容器 # 云原生 # elk
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods