导图社区 K8S
- 442
- 19
- 2
- 举报
K8S
学习过程中整理的k8s相关知识，包括K8S的教程、网络模型、特性和作用等，作为笔记和学习引导非常有用。
编辑于2021-11-19 16:31:28- Kubernetes
- k8s
- 相似推荐
- 大纲
基础
教程
http://docs.kubernetes.org.cn/
推荐
https://www.cnblogs.com/linuxk/p/10436260.html
https://www.kuboard.cn/
网络模型
通信场景
同一Pod内的容器间通信
各个Pod彼此间的通信
Pod和Service间的通信
集群外部流量和Service之间的通信
三种网络
节点网络
Pod网络
Service网络
特性
自愈
重启已经停机的容器
替换、kill 那些不满足自定义健康检查条件的容器
在容器就绪之前，避免调用者发现该容器
服务发现和负载均衡
Kubernetes 可以通过 DNS 名称或 IP 地址暴露容器的访问方式。并且可以在同组容器内分发负载以实现负载均衡
存储编排
自动发布和回滚
密钥及配置管理
自动容器调度
Kubernetes 自动决定将容器部署到何处。当您在多个节点上运行许多容器时，这确实非常方便
零停机降级
如果在某些容器中发现错误，可以恢复到这些容器的旧版本，而不会中断
作用
管理云平台中多主机上的容器化应用
能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着
其他
Pod与控制器的区别
controllers
在集群上管理和运行容器的对象通过label-selector相关联
Pod
通过控制器实现应用的运维，如伸缩，升级等
有状态/无状态 区别
有状态
实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
实例之间不对等的关系，以及依靠外部存储的应用
无状态
deployment 认为所有的pod都是一样的
不用考虑顺序的要求
不用考虑在哪个node节点上运行
可以随意扩容和缩容
集群
master
组件
kubelet
kube-proxy
master也是一个节点，所以节点需要的组件他也需要
API Server
Schedule(调度器)
kube-controller-manager
etcd
Pod网络
作用
协调控制整个集群
协调集群中的所有行为/活动，例如应用的运行、修改、更新等
暴露API接口
跟踪其他服务器的健康状态、以最优方式调度负载，以及编排其他组件之间的通信
生产环境中通常要部署多个Master节点，组成Cluster
node
Node主要负责提供容器的各种依赖环境，并接受Master管理
必备组件
kubelet
kube-proxy
container runtime
作用
负责接收来自master的工作指令
运行应用的工作节点
状态
地址
包括hostname、外网IP和内网IP
条件（Condition）
包括OutOfDisk、Ready、MemoryPressure和DiskPressure
容量（Capacity）
Node上的可用资源，包括CPU、内存和Pod总数
基本信息
包括内核版本、容器引擎版本、OS类型等
核心组件
etcd
保存集群的配置信息和各种资源的状态信息
当数据发生变化时，etcd会快速地通知k8s相关组件
etcd是一个独立的服务组件，并不隶属于K8S集群
生产环境当中etcd应该以集群方式运行，以确保服务的可用性
提供了监听/推送机制
etcd不仅仅用于提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。在K8S集群系统中，etcd的键值发生变化会通知倒API Server，并由其通过watch API向客户端输出
API Server
资源操作的唯一入口
提供认证、授权、访问控制、API注册和发现等机制
所有的请求都需要经过这个接口进行通信
API
3大类属性
元数据
metadata
用来表示api对象
必备属性
namespace
name
uid
规范
spec
设置系统配置信息
状态
status
描述了系统期望达到的状态
kube-controller-manager
作用
维护集群的状态
比如故障检测、自动扩展、滚动更新等
管理集群各种资源，保证资源处于预期的状态
生命周期功能：包括Namespace创建和生命周期、Event垃圾回收、Pod终止相关的垃圾回收、级联垃圾回收及Node垃圾回收等。
API业务逻辑：例如，由ReplicaSet执行的Pod扩展等。
组成
副本控制器（replication controller）
端点控制器（endpoints controller）
namespace controller
serviceaccounts controller
Schedule(调度器)
负责资源的调度，按照调度策略（预定和择优）将Pod调度到相应的机器上
Scheduler在调度时会对集群的结构进行分析，当前各个节点的负载，以及应用对高可用、性能等方面的需求
kubelet
负责管理pods和它们上面的容器，images镜像、volumes、etc
负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
kubelet是node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态
默认情况下，kubelet在启动时会向master注册自己，并创建Node资源
管理Kubernetes Master和Node之间的通信
管理机器上运行的Pods和containers容器
container runtime
负责节点的容器的管理工作
每个Node都需要提供一个容器运行时（Container Runtime）环境，它负责下载镜像并运行容器。目前K8S支持的容器运行环境至少包括Docker、RKT、cri-o、Fraki等
类型
Docker
rkt
kube-proxy
service在逻辑上代表了后端的多个Pod，外界通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务，负责将访问的service的TCP/UDP数据流转发到后端的容器，如果有多个副本，kube-proxy会实现负载均衡，有2种方式：LVS或者Iptables
K8s集群中微服务的负载均衡是由Kube-proxy实现的
K8s集群内部的负载均衡器
是一个分布式代理服务器，在K8s的每个节点上都有一个
Pod网络
Pod要能够相互间通信，K8S集群必须部署Pod网络，flannel是其中一种的可选方案
附件组件
K8S集群还依赖一组附件组件，通常是由第三方提供的特定应用程序
cAdivsor
作用于各个节点（master和node节点）之上，用于收集及收集容器及节点的CPU、内存以及磁盘资源的利用率指标数据，这些统计数据由Heapster聚合后，可以通过apiserver访问
KubeDNS
在K8S集群中调度并运行提供DNS服务的Pod，同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务
负责整个集群提供DNS服务
Dashboard
K8S集群的全部功能都要基于Web的UI，来管理集群中的应用和集群自身
K8S集群安装好后默认没有包含Dashboard，我们需要额外创建它
Prometheus（或HeapSter）
容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期时间，在最新的版本当中，其主要功能逐渐由Prometheus结合其他的组件进行代替
提供资源监控
Ingress Controller
Service是一种工作于4层的负载均衡器，而Ingress是在应用层实现的HTTP(S)的负载均衡。不过，Ingress资源自身并不能进行流量的穿透，，它仅仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前该功能项目大概有：Nginx-ingress、Traefik、Envoy和HAproxy等
微服务提供外网入口
Federation
提供跨可用区的集群
Fluentd-elasticsearch
提供集群日志采集、存储与查询
YAML
基本语法
注意项
缩进时不允许使用tab键
只允许使用空格
缩进空格数目不重要，只要相同层级的元素左对齐即可
#标识注释
支持的数据结构
对象
键值对集合
数组
一组按次序排列的值
中划线+空格
animal - cat - dog
中括号
[ cat , dog ]
纯量
单个的，不可再分的值
常用元素
apiVersion
指定api版本，此值必须在kubectl apiversion中
kind
指定创建资源的角色/类型
metadata
资源的元数据/属性
name
test-pod #资源的名字，在同一个namespace中必须唯一
labels
设定资源的标签
annotations
自定义注解列表
name
自定义注解名字
namespace
命名空间
resourceVersion
spec
specification of the resource content 指定该资源的内容
containers
name
容器的名字
image
镜像地址+名字
ports
containerPort
imagePullPolicy
镜像获取策略
每次启动时检查和更新（从registery）images的策略
值
Always
每次都检查
Never
每次都不检查（不管本地是否有）
IfNotPresent
IfNotPresent，如果本地有就不检查，如果没有就拉取
command
启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT
args
启动容器的命令参数，对应Dockerfile中CMD参数
env
restartPolicy
值
Always
表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器
nodeSelector
节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1
ports
port
protocol
targetPort
capacity
storage
accessModes
访问模型
ReadWriteOnce一人读写
ReadOnlyMany 多人只读
ReadWriteMany多人读写
persistentVolumeReclaimPolicy
除绑定后，数据操作
默认是Retain保留生成的数据
recycle回收
delete，删除
nfs
path
server
readOnly
progressDeadlineSeconds
replicas
设置Pod的具体数量
revisionHistoryLimit
selector
通过selector来匹配相应的Pod的label
matchLabels
matchExpressions
name
strategy
rollingUpdate
maxSurge
maxUnavailable
type
template
设置Pod的模板
metadata
spec
containers
volumeClaimTemplates
completions
subsets
配置连接信息
addresses
添加分布式地址
ip
ports
设定服务端口
port
protocol
status
availableReplicas
conditions
observedGeneration
readyReplicas
replicas
updatedReplicas
Volumes
说明
Pod 中的所有容器都可以共享 Volume
独立于任何容器，只与Pod相关
作用与docker中的大同小异，是Pod中能够被多个容器访问的共享目录，它定义在Pod上，它被一个Pod中的多个容器挂载到具体的文件目录下。Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或重启时，Volume中的数据也不会丢失
类型
awsElasticBlockStore
azureDisk
azureFile
cephfs
cinder
configMap
csi
downwardAPI
emptyDir
特点
与所在的Pod的生命周期相同
当 Pod 从节点删除时，Volume 的内容也会被删除
如果只是容器被销毁而 Pod 还在，则 Volume 不受影响
使用场景
缓存空间，例如基于磁盘的归并排序
为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行
在 Web 服务器容器服务数据时，保存内容管理器容器获取的文件
fc (fibre channel)
flexVolume
flocker
gcePersistentDisk
gitRepo (deprecated)
glusterfs
hostPath
特点
将主机node节点的文件系统中的目录或文件挂载到pod
基础主机上创建的文件或目录只能由 root 用户写入
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
其他
持久存储卷（Persistent Volume，PV）
持久存储卷声明（Persistent Volume Claim，PVC）
核心资源对象
工作负载资源(workload)
Pod
apiVersion: v1 #必选，版本号，例如v1,版本号必须可以用 kubectl api-versions 查询到 . kind: Pod #必选，Pod metadata: #必选，元数据 name: string #必选，Pod名称 namespace: string #必选，Pod所属的命名空间,默认为"default" labels: #自定义标签 - name: string #自定义标签名字 annotations: #自定义注释列表 - name: string spec: #必选，Pod中容器的详细定义 containers: #必选，Pod中容器列表 - name: string #必选，容器名称,需符合RFC 1035规范 image: string #必选，容器的镜像名称 imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像，Nerver表示仅使用本地镜像 command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令 args: [string] #容器的启动命令参数列表 workingDir: string #容器的工作目录 volumeMounts: #挂载到容器内部的存储卷配置 - name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名 mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符 readOnly: boolean #是否为只读模式 ports: #需要暴露的端口库号列表 - name: string #端口的名称 containerPort: int #容器需要监听的端口号 hostPort: int #容器所在主机需要监听的端口号，默认与Container相同 protocol: string #端口协议，支持TCP和UDP，默认TCP env: #容器运行前需设置的环境变量列表 - name: string #环境变量名称 value: string #环境变量的值 resources: #资源限制和请求的设置 limits: #资源限制的设置 cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数 memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数 requests: #资源请求的设置 cpu: string #Cpu请求，容器启动的初始可用数量 memory: string #内存请求,容器启动的初始可用数量 livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可 exec: #对Pod容器内检查方式设置为exec方式 command: [string] #exec方式需要制定的命令或脚本 httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port path: string port: number host: string scheme: string HttpHeaders: - name: string value: string tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式 port: number initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒 timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒 periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次 successThreshold: 0 failureThreshold: 0 securityContext: privileged: false restartPolicy: [Always | Never | OnFailure] #Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定 imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定 - name: string hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络 volumes: #在该pod上定义共享存储卷列表 - name: string #共享存储卷名称 （volumes类型有很多种） emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值 hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录 path: string #Pod所在宿主机的目录，将被用于同期中mount的目录 secret: #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部 scretname: string items: - key: string path: string configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部 name: string items: - key: string path: string
创建流程
1. 客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML
2. API Server处理用户请求，存储Pod数据到etcd
3. 调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机
4. 过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉
5. 主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等
6. 选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中
7. kubelet根据调度结果执行Pod创建操作： 绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器
特点
Pod都分配了唯一的IP地址，称之为Pod IP，一个Pod里的多个容器共享Pod IP地址
一个Pod里的容器与另外主机上的Pod容器能够直接通信
不可复活
类型
普通Pod
静态Pod
静态Pod不存放在etcd存储里，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行
解释
Pod是Kubernetes的最小调度单元
每一个Pod可以包含一个或多个容器
Pod的容器会作为一个整体被Master调度到一个worker上运行
每个Pod都有唯一的IP地址，称为PodIP，一个Pod里的多个容器共享PodIP地址
猜测：命名空间共享
每个pod中都包含一个根容器pause，它保存了该pod中所有容器的状态，并管理所有的容器
同一个Pod中共享网络名称空间和存储资源，而容器之间可以通过本地回环接口：lo 直接通信，但是彼此之间又在Mount、User和Pid等名称空间上保持了隔离
每个Pod都有一个特殊的被称为“根容器”的Pause 容器。 Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或者多个紧密相关的用户业务容器
一个Pod代表着集群中运行的一个进程
Pause容器(Infra容器)
解释
Pause容器作为Pod的根容器，以它的状态代表着整个容器组的状态
功能
在pod中担任Linux命名空间共享的基础
启用pid命名空间，开启init进程
生命周期
挂起（Pending）
运行中（Running）
成功（Succeeded）
失败（Failed）
未知（Unknown）
共享资源
命名空间
PID 命名空间
同一个Pod中应用可以看到其它进程
Pid的命名空间共享还没有应用到Docker中？
网络 命名空间
同一个Pod的中的应用对相同的IP地址和端口有权限
每个Pod都会被分配一个唯一的IP地址
Pod中的所有容器共享网络空间，包括IP地址和端口
Pod内部的容器可以使用localhost互相通信
Pod中的所有容器都可以访问共享的volume
IPC 命名空间
一个Pod中的应用可以通过VPC或者POSIX进行通信
UTS 命名空间
同一个Pod中的应用共享一个主机名
存储
同一个Pod中的应用可以共享磁盘，磁盘是Pod级的，应用可以通过文件系统调用
持久化
pod不做持久化操作
终止
特性
当一个节点死掉之后，上面的所有Pod均会被删除
特殊的Pod永远不会被转移到的其他的节点，作为替代，他们必须被replace.
模板
ReplicaSet
Deployment
部署一个Pod，内部只能链接service，无法互相链接
apiVersion: apps/v1beta2 kind: Deployment metadata: name: xxxx namespace: test spec: replicas: 1 selector: matchLabels: app: xxxx template: metadata: labels: app: xxxx spec: containers: - name: xxxx image: xx/xx/xx:xxx ports: - containerPort: 8080
StatefulSet
DaemonSet
Job
CronJob
ReplicationController
v1.11版本被废弃
服务发现及负载均衡型资源(ServiceDiscovery LoadBalance)
Ingress

