这些概念到底有什么区别？
apisix 和 apisix-ingress-controller: apisix是一套体系，apisix-ingress-controller是k8s环境下基于go语言开发的一套自定义CRD，他负责响应apisix自定义资源的创建，监听k8s服务资源的创建变更，同步到apisix网关，apisix网关本身由openresty、nginx组成，主要是由Lua语言在nginx执行的各个阶段插入钩子，实现动态化，且基于etcd+灵活的插件机制，让变更更灵活且立即生效；
nginx-ingress和apisix-ingress-controller： nginx-ingress是k8s体系中目前使用最广的路由网关，比如阿里默认的控制台ingress创建就是使用的它；他集合了nginx+nginx-ingress-controller，拉代码可以看出，nginx-ingress-controller完成了与k8sapiserver交互，获取最新的服务配置变更，生成最新nginx配置，除此之外的通讯机制是通过>
Job控制器用于Pod对象运行一次性任务，容器中的进程在正常运行结束后不会对其进行重启，而是将Pod对象置于"Completed"(完成)状态，若容器中的进程因错误而终止，则需要按照重启策略配置确定是否重启，未运行完成的Pod对象因其所在的节点故障而意外终止后会被调度。
Job控制器的Pod对象的状态转换如下图所示：
有的作业可能需要运行不止一次，用户可以配置它们以串行或者并行的方式运行。
Job控制器的spec字段内嵌的必要字段只有 template ，不需要定义标签选择器，控制器会自动关联，除了这一点与Deployment控制器不同，其它别无二致。
1创建Job控制器配置清单
使用busybox镜像，然后沉睡120s，完成后即正常退出容器
2创建Job控制器
3查看Job控制器及Pod状态
120s后，Job控制器创建的Pod对象完成了任务
查看Job控制器的详细信息
如下 Selector 与 Lables 都是Job控制器自动生成后自动关联，控制器自动生成的 controller-uid-随机字符串 ，控制器携带了后面的字符串是为了防止所管理的Pod发生重合。
下面可以看到Job运行成功后及完成了 *** 作并没有进程重启，这得助于我们设置的 restartPolicy 。
将并行度属性 jobspecparallelism 的值设置为1，并设置总任务数 jobspeccompletions 属性便能够让Job控制器以串行方式运行多任务，下面是一个需要串行5此任务的Job控制器示例：
创建Job控制器
动态监控Pod对象作业的变化
如上，Job控制器需要执行五次任务，每次一个Pod执行一个任务，依次执行，执行成功后的Pod即为完成状态
并行式Job我们只需要修改 jobspecparallelism 属性与 jobspeccompletions 属性即可；
jobspecparallelism 属性表示了每次启动多少队列执行作业(即为Pod数量)
jobspeccompletions 属性表示了作业的总数量
如下示例一个5个作业，同时启动5个队列进行作业。
查看Job控制器运行状态，如下Job控制器中的Pod对象创建时间是一致的。
Job控制器中的Pod运行完成后，将不再占用系统资源，用户可以按照需求保留或使用资源删除命令将Pod删除，不过如果某控制器的容器应用总是无法正常结束运行，而其 restartPolicy 又设置为了重启，则它可能会一直处于不停地重启和错误的循环当中。所幸的是，Job控制器提供了两个属性用于抑制这种情况的发生，具体如下：
例如，下面的配置清单为，表示其失败重试次数为5此，并且如果超出100秒的时间仍然未运行完成，那么则将其终止：
1 什么是kubernetes
Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
2 kubernetes核心组件说明
Kubernetes 集群中主要存在两种类型的节点，分别是 master 节点 ，以及 minion 节点 。
Minion 节点是实际运行 Docker 容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。
Master 节点负责对外提供一系列管理集群的 API 接口，并且通过和 Minion 节点交互来实现对集群的 *** 作管理。
apiserver ：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查 *** 作，提供了 RESTFul 风格的 API 接口，通过 etcd 来实现持久化并维护对象的一致性。
scheduler ：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheduler 通过一定的调度算法从而找到最合适的节点。
controller-manager ：主要是用于保证 replicationController 定义的复制数量和实际运行的 pod 数量一致，另外还保证了从 service 到 pod 的映射关系总是最新的。
kubelet ：运行在 minion 节点，负责和节点上的 Docker 交互，例如启停容器，监控运行状态等。
proxy ：运行在 minion 节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。
etcd ：key-value键值存储数据库，用来存储kubernetes的信息的。
flannel ：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。
我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。
Flannel 的目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。
3 Kubernetes的核心概念
Pod
运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。
Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。
Replication Controller
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。
集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。
Replication Controller是实现d性伸缩、动态扩容和滚动升级的核心。
Service
Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。
Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。
Label
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
Node
Node是Kubernetes集群架构中运行Pod的服务节点（或agent）。
Node是Kubernetes集群 *** 作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。
4 前置条件设置
三台Centos7系统的虚拟机（1个master+2个node）,三台机器上的防火墙，SELINUX全部关掉。我的实验坏境可以上网，默认的YUM源就可以用。
5 部署规划
192168101 # master节点(etcd,kubernetes-master)
192168102 # node1节点(etcd,kubernetes-node,docker,flannel)
192168103 # node2节点(etcd,kubernetes-node,docker,flannel)
6 开始安装
step1：在master上安装
yum install kubernetes-master etcd flannel -y
step2：在node上安装
yum install kubernetes-node etcd flannel -y
step3：etcd集群配置
在master节点上编辑etcd配置文件
在node1节点上编辑etcd配置文件
在node2节点上编辑etcd配置文件
到此etcd集群就部署完了，然后每个节点上启动
systemctl start etcd
step4：验证
step6：启动Master上的三个服务
step7：kubernetes node安装
node2 节点重复上述 *** 作
step8：分别启动kubernetes node服务
7 网络配置
因为kubernetes集群中网络部分是插件形式安装的，我们这里选用flannel
上述安装步骤已经install 了
为flannel创建分配的网络
8 执行kubectl 命令检查
在master上执行下面，检查kubernetes的状态
9 常用排错命令如下
当使用 Node 在生产环境作为服务器语言时，并发量过大或者代码问题造成 OOM (out of memory) 或者 CPU 满载这些都是服务器中常见的问题，此时通过监控 CPU 及内存，再结合日志及 Release 就很容易发现问题。第一点，已经在编排文件中限制资源最大使用量为4G，理论上Pod中容器是不可能占用这么多资源， 默认情况下Java占用物理资源的1/4左右， 但是既然出现了这个问题，说明Java进程占用资源超过了这个限制。
当某个node节点宕机，其上面的工作负载会被master自动转移到其他的节点上。
通过kubeadmin安装K8S集群可以做到快速部署，但是如果需要调整K8S各个组件及服务的安全配置，高可用模式，最好通过二进制模式进行K8S的安装
生产环境K8S Master节点最好在3个节点以上，且配置不低于4核16g
生产环境：确保Master高可用，启用安全访问机制
PS：
服务器节点只是起名字，与是否为k8s-master或k8s-node无关，可根据需要增加或删减测试用例的数量，如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192168100100
node1 192168100101
node2 192168100102
注：本节中创建的证书为部署流程全过程证书，测试用例为openssl生成证书，cfssl生成证书需要参考cfssl生成k8s证书，并在对应配置文件的相关证书位置替换对应证书
在配置文件中需要在[alt_names]设置Master服务的全部域名和IP地址，包括：
参数解析
配置文件详解：
分发配置文件
配置文件详解：
配置详解
分发配置文件
分发配置文件
在三个kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虚拟IP地址）192168100200作为Master的唯一入口地址，供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。
接下来在主机master（192168100100）和主机node1（192168100101）中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP的高可用
准备 HAProxy 的配置文件 haproxycfg
参数说明：
分发配置文件
在master（192168100100）和node1（192168100101）上使用docker部署HAProxy，并将配置文件挂载到容器的/usr/local/etc/haproxy下
访问192168100100:8888/stats，192168100101:8888/stats
keepalived用于维护VIP地址的高可用，同样在master和node1中部署
主节点配置文件
子节点配置文件
参数解析
主节点和子节点配置异同
健康检查脚本
keeplived需要持续监控HAProxy的运行状态，在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本，定期运行监控
脚本内容如下：
分发脚本
在master（192168100100）和node1（192168100101）上使用docker部署keeplived，并将配置文件挂载到容器的/container/service/keepalived/assets下，将脚本挂载到容器的/usr/bin下
检查ens33网卡是否存在keeplived VIP地址
检测keeplived是否进行转发
注：master集群已经配置完毕，后续需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，还需要部署CNI网络插件、DNS插件等
之前已经在master，node1，node2中部署了docker，接下来需要部署其他服务组件，本节部署kubelet组件
参数说明
参数说明
参数说明
当前显示所有node为NOT READY，需要部署完网络插件才可使用
为方便使用kubectl
在应用的整个生命周期里，开发和运维都和它密不可分。一个塑造它，一个保养它。
如果应用需要部署到K8S中，开发和运维在其中都做了什么呢？
从开发侧来说，我们的应用应该具备以下能力：
健康 检测接口用于检测应用的 健康 状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。
如果我们应用未定义好相应的 健康 检测接口，K8S就无法判断应用是否正常可用，整个应用对我们来说就是黑匣子，也就谈不上应用稳定性了。
定义一个简单的 健康 检测接口如下：
如上我们定义了 health 接口，当应用启动后，只需要探测这个接口，如果返回OK，表示应用是正常的。
当然，上面的接口是非常简单的，在实际情况下，应用本身也许还依赖起来应用，比如redis，mysql，mq等，如果它们异常，应用是不是异常的呢？那我们的应用 健康 检测需不需要检测其他应用的 健康 状态呢？
既然我们定义好了 健康 检测接口，那我们的YAML模板就可以增加 健康 检测功能，如下：
应用发版是常规不能再常规的 *** 作，通常情况下都是滚动更新的方式上线，也就是先起一个新应用，再删一个老应用。
如果这时候老应用有部分的流量，突然把老应用的进程杀了，这部分流量就无法得到正确的处理，部分用户也会因此受到影响。
怎么才会不受影响呢？
假如我们在停止应用之前先告诉网关或者注册中心，等对方把我们应用摘除后再下线，这样就不会有任何流量受到影响了。
在K8S中，当我们要删除Pod的时候，Pod会变成Terminating状态，kubelet看到Pod的状态如果为Terminating，就会开始执行关闭Pod的流程，给Pod发SIGTERM信号，如果达到宽限期Pod还未结束就给Pod发SIGKILL信号，从Endpoints中摘除Pod等。
从上面可知，Pod在停止之前会收到SIG信号，如果应用本身没有处理这些信号的能力，那应用如果知道什么时候该结束呢？
下面简单定义一个处理SIG信号的功能。
当接收到SIG信号的时候，就会调用 Shutdown 方法做应用退出处理。
除此，还要结合K8S的 PreStop Hook 来定义结束前的钩子，如下：
如果使用注册中心，比如nacos，我们可以在 PreStop Hook 中先告诉nacos要下线，如下：
Metrics主要用来暴露应用指标，可以根据实际情况自定义指标，以便于监控工具Prometheus进行数据收集展示。
有些语言有现成的exporter，比如java的jmx_exporter，没有的就需要自己在应用中集成。
比如：
这种会暴露默认的>我们通常可以基于top命令来查看节点上的资源使用情况，可以带两个参数nodes和pods通过这个命令，分别用于查看节点和pods的资源使用情况，这对于我们快速查看k8s集群以及pod的资源利用率，从而提醒业务或者系统管理人员及时的对集群扩容，调整Pod的资源请求。
下面是这个命令显示的一个常规的输出：
但是这个命令新旧版本的实现上有差异，主要分水岭是从19X版本开始。
kubectl top命令依赖于heapster组件，我们用下面的内容创建heapsteryaml文件：
并运行kubectl apply -f heapsteryaml部署好heapster，就能通过旧版本的kubectl来执行top命令获取到资源利用率。
该版本的实现原理是，从heapster组件中读取收集的监控数据，由于heapster已经是淘汰的版本，这里不做深入的分析了。
新版本已经用metrics server替代了heapster，下面是K8S的监控架构图：
监控架构中包含了指标收集流以及监控流两个部分，这里我们主要讨论的是指标收集部分。
在这里我们有两个指标源：
Metrics Server负责从指标源中抓取数据，它不负责指标数据的持久化，只保留最近的数据（注意：kubectl top命令只用到了kubelet相关的核心指标），与此同时，Metrics Server会通过Aggregated API Servers模式把自己的API暴漏给API Server。
所以从客户端使用视角来看，访问Metrics Server就想访问API Server 一样，而kubectl就是这样的一种客户端，下面是Metrics Server暴漏的API信息：
我们可以通过下面的API来访问Metrics API：
>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）