k8s:kubernetes:8个字母省略，就是k8s。

自动部署，自动扩展和管理容器化部署的应用程序的一个开源系统。k8s是负责自动化运维管理多个容器化程序的集群，是一个功能强大的容器编排工具。分布式和集群化的方式进行容器管理。

1.15 1.18 1.20 1.28 几个版本 常用1.20.

 官网：
https://kubernetes.io

GitHub：
https://github.com/kubernetes/kubernetes

k8s是google的borg系统作为原型，后期经由go语言编写的开源软件。docker微服务，可以满足微服务使用，那么为什么还要使用k8s呢。

1、传统的部署方式：一般意义上的二进制部署，安装-运行-运行维护，需要专业的人员，如果出了故障还需要人工重新拉起来。而且如果业务量增大，只能水平的拓展，再部署一个。

2、容器化，可以用dockerfile编写好自定义的容器，随时基于镜像都可以运行。数量少，可以管理，数量一旦太多，管理起来太复杂。而且，docker一般是单机运行，没有高可用。

k8s的作用：

简单，高效的部署容器化的应用。

1、解决了docker的单机部署和无法集群化的特点

2、解决了随着容器数量的增加，对应增加的管理成本。

3、容器的高可用，提供了一种容器的自愈机制。

4、解决了容器没有预设模版，以及无法快速，大规模部署以及大规模的容器调度。

5、提供了集中化配置管理的中心。

6、解决了容器的生命周期的管理工具。

7、提供了图形化工具，可以用图形化工具对容器进行管理。

k8s是基于开源的容器集群管理系统，在docker容器技术的基础之上。为容器化的集群提供部署，运行，资源调度，服务发现，动态伸缩等一系列完整的功能

大规模容器管理：

1、对docker等容器技术从应用的包--部署-…-运行---停止---销毁，全生命周期管理

2、集群方式运行，跨机器的容器管理

3、解决docker的跨机器运行的网络问题

4、k8s可以自动修复，使得整个容器集群可以在用户期待的状态下运行。

5    k8s集群内的各个组件都是要进行密钥对验证的。但是k8s的安全性不够，核心的组件不建议部署，自定义应用。
6、存储编排
（1）可以自动化的把容器部署在节点上。
（2）可以通过命令行或者yml文件（自定义pod)实现指定节点部署
（3）可以通过网络存储，NFS gfs
7、任务进行批次处理。提供一次性的任务，定时任务，满足需要批量处理和分析的场景。

k8s的master核心组件：

1、kube-apisrver:

   k8s集群之中每个组件都是要靠密钥队来进行验证，组件之间的通信通过apiserver提供的接口进行。以 HTTP Restful API 提供接口服务。API是应用接口服务，k8s的所有资源请求和调用操作都是kube-apiserver来完整。
   所有对象资源的增，删，改，查和监听的操作都是kube-apiserver处理完之后交给etcd来进行。
api-servr是k8s所有请求的入口服务，api-server接收k8s的所有请求（命令行和图形化界面），然后根据用户的具体请求，通知对应的组件展示或者运行命令。
   APlserver相当于整个集群的大脑。

2、kube-controller-manager：

运行管理控制器。是k8s集群中处理常规任务的后台线程。是集群中所有资源对象的自动化控制中心。一个资源对应一个控制器，controller-manager负责管理这些控制器。
（1）node controller(节点控制器)：负责节点的发现以及节点故障时的发现和响应。

（2）replication controller（副本控制器）：控制关联pod的副本数。可以随时扩缩容。

（3）Endpoints controller(端点控制器)，监听service和对应pod的副本变化。端点就是服务暴露出的访问点。要访问这个服务，必须要知道他的Endpoints。就是内部每个服务的ip地址+端口

