初识Kubernetes
Kubenetes架构
Kubenetes组件
Kubenetes资源对象
Kubenetes网络
Kubernetes集群部署
Kubernetes日志
kubernetes监控
进阶知识
微服务
- ">
边缘计算
推荐书籍
推荐资料

初识Kubernetes

Kubernetes（K8s）是一个用于自动化部署、扩展和管理容器化应用程序的开源系统
2014年6月7日Google推出了Borg的开源版本
2015年7月21日Google与Linux基金会组建了CNCF基金会
2015年7月21日Kubernetes v1.0 发布，并捐献给CNCf基金会
2017年Docker宣布将原生支持 Kubernetes，包括Docker EE、Docker CE 以及 Docker for Mac/Windows 等全平台的支持
2017年Mesosphere也开始支持Kubernetes
每三个月发布一个新版本，目前最新的版本是1.17

项目地址:
https://github.com/kubernetes/kubernetes

官方文档
https://kubernetes.io/zh/docs/home

https://mp.weixin.qq.com/s/Hh2KWt7F0ExUSJzVcTy8rQ
Kubernetes 1.13：Kubeadm简化群集管理、容器存储接口（CSI）和CoreDNS作为默认DNS现已普遍可用
https://mp.weixin.qq.com/s/eg26el8eUOmKcUDTuvl_KQ
【深度】Kubernetes v1.16 最值得工程师关注的改动
https://mp.weixin.qq.com/s/i4MfuvozyoIEhxeGL4Hxcw
回顾 Kubernetes 最近 6 个版本重点更新
https://mp.weixin.qq.com/s/fSqfHmG8Yrw_l9Yqir2Dxg
美国时间 12 月 9 日，Kubernetes 迎来了 2019 年的最后一个新版本 1.17
https://mp.weixin.qq.com/s/XPWjRa3V9asWSwDcNYyWYg
k8s v1.17 新特性预告: 拓扑感知服务路由
https://mp.weixin.qq.com/s/SxVUNKfOn8BvMQ8tFbcdZw

最新版本

云原生与CNCF
https://www.cncf.io/
Cloud Native Computing Foundation
云原生计算基金会（以下简称CNCF）是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展
https://www.kubernetes.org.cn/5482.html

CNCF项目

云原生应用之路
https://jimmysong.io/blog/from-kubernetes-to-cloud-native/

Kubernetes 简介 - 图7

云原生应用的三大特征：容器化封装、动态管理、面向微服务
https://www.jianshu.com/p/13251fd149a6

KubeCon 中国上海-2018
**

KubeCon 中国上海-2019

KubeCon 中国上海-2020 受疫情影响已取消

Docker容器
容器十年 ——一部软件交付编年史
https://mp.weixin.qq.com/s/O7pZGz5oQOdS1Yj1YiRm5w

复习Docker
早期架构

新架构
Docker简介
https://www.yuque.com/liweiming/gfe9m0/yp0tna

Kubernetes 简介 - 图14

https://www.docker.com/products/container-runtime

containerd
美国时间2019年2月28日，CNCF正式宣布containerd毕业https://blog.csdn.net/RancherLabs/article/details/88102538

https://www.cnblogs.com/xuxinkun/p/8036832.html
Kubernetes 简介 - 图16

CRI + shimv2：一种 Kubernetes 集成容器运行时的新思路
https://mp.weixin.qq.com/s/rCyp_EbP46A5p9_XufNCQQ
Kubernetes 容器运行时演进
https://mp.weixin.qq.com/s/cf2jQ7pEHwZ2CGOjDhguSQ

Kubernetes 简介 - 图17

接触到时间
Docker 2017年7月
Kubernetes 2018年5月

Kubenetes架构

https://kubernetes.io/zh/docs/concepts/

Kubernetes 简介 - 图26

Kubenetes组件

https://mp.weixin.qq.com/s/xjaVVOMyH1JiVjQUdwMdGQ
kube-apiserver 用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行
ETCD 是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划
kube-controller-manager 管理控制器，是集群中处理常规任务的后台线程；这些控制器包括：
节点（Node）控制器
副本（Replication）控制器：负责维护系统中每个副本中的pod
端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）
Service Account和Token控制器：为新的Namespaces创建默认帐户访问API Token
kube-scheduler 监视新创建没有分配到Node的Pod，为Pod选择一个Node
kube-proxy 通过在主机上维护网络规则，并执行连接转发来实现service（Iptables/ipvs）
Kubelet 负责维护容器的生命周期

Addons：
coredns负责为整个集群提供DNS服务
Ingress对外提供七层服务的访问
metries-server提供资源监控
Dashboard提供GUI

Kubectl

Kubernetes接口
CRI（Container Runtime Interface）：容器引擎接口，提供计算资源
CNI（Container Network Interface）：容器网络接口，提供网络资源
CSI（Container Storage Interface）：容器存储接口，提供存储资源

kubectl 创建pod 流程

Kubenetes资源对象

Pod