可以使用 Ingress 来使内部服务暴露到集群外部去，它为你节省了宝贵的静态 IP
说明
service和pod的IP仅可在集群内部访问
集群外部的请求需要通过负载均衡转发到service在Node上暴露的NodePort上，然后再由kube-proxy将其转发给相关的Pod
类似于网关
作用
为进入集群的请求提供路由规则的集合
可以给service提供集群外部访问的URL、负载均衡、SSL终止、HTTP路由等
yaml
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 请求/testpath时转发到服务test的80端口
分类
单服务Ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress spec: backend: serviceName: testsvc servicePort: 80
即该Ingress仅指定一个没有任何规则的后端服务
路由到多服务的Ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 80
即根据请求路径的不同转发到不同的后端服务上
虚拟主机Ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80 - host: bar.foo.com http: paths: - backend: serviceName: s2 servicePort: 80
即根据名字的不同转发到不同的后端服务上，而他们共用同一个的IP地址
TLS Ingress
更新Ingress
功能
给service提供集群外部访问的URL
负载均衡
SSL终止
HTTP路由
Service
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
说明
部署一个内部虚拟IP，其他deployment可以链接
apiVersion: v1 kind: Service metadata: name: mysql-production namespace: test spec: ports: - port: 3306 port: 3306为内部IP name: mysql-production为service名称 此时mysql-production.test即为mysql的虚拟IP，其他可配置该字段连接到mysql，例如 "java","-Dspring.datasource.url=jdbc:mysql://mysql-production.test:3306/config", "-jar", "xxx.jar" spec.selector ： Selector配置，将选择具有指定label标签的Pod作为管理范围 NodePort: 使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务;
工作在第四层传输层（TCP/IP层）
Service 使用label selectors来匹配一组Pod
作用
定义了Pod的逻辑分组和一种可以访问它们的策略，这组Pod能被Service访问
LabelSelector
Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡
一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现
类型
ClusterIP(默认)
在集群中内部IP上暴露服务。此类型使Service只能从群集中访问
NodePort
通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort>，可以从集群的外部访问一个 NodePort 服务
LoadBalancer
使用云提供商的负载均衡器（如果支持），可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务
ExternalName
通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容，没有任何类型代理被创建。这种类型需要v1.7版本或更高版本kube-dnsc才支持
问题
Deployment 可以部署多个副本，每个 Pod 都有自己的 IP，外界如何访问这些副本呢？
通过 Pod 的 IP 吗？
Pod 很可能会被频繁地销毁和重启，它们的 IP 会发生变化，用 IP 来访问不太现实
pod会被创建、销毁
如果一部分pods提供功能给其他pod使用
如何确定pod的地址？
每个pod都有自己的IP，且动态变化
创建
{ “kind”: “Service”, “apiVersion”: “v1”, “metadata”: { “name”: “my-service” }, “spec”: { “selector”: { “app”: “MyApp” }, “ports”: [ { “protocol”: “TCP”, “port”: 80, “targetPort”: 9376 } ] } }
Headless service
无头服务，不需要cluster-IP，直接绑定具体的Pod的IP
配置与存储型资源
Volume
存储卷
CSI
容器存储接口，可以扩展各种各样的第三方存储卷
特殊类型的存储卷
ConfigMap
作用
用于保存配置数据的键值对
用来将非加密数据保存到键值对中
使用场景
环境变量
命令行参
存储卷中的配置文件
Secret
保存敏感数据
类型
Service Account
https://www.kubernetes.org.cn/service-account 顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。
用途
为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的
说明
每个namespace都会自动创建一个default service account
用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
Opaque
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: password: MWYyZDFlMmU2N2Rm username: YWRtaW4=
base64编码格式的Secret，用来存储密码、密钥等
Opaque类型的数据是一个map类型，要求value是base64编码格式
kubernetes.io/dockerconfigjson
用来存储私有docker registry的认证信息
使用方式
Volume方式
环境变量方式
DownwardAPI
把外部环境中的信息输出给容器
集群级资源
Namespace
作用
可以将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster
每个 Cluster 就是一个 Namespace
不同 Namespace 里的资源是完全隔离的
并不是 Linux Namespace，二者没有任何关系，它只是 Kubernetes 划分不同工作空间的一个逻辑单位
一种将集群资源划分为多个用途的方法
默认
default(默认名字空间)
创建资源时如果不指定，将被放到这个 Namespace 中
kube-system(系统名字空间)
Kubernetes 自己创建的系统资源将放到这个 Namespace 中
k8s默认创建的
目标
pod
services
replication controller
deployments
......
注意
node, persistentVolumes不属于namespace
配置限额
pod
cpu请求与限额
内存请求与限额
设置最大和最小内存限制
配置CPU和内存配额
配置最大和最小CPU限制
Node
Role
ClusterRole
RoleBinding
ClusterRoleBinding
元数据型资源
HPA
PodTemplate
Pod模板，可单独定义
LimitRange
其他暂未分类
Endpoints
可以把外部的链接到k8s系统中
将一个mysql连接到k8s中。 kind: Endpoints apiVersion: v1 metadata: name: mysql-production namespace: test subsets: - addresses: - ip: 10.0.0.82 ports: - port: 3306 10.0.0.xx：3306为外部mysql。 namespace: test为命名空间
PodPreset
作用
用来给指定标签的Pod注入额外的信息
环境变量
存储卷
......
ResourceQuota
Controller（控制器）
Replication Controller（复制控制器RC）--新版本中已废弃
Replication Controller：用于规定pod的创建，当提交一个RC到Kubernetes集群中以后，Master节点上的Controller Manager组件就得到通知，定期检查系统中存活的Pod,并确保目标Pod实例的数量刚好等于RC的预期值，并根据实际情况扩缩数量
就像一个进程管理器，监管着不同node上的多个pod,而不是单单监控一个node上的pod,Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）
只会对那些RestartPolicy = Always的Pod的生效
如果太多了，Replication Controller就杀死几个
如果太少了，Replication Controller会新建几个
能够保证Pod持续运行，并且在任何时候都有指定数量的Pod副本，在此基础上提供一些高级特性，比如滚动升级和弹性伸缩
注意
删除rc后pod也被删除(--cascade=false只删除rc保留创建的pod)
官方建议使用RS（Replicaset）替代RC（ReplicationController)进行部署，RS跟RC没有本质的不同，只是名字不一样，并且RS支持集合式的 selector
Deployment(部署)
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理
作用
用于无状态应用的运维管理
应用场景
定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续Deployment
说明
Deployment是通过ReplicaSet来管理Pod
Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能
Deployment为Pod 和Replicaset 提供了一个声明式定义（declarative)方法
可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行
ReplicaSet(副本集RS)
是下一代复本控制RC
作用
实现了 Pod 的多副本管理
使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet
虽然ReplicaSets可以独立使用，但是今天它主要被 Deployments 作为协调pod创建，删除和更新的机制
注意
新版本的k8s,Rs取代了Rc（ReplicationController）,RC与RS没有本质不同，只是RS支持集合式的selecor,通过标签label
虽然ReplicaSets可以独立使用，但是今天它主要被 Deployments 作为协调pod创建，删除和更新的机制
Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。因此，我们建议您使用Deployments而不是直接使用ReplicaSets，除非您需要自定义更新编排或根本不需要更新
概要
Deployments和ReplicaSets是为无状态服务而设计
DaemonSet(后台支撑服务集)
作用
用于每个 Node 最多只运行一个 Pod 副本的场景
保证在每个Node上都运行一个容器副本
正如其名称所揭示的，DaemonSet 通常用于运行 daemon
应用场景
日志收集
比如fluentd，logstash等
系统监控
比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
系统程序
比如kube-proxy, kube-dns, glusterd, ceph等
StatefuleSet
作用
为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计）
使用场景
稳定的持久化存储
即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志
即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展
即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除
即从N-1到0
组成部分
用于定义网络标志（DNS domain）的Headless Service
DNS格式为statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local
serviceName为Headless Service的名字
0..N-1为Pod所在的序号，从0开始到N-1
statefulSetName为StatefulSet的名字
namespace为服务所在的namespace，Headless Servic和StatefulSet必须在相同的namespace
.cluster.local为Cluster Domain
用于创建PersistentVolumes的volumeClaimTemplates
定义具体应用的StatefulSet
Job

