目录
建于 Docker 之上的 K8s可以构建一个容器的调度服务，其目的是让用户透过K8s 集群来进行云端容器集群的管理，而无需用户进行复杂的设置工作。系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作。
其核心概念是 Container Pod。一个 Pod 由一组工作于同一物理工作节点的容器构成。这些组容器拥有相同的网络命名空间、IP以及存储配额，也可以根据实际情况对每一个 Pod 进行端口映射。此外，Kubernetes 工作节点会由主系统进行管理，节点包含了能够运行 Docker 容器所用到的服务。
1. Pod
Pod是k8s创建或部署的最小单位，可以运行一个或多个容器（多个容器应用有紧耦合关系，组合成一个整体对外提供服务）；
一个Pod中的容器拥有相同的命名空间、IP地址和存储配额，可以通过localhost进行通信；
普通Pod一旦被创建就会被存放在etcd存储中，随后被Master调度到某个Node进行绑定，随后被该Node中的kubelet进程实例化成一组相关的Docker容器并启动；
#frontend-localredis-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-php
label:
name: redis-php
spec:
containers:
- name: frontend
image: kubeguide/guestbook-php-frontend:localredis
ports:
- containersPort: 80
- name: redis-php
image: kubeguide/redis-master
ports:
- containersPort: 6379
每个容器应用都有一个独立的EndPoint(PodIP+container port)访问点，表示这个Pod中一个服务进程对外的通信地址
- 静态Pod:不能通过API Server管理，在Node上由kubelet创建，删除只能在其运行的Node上将定义的yaml删除
- 共享Volume:
Pod配置文件中：
spec.containers.name.volumeMounts #挂载到容器内部的存储卷设置
spec.volumes #Pod上定义的共享存储卷列表
# pod-volume-applogs.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-pod
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 8080
volumeMounts:
- name: app-logs
mountPath: /usr/local/tomcat/logs
- name: logreader
image: busybox
command: ["sh","-c","tail -f /logs/catalina*.log"]
volumeMounts:
- name: app-logs
mountPath: /logs
volumes:
- name: app-logs
emptyDir: {} #emptyDir：为Pod分配到Node的时候创建。无需指定宿主机的目录文件，为Kubernetes自动分配的目录。ConfigMap:配置管理方案，引入ConfigMap对象将配置和应用分离
Pod定义文件中通过环境变量使用，spec.containers.command,spec.containers.env
Pod定义文件中通过Volumn使用,spec.volumns.configMap
- Pod调度：RC/Deployment
NodeSelector:定向调度
NodeAffinity亲和性调度：软限制，可通过Node上正运行的其他Pod标签进行限制，并非节点本身标签
PodAffinity：Pod亲和性与互斥性调度，对Pod和Node两个条件匹配
DaemonSet:每个Node上都调度一个Pod
- 查看已创建Pods信息：
kubectl get pods -n [命名空间] -o wide
2.Node
Pod实际运行环境，可以是物理机也可以是虚拟机，一个Node运行多个Pod.
拥有kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。
kubelet:负责Pod中容器的创建，启停等任务，和Master协作，会定时向Master汇报自身情况
kube-proxy：实现service的通信与负载均衡机制
Docker Engine:负责容器的创建和管理工作
3.Master
集群管理节点，拥有etcd数据库
运行kube-apiserver、kube-controller-manager和kube-scheduler这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。
apiserver是所有资源增删改查等操作的唯一入口，也是集群控制的入口进程
controller-manager是所有资源对象的自动化控制中心
scheduler是负责Pod调度的进程
4.Replication Controller（RC）
RC用来管理Pod的副本，保证集群中存在指定数量的Pod副本，是实现弹性伸缩，动态扩容，滚动升级（通过改变RC的Pod模板的镜像版本）的核心。
controller-manager进程通过RC中定义的Pods的Label筛选对应的Pod实例，并实时监控其状态和数量，实例数量少于定义的副本数量，会根据RC定义中的模板创建新的Pod，然后将新的Pod调度到合适的Node上启动运行。若多余制定数量则会停止相应的副本。
- 创建RC:
kubectl create -f xxx.yaml
配置文件包含：
- 目标Pod的定义模板
- 目标Pod需要运行的副本数量（Replicas）
- 要监控的目标Pod标签（Label）
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-rc
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-c
image: nginx
ports:
- containerPort: 80创建后，这几个Pods的副本由系统全自动完成调度，具体运行在哪个Node，完全由Master的scheduler计算得出，用户无法干预
- 查看RC状态：
kubectl get rc
- 删除RC及其Pods:
kubectl delete -f xxx.yaml
5.Replica Sets(RS)
RS和RC唯一的区别是RS支持基于集合的Label Selector
Set-based 的标签条件允许用一组value来过滤key。支持三种操作符: in ， notin 和 exists(仅针对于key符号)
6.Deployment
Deployment 是一个更高层次的概念，它能管理ReplicaSets，其继承了RC的所有功能，此外：
可以查看Deployment的升级详细进度和状态；回滚到之前的版本；对每次升级都可用随时暂停和启动等
7.Service
定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。和Pod依照标签建立关联，给Pod贴上若干标签，Service定义selector。
- k8s的三种IP：
- Node IP：Node节点物理网卡的IP地址，k8s集群外的节点访问集群内的节点时，必须通过Node IP
- Pod IP:Docker Enginee根据docker0网桥的IP地址分配，通常是虚拟的二层网络
- Cluster IP：Service的IP地址，是一个虚拟IP，只能结合Service Port组成具体的通信端口
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
type: NodePort
selector:
app: nginx
ports:
- protocol: TCP
port: 80
nodePort: 30002NodePort:将Service暴露到集群外部，在Node上暴露一个nodePort端口，外网通过NodeIP:nodePort访问到service
8.Label
任意对象（Pod,Node,RC,Service等）都通过Label标识，一个对象可以关联多个Label，一个Label也可被添加到任意个对象上。Label是RC和Service运行的基础，两者通过Label关联Node上的Pod,使用Label Selector查询和筛选对象。
应用场景：
kube-controller通过RC中定义的Label Selector筛选要监控的Pod副本数量，从而保证副本数量符合预期设定
kube-proxy通过Service定义的Selector选择对应的Pod,自动建立每个Service的转发路由表，从而实现智能负载均衡
通过Node的标签，和Pod定义文件中的NodeSelector的属性相匹配，kube-scheduler可以实现Pod的定向调度
9.Volume
是Pod中可以被多个容器访问的共享目录
10.NameSpace
可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。
11.Annotation（注释）
类似Label，也使用key/value形式进行定义，是用户任意定义的附加信息。
12.API Server
运行在Master节点上，提供接口
List-Watch机制，其他核心进程通过这个接口实时监控集群中资源对象的变化
13. Controller Manager
监控资源状态并自动化调整
Replication Controller
Node Controller
Endpoints Controller
14.Scheduler
通过调度流程计算最佳目标节点，然后绑定到该节点
接收Controller创建的Pod,kubelet接管后续工作
15. kubelet
每个Node上都会启动一个kubelet服务进程。在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。
16.kube-proxy
Service是一个抽象概念，真正提供Service功能的是kube-proxy服务进程，其核心功能是将Service的多个服务请求转发到后端的多个Pod实例上
ClusterIP和NodePort是proxy服务通过iptables的NAT转换实现的，实现了将访问服务ClusterIP、NodePort的请求负载分发到后端Pod，每个Node都要运行kube-proxy才可以在集群内部在任意Node上发起对Service的访问请求。