1.kubectl讲解

1.1 kubectl命令和kubeconfig

1.2 kubectl常用命令

1.3 kubectl describe

1.4 kubectl exec

1.5 kubectl logs

2.深入理解K8S

2.1 云计算传统分类

在云出现之前，任何的公司，任何的企业要管理自己的应用，其实都需要一个完备的技术栈的。包括你的网络、存储、服务器。包括你的虚拟化、操作系统、中间件，包括运行时、数据和应用。
所以在十几年前，我们给客户做方案怎么做呢，有些客户没有基础架构的能力，但是他又要去搭建应用，这个时候就是软硬件一起推，就是说我帮你影件采购都给你做好，然后帮你把中间的所有的这些虚拟化、操作系统等装好，然后打包卖给你。这是一类做toB业务的人用的方法。
当然有一类就是说企业自己有能力，那么它就要全套的去构建。
随着业务的不断发展和演进，那么就出现了云，其实云本身就是为了适应一种计算抽象的一类需求。就是说我基础架构和最终的应用管理工具其实是两个维度的东西。第一个我要把硬件上架，硬件上架后操作系统层面之上是更抽象稍微偏软的，下面是偏硬的。那么有没有办法把这些东西抽象化，所以云就出现了。
所以，所谓的云就是把这些基础架构层面的这些资源抽象出来，让应用以抽象的模式部署到一个统一的平台里面来，这个其实就是云，就是算力的抽象。那么有了最早期的云基本上是IaaS层。
所谓的IaaS层就是云用来管基础架构层，我们提供一个个的操作系统，然后业务只需要部署到这一个个操作系统（虚拟机）上就好了。但是这会带来一个什么问题呢，就是应用面向操作系统，它本身中间还隔着非常多的东西，比如说我要搭建一个高可用应用，这个高可用应用应该怎么样去部署到不同的节点上面去，我应该怎么样去配置我的高可用服务呢，我怎么样去控制我的部署策略，所有的这些事情其实都是要去应用层面关心的。如果只给一个操作系统，那么每个公司都要关心这些问题，大家都在重复造轮子。
如果说我把操作系统管理、中间件的管理、运行时的管理全部都搭起来，你上面只需要跑你的应用，这个就是Platform as a Service,那么从networking到runtime就叫做PaaS了。
那么再后面又有发展说我们能不能以软件为中心，以应用为中心，我提供一个软件，然后你只需要用这个软件就好了。比较出名的比如说 salesforce，比如说SAP，它们就会提供一些标准化的无论是进销存的这样的软件。还有Oracle As Service，提供一个DB，你来用，就给你个账号，给你个链接，你直接用就好了。所以整个的应用都是由平台层来提供，你只需要作为一个用户就好了，这个就是Saas。
以上就是传统的云的一个演进

2.2 K8S生态系统

K8S系统事实上其实打破了这一类的边界，它把IaaS，SaaS和PaaS这些能力的边界变得不是那么清晰了，这是因为K8S基于这种标准的API，来描述所有的代管对象，所有代管对象向下探就是基础架构，向上探就是应用抽象。
它是通过统一的一套API，把所有层面的对象，统一纳管起来。K8S向下就是IaaS，它可以把整个IaaS的能力接进来，它中间就有强大的PaaS，有了PaaS之后它又是面向应用的，表示它本身又能提供SaaS的服务
所以从K8S生态来看，最底层的基础架构其实可以是它的范围，当然有些公司称自己K8S管控层面是可以分级的，但是现在的K8S社区的一个发展，它整个基础架构其实都是纳管进来了。
整个K8S的集群管理，包括集群安装，节点管理，认证授权，网络，为控制平面提供了一些核心能力，比如说应用的部署能力，支持多种部署策略，服务抽象能力，提供了服务发现的机制，服务治理的能力，整个集群的管理能力，这些它都有，所以它是一个完整的PaaS。那么有了完整的PaaS，我上面就可以运行一些公共的服务了。有了公共的服务那它就可以是一个SaaS了。

2.3 K8S设计理念

2.4 K8S Master

2.5分层架构

K8S向下实现了几个接口抽象：
一个叫cri runtime的抽象，runtime抽象相当于下面可以接docker也可以接containerd，也可以接cri-o
还有网络的抽象：CNI。这个CNI里面，就会有很多的实现，比如说在早期还有kubenet，现在kubenet已经不用了。更多的是CNI，CNI本身就会有不同的实现插件，比如说Flannel，Calico，slim
Volume：比如说CEPH等等。
镜像仓库：
Cloud Provider：比如说运行在AWS，那就会把很多功能跟AWS的接口去整合，你要运行在腾讯云，那它就跟腾讯的很多API去整合。
认证服务：较早的时候基于k stone的这种认证，现在可以支持Webhook的认证。
通过这些方式，K8S可以适用于不同的环境，向下更多的是说这种Plugin的支持和灵活性的选择。
那么向上就是K8S提供了一系列的扩展能力。主要的扩展能力就是API的扩展，比如Operator的扩展，比如说Istio能力，还有一些是为整个生态服务的。比如Helm提供了K8S的那些对象的抽象，模板抽象的能力，你一个应用部署可能需要很多的yaml，就是那些K8S的对象定义，Helm就是相当于把这些对象里面的模板抽取出来，然后它把一些可变的东西比如说版本号等等抽成一个个的变量，你要做版本更新的时候，你只需要去更改那些变量的值，然后它最后负责渲染整个模板，最后给你创建回K8S集群里面去

2.6 API设计原则

2.7K8S如何通过对象的组合完成业务描述

2.8 架构设计原则

2.9引导原则

3.K8S核心技术概念和API对象

3.1 TypeMeta

定义了对象是什么

3.2 Metadata

定义了对象是谁
Namespace是在K8S里面，可以理解成是一个个虚拟目录，它是用来放置对象的，以此将对象隔离。任何的K8S对象会分为两类，一类像节点这样的对象，比如计算节点其实是属于整个集群的，这类对象是nonNamespace，它的namespace的值永远是空的。还有一类对象，比如说Pod Service这类对象，都归属于某个租户，这些对象是属于某一个namespace的。
Annotaion是放置对象的扩展属性的

3.2.1 Label

一般我们会通过label来做过滤查询

3.2.2 Annotations

3.3 Spec 和 Status

3.4 常用K8S对象及其分组