pod健康检查与生命周期
kubectl 创建 Pod 背后到底发生了什么？
https://mp.weixin.qq.com/s/ctdvbasKE-vpLRxDJjwVMw
高清版
https://hugo-picture.oss-cn-beijing.aliyuncs.com/what-happens-when-k8s.svg

深入剖析Kubernetes
kubernetes的调度机制工作原理
Informer Path：
监听Etcd中Pod、Node、Service
PriorityQueue scheduler cache
Scheduling Path：Predicates Bind

Service

iptable

ipvs

Kubenetes网络

https://mp.weixin.qq.com/s/X43vIG3hE635DiPozvhsGA

网络方案介绍之Overlay网络-Flannel（vxlan）

Flannel 是由CoreOS维护的一个容器跨主机网络方案，由golang语言编写，后端支持多种网络模式。
VxLAN模式：Linux内核3.7+以上版本支持vxlan，使用linux内核中的VxLAN模块封装报文。也是默认模式。
Host-gw模式：即Host Gateway，它是通过在节点上，创建到达目标容器地址的路由直接完成报文转发。但是这种模式要求所有节点必须在同一个二层网络，不太适用于集群跨需要跨子网环境。
UDP模式：使用普通的UDP协议完成对于报文的封装，实现overlay网络的转发。转发性能最差。

Flannel默认网络模式。
每个节点部署一个flanneld作为agent，用于生成vtep设备和从etcd获取和上传subnet信息；
从一个大网段划分子网每个主机对应一个子网；
通过veth-pair网卡连接宿主机和POD；
同子网直接通过CNI0进行数据包转发，不同子网，封装vxlan通过flannel.1这个vtep设备建立的vxlan隧道进行传输。
访问集群外部网络经过iptables做Snat。

优势
基于VxLAN的Overlay网络虚拟化技术简化网络结构，对底层网络侵入性和依赖性小。
保证整个集群中所有容器能够获得同属一个内网且不重复的IP地址。
学习成本低，应用范围广，用户只需要一些基础知识就可以设置适合大多数用例的环境

缺点
由于利用linux内核的VxLAN模块使用CPU进行数据包的解封装操作，会带来一定的性能损耗。
本身没有网络隔离组件，没有办法进行安全策略控制。使用flanel变种canal可实现隔离，flannel+calico Network policy

网络方案介绍之undelay网络——Calico(BGP)

Calico是一种开源网络和网络安全解决方案，适用于容器，虚拟机和基于主机的本机工作负载。Calico支持广泛的平台，包括Kubernetes，docker，OpenStack和裸机服务。Calico后端支持两种网络模式。
BGP模式：将节点做为虚拟路由器通过BGP路由协议来实现集群内容器之间的网络访问。
IPIP模式：在原有IP报文中封装一个新的IP报文，新的IP报文中将源地址IP和目的地址IP都修改为对端宿主机IP。

每个节点部署一个calico-node作为agent，从etcd获取和上传subnet信息；
从一个大网段划分子网每个主机对应一个子网；
通过veth-pair网卡连接宿主机和POD；
生成明细路由，同子网直接通过明细路由进行数据包转发
将宿主机做为一个虚拟路由器，整个集群节点默认在一个自治域内，通过BGP路由协议将宿主机上路由条目互相宣告学习，这样整个集群主机都有到对应POD路由信息，不同集群通过生成的BGP路由转发。
访问集群外部网络经过iptables做Snat。
网络策略使用calico-networkpolicy组件生成对应的iptables规则。

网络方案介绍之undelay网络——Calico(BGP)路由反射
为了防止BGP路由环路，BGP协议规定在一个AS（自治系统）内部，IBGP路由器之间只能传一跳路由信息，所以在一个AS内部，IBGP路由器之间为了学习路由信息需要建立全互联的对等体关系，但是当一个AS规模很大的时候，这种全互联的对等体关系维护会大量消耗网络和CPU资源，所以这种情况下就需要建立路由反射器以减少IBGP路由器之间的对等体关系数量。

Calico(BGP)网络模型优势：
数据包采用纯三层网络协议转发，没有封装和解封装数据包的过程，传输性能几乎接近于物理网络本身的传输性能。
集群中运行的容器是以独立的IP协议栈进行数据转发，可以通过calico提供的基于iptables的安全管理功能对于集群内的容器进行网络安全防护。
Calico(BGP)网络模型劣势：
需要集群内所有节点在同一个二层网络中，或对应的三层路由转发设备支持并打开BGP路由来学习对应路由条目，对底层网络侵入性较大。
学习成本较高，用户需要具备一定的BGP知识才能完成对一些用例的支持。
若需要硬件设备学习BGP路由，则需要考虑硬件路由器本身性能和最大路由条目数。

Canal是一种将Calico和Flannel网络部署在一起的统一的联合网络解决方案，在Canal网络体系中，由Flannel提供网络解决方案，由Calico提供网络策略支持（例如：对POD之间进行网络流量隔离等），因为Canal底层是flannel，所以Canal一样支持flannel的多种网络模式。

复习Docker 网络图片来自极客时间:深入剖析Kubernetes