（4）service account和roken controllers(服务账户和令牌控制）为命名空间创建默认账户和API访问令牌。namespace,访问不同的命令空间。
（5）resourcequota controller（资源控制器）：可以对命名空间的资源使用进行控制，也可以对pod的资源的进行控制。
（6）namespace controller（命名空间的控制器），管理命名空间的生命周期。
（7）service controller(服务节点控制器)：k8s集群和外部的主机之间的接口控制器。

3、kube-scheduler:

资源调度组件，根据调度算法为新创建的pod选择一个合适的node节点。可以理解为k8s的所有node节点的调度器，部署和调度node。
预先策略：人工定制，指定的node节点上部署
优先策略：限制条件，根据调度算法选择一个合适的node，node的节点的资源情况，node的资源控制的情况等等，选一个资源最富裕，负载最小的node来部署。

ETCD：

k8s的存储服务，etcd分布式键值存储系统（key:value），k8s的关键配置和用户配置，先通过APlsever调用etcd当中的存储信息，然后再实施。（这个集群当中，能对etcd存储进行读写权限的，只有APl-server.）
 

k8s的node组件：

1、kubelet:

node节点的监视器，以及于MASTER节点的通讯器，也可以理解为master在node节点上的眼线。kubelet会定时向APl server汇报自己的node上的运行服务的状态，Apl-server会把节点状态保存ETCD存储当中。接受来自master节点的调度命令。
如果发现自己的状态和matser节点的状态不一致，调用docker的接口，同步数据。
对节点上容器的生命周期进行管理，保证节点上的镜像不会占满磁盘空间，退出的容器的资源，进行回收。

 总之，在 Kubernetes 集群中，在每个 Node（又称 Worker Node）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。
 

2、 kube-porxy:

在每个 Node 节点上实现 Pod 网络代理，是 Kubernetes Service 资源的载体，负责维护网络规则和四层负载均衡工作。 负责写入规则至iptables、ipvs实现服务映射访问的。

Kube-Proxy 本身不是直接给 Pod 提供网络，Pod 的网络是由 Kubelet 提供的，Kube-Proxy 实际上维护的是虚拟的 Pod 集群网络。
Kube-apiserver 通过监控 Kube-Proxy 进行对 Kubernetes Service 的更新和端点的维护。

在 K8S 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个 Kube-proxy 组件。

3、docker：

容器引擎，运行容器，负责本机的容器创键和管理。
k8s要创建pod时，kube-scheduler调度到节点上（node节点），节点上的kubelet指示docker启动特定的容器。
kubelet把容器的信息收集，发送给主节点。主需要在主节点发布指令，节点上kubelet就会指示docker拉取镜像，启动或者停止容器。

不同点仅仅在于这是由自动化系统控制而非管理员在每个节点上手动操作的。 

K8s 核心概念

pod的理解运用 与创建过程

pod 运行在节点上的。是k8s当中创建或者部署的最小/最简单的基本单位，一个pod代表集群上正在运行的一个进程。pod是由一个或者多个容器组成，pod中的容器共享网络，存储和计算资源。可以部署在不同的docker主机上。
一个pod里面可以运行多个容器，也可以是一个容器。在生产环境中，一般都是单个容器或者具有关联关系的多个容器组成一个pod.

K8S创建Pod的工作流程
（1）用户通过客户端发送创建pod的请求到master节点上的apiserver

 （2）apiserver会先把相关的请求信息写入到etcd中，再找controller-manager

          根据预设的资源模板创建pod清单

（3）然后controller-manager会通过apiserver去找scheduler

          为新创建的pod选择最适合的Node节点

（4）scheduler会通过调度算法的预选策略和优选策略筛选出最适合的Node节点

（5）然后再通过apiserver找到对应的Node节点上的kubelet去创建和管理pod

（6）kubelet会直接跟容器引擎交互来管理容器的生命周期

（7）用户通过创建承载在kube-proxy上的service资源，写入相关的网络规则，

           实现对pod的服务发现和负载均衡

Pod 控制器    

    1.deployment:无状态应用部署，作用就是管理和控制pod,以及replicaset(运行几个容器)。管控他的运行状态
    2.replicaset:保证pod的副本数量，受控于deployment。
    在k8s中,部署服务,实际上就是pod,deployment部署的服务就是pod,rereplicaset的就是来定义pod的容器数量。可以保证pod的不可重复性。在当前命名空间不能重复。不同命名空间名称可以重复。
    官方推荐使用deployment进行服务部署。
    3.daemonset：确保所有节点运行同一类的pod。
    4.statefulset:有状态应用部署。

    5. job:可以在pod中设置一次性任务，运行完即退出。
    6.cronjob:一直在运行的周期性任务。

service:

在k8s集群当中，创建一个pod之后，都会其中运行的容器分配一个集群内的IP地址，由于业务的变更，容器可能会发生变化，ip地址也会发生变化，service的作用就是提供整个pod对外统一的ip地址。
service就是一个网关（路由器），通过访问service就可以访问pod内部的容器集群。
service能实现负载均衡和代理-- --kube-proxy-----来实现负载均衡
service是k8s微服务的核心，屏蔽了服务的细节，统一的对外暴露的端口，真正实现了“微服务”。

service的流量调度：userspace(用户空间，废弃），iptables(即将废弃）。jpvs（目前1.20都用ipvs)

label:

标签，k8s的特色管理方式，分类管理资源对象。
NODE pod service namespace
label标签可以用户自定义。

lable选择器：等于，不等于，使用定义的标签名。

ingress:k8s集群对外暴露提供访问的接口，属于应用层，七层代理，转发的是http请求，http/https。

service是四层转发，转发的是流量。

Ingress 

Service 主要负责 K8S 集群内部的网络拓扑，那么集群外部怎么访问集群内部呢？这个时候就需要 Ingress 了。Ingress 是整个 K8S 集群的接入层，负责集群内外通讯。
Ingress 是 K8S 集群里工作在 OSI 网络参考模型下，第7层的应用，对外暴露的接囗，典型的访问方式是 http/https。
Service 只能进行第四层的流量调度，表现形式是 ip+port。Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
流程大致：客户端请求 访问的域名 ---> Ingress（七层代理） ---> Service（四层代理） ---> Pod 

 

 Name 

由于 K8S 内部，使用 “资源” 来定义每一种逻辑概念（功能），所以每种 “资源”，都应该有自己的 “名称”。
“资源” 有 api 版本（apiversion）、类别（kind）、元数据（metadata）、定义清单（spec）、状态（status）等配置信息。
“名称” 通常定义在 “资源” 的 “元数据” 信息里。在同一个 namespace 空间中必须是唯一的。

Namespace 

随着项目增多、人员增加、集群规模的扩大，需要一种能够逻辑上隔离 K8S 内各种 “资源” 的方法，这就是 Namespace。
Namespace 是为了把一个 K8S 集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同 Namespace 内的 “资源” 名称可以相同，相同 Namespace 内的同种 “资源”，“名称” 不能相同。
合理的使用 K8S 的 Namespace，可以使得集群管理员能够更好的对交付到 K8S 里的服务进行分类管理和浏览。
K8S 里默认存在的 Namespace 有：default、kube-system、kube-public 等。
查询 K8S 里特定 “资源” 要带上相应的 Namespace。 

常见的K8S部署方式

●Minikube
Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。
部署地址：https://kubernetes.io/docs/setup/minikube

●Kubeadm
Kubeadm也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

●二进制安装部署
生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐。
https://github.com/kubernetes/kubernetes/releases
Kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署Kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护。 

k8s部署 二进制与高可用的区别

 ●二进制部署
部署难，管理方便，集群伸展性能好
更稳定，集群规模到达一定的规模(几百个节点、上万个Pod)，二进制稳定性是要高于kubeadm部署
遇到故障，宿主机起来了，进程也会起来

●kubeadm部署
部署简单，管理难
是以一种容器管理容器的方式允许的组件及服务，故障恢复时间比二进制慢
遇到故障，启动宿主机，再启动进程，最后去启动容器，集群才能恢复，速度比二进制慢