用来控制批处理型任务的API对象
用途
负责批量处理短暂的一次性任务
即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
类型
非并行Job
通常创建一个Pod直至其成功结束
固定结束次数的Job
设置.spec.completions，创建多个Pod，直到.spec.completions个Pod成功结束
带有工作队列的并行Job
设置.spec.Parallelism但不设置.spec.completions，当所有Pod结束并且至少一个成功时，Job就认为是成功
CronJob
定时任务
在job的基础上添加了时间调度
Ingress
种类
github.com/kubernetes/ingress-nginx
官方
github.com/nginxinc/kubernetes-ingress
github.com/Kong/kubernetes-ingress-controller
github.com/containous/traefik
github.com/jcmoraisjr/haproxy-ingress
github.com/appscode/voyager
github.com/heptio/contour
......
其他
Node Controller
作用
维护Node状态
与Cloud Provider同步Node
给Node分配容器CIDR
删除带有NoExecute taint的Node上的Pods
管理工具
kubectl
dashboard
kuboard
概念与术语
客户端通过kubectl对api-server发起资源操作请求，api-server通过schedule具体找到某个worker node进行资源调度操作，然后由api-server将具体的调度信息记录到etcd。controller-manager间隔检测整个集群的状态，及时调整，并将信息通过api-server上报etcd
Motivation
Worker
除了Master，Kubernetes集群中的其它机器被称为worker节点。Node职责是运行容器应用，worker由Master管理，并负责监控并汇报容器的状态，同时根据Master的要求管理容器的生命周期
标签（Label）
命名规则
具有严格的命名规则
解释
仅仅是key/value，对资源的简单标注，没有实际的逻辑影响
将资源进行分类的标识符
一个对象可以有多个标签，一个标签页可以附加到多个对象
应用对象
pod
node节点
等其他资源
注解
解释
使用key/value键值对的形式进行定义
用户任意定义的“附加”信息，以便于外部工具进行查找
与标签不同，注解并不是为了保存标识信息而 存在的，它们不能像标签 一 样用于对对象进行分组
标签选择器(Label Selector)
其他
K8S 通过template来生成pod，创建完后模板和pod就没有任何关系了，rc通过 labels来找对应的pod,控制副本
apiVersion: v1 kind: ReplicationController //ReplicationController类型 metadata: name: nginx //pod名字 spec: replicas: 2 //2个副本 selector: app: nginx //通过这个标签找到生成的pod template: //定义pod模板，在这里不需要定义pod名字，就算定义创建的时候也不会采用这个名字而是.metadata.generateName+5位随机数。 metadata: labels: //定义标签 app: nginx //key:v 这里必须和selector中定义的KV一样 spec: containers: //rc 的容器重启策略必须是Always(总是重启)，这样才能保证容器的副本数正确 - image: nginx name: nginx ports: - containerPort: 80