参考：
https://zhuanlan.zhihu.com/p/43266412
https://zhuanlan.zhihu.com/p/292081941
k8s的作用和解决什么问题
由于docker并不具备分布式集群部署，自动扩容缩容，负载均衡的能力，并且没有解决故障自愈和集群内服务间的通信问题。k8s的出现就很好的弥补了docker的这些缺点，并且k8s自身也有非常出色的容器技术，不一定非得使用docker配合k8s，在最新的k8s版本中已经移除对docker容器的支持。简而言之k8s就是容器技术的分布式架构系统
作用：
-
自动化服务
- 1、自动快速的垂直扩容缩容和水平扩容缩容、更新部署：
- a、垂直扩容和缩容：服务器能够轻易的增加和删除
- b、水平扩容和缩容：容器能轻松增加和移除
- 2、自动为扩容的pod实例提供负载均衡
- 3、自动的提供健康检查和自愈能力
- 4、根据指令做到任务的自动统一调度
- 1、自动快速的垂直扩容缩容和水平扩容缩容、更新部署：
k8s架构
K8S是属于主从设备模型（Master-Slave架构），即有Master节点负责核心的调度、管理和运维，Slave节点则在执行用户的程序。但是在K8S中，主节点一般被称为Master Node或者Head Node或Master Node，而从节点则被称为Worker Node或者Node。Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node
Master Node
- ETCD:K8S的存储服务。ETCD保存了集群中Master Node和Worker Node中各个组件的状态，同时也存储了K8S的关键配置和用户配置，k8s架构所有需要持久化的数据都会存储在ETCD中。K8S中仅API Server才具备读写权限，其他组件必须通过API Server的接口才能读写数据;
- Controller Manager：Worker Node的监控器，Controller Manager有很多不同类型的Controller，主要负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- Scheduler：负责资源的调度，按照预定的调度策略将 Pod 调度到相应的Node节点上；
- API Server:API Server负责接收K8S所有请求,是k8s资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制。API Server根据的具体请求，去通知其他组件干活。
Worker Node
- Kubelet。Worker Node的监视器。每个节点上都运行一个 kubelet 服务进程，默认监听 10250 端口，接收并执行 master 发来的指令，管理 Pod 及 Pod 中的容器。每个 kubelet 进程会在 API Server 上注册节点自身信息，定期向 master 节点汇报节点的资源使用情况，并监控节点和容器的资源，维护node节点上Pod的生命周期。
- Kube-Proxy：K8S的网络代理。Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。
- Container Runtime：Worker Node的运行环境。容器运行时（Container Runtime）是 Kubernetes 最重要的组件之一，负责真正管理镜像和容器的生命周期。Kubelet 通过 Container Runtime Interface (CRI) 与容器运行时交互，以管理镜像和容器。
其他组件：
kube-dns：负责为整个集群提供 DNS 服务
Ingress Controller：为服务提供外网入口
Heapster：提供资源监控
Dashboard：提供 GUI
Federation：提供跨可用区的集群
Fluentd-elasticsearch：提供集群日志采集、存储与查询
K8S重要概念
k8s架构由master和node组成，node可以运行一个或多个pod,pod可以运行一个或者多个容器，master通过deployment管理和控制Pod,Kubelet管理node的资源和Pod生命周期，定期向master汇报node的资源使用情况
-
Pod：Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。同一个Pod之间的Container可以通过localhost互相访问，并且可以挂载Pod内所有的数据卷；但是不同的Pod之间的Container不能用localhost访问，也不能挂载其他Pod的数据卷。每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中，每当启动一个pod的时候,pause容器也会随之启动
- Deployment：Deployment的作用是管理和控制Pod和ReplicaSet，管控它们运行在用户期望的状态中，确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某Pod不行了，就从其他的node上启动一个新的pod替换掉。
-
ReplicaSet ：ReplicaSet 的目的是维护一组Pod在任何时候都处于稳定运行的状态。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。ReplicaSet受控制于Deployment
- Service：Service屏蔽了服务细节，统一对外暴露服务接口。举个例子，我们的一个服务A，部署了3个备份，也就是3个Pod；对于用户来说，只需要关注一个Service的入口就可以，而不需要操心究竟应该请求哪一个Pod。一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S重新拉起Pod而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化，另一方面，Service还可以做流量负载均衡。
-
Ingress：Ingress是整个K8S集群的接入层，负责集群内外通讯，类似springcloud的zuul网关的作用
-
Label：Label是为使Deployment识别调度范围内的Pod是哪些，从而使service知道给哪些Pod进行负载均衡。比如我有2个业务A和B，通过标签，DeploymentA和DeploymentB可以识别调度的Pod在哪里，Label不仅可以贴到pod上，它还可以贴到任何的资源上，例如：Namespace和node都可以贴标签
- Namespace:在一个Kubernetes集群中可以使用namespace创建多个“虚拟集群”，这些namespace之间可以完全隔离,资源名称在同一个命名空间内需保持唯一，但是两个不同的命名空间可以包含同名的资源。例如service访问pod时，如果service的命名空间不指定正确，那么就无法通过标签关联到pod。但是可以通过某种方式，让一个namespace中的service可以访问到其他的namespace中的pod。也就是说命名空间不会隔离不同空间下的Pod 之间的网络通讯，除非针对命名空间加了相应的安全策略。
通过实例理解概念：
参考：https://zhuanlan.zhihu.com/p/265997618
以搭建Nginx为例：
创建命名空间
vim nginx-namespace.yaml
apiVersion: v1 #类型为Namespace
kind: Namespace #类型为Namespace
metadata:
name: ns-test #命名空间名称
#创建
kubectl create -f nginx-namespace.yaml
#查询
kubectl get namespace
在Namespace下创建资源,通过controller来创建pod。deployment为其中一种controller
deployment创建pod
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: ns-test
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
#创建
kubectl create -f nginx-deployment.yaml
#查询
kubectl get deployment
#或
kubectl get pods -n ns-test
创建service
使用随机生产ip:
vim nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
kubectl create -f nginx-service.yaml
//查看生成的ip
kubectl get svc nginx-service -o wide
创建service
使用本机ip:
vim nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
type: NodePort
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 8000
kubectl create -f nginx-service.yaml
