自动化集成（Kubernetes容器引擎详解）自动化集成：Kubernetes容器引擎

同系列推荐：

Jenkins管理工具详解
Pipeline流水语法详解
Docker容器入门简介
Pipeline整合Docker容器
微服务组件二次浅封装

前言：该系列文章，围绕持续集成：Jenkins+Docker+K8S相关组件，实现自动化管理源码编译、打包、镜像构建、部署等操作；本篇文章主要描述Kubernetes引擎用法。

文章图片

一、基础简介 Kubernetes简称K8S，是一个开源的分布式的容器编排引擎，用来对容器化应用进行自动化部署和管理。

文章图片

Control-Plane-Components：控制平面组件，对集群做出全局决策，例如：调度、检测和事件响应，可以在集群中的任何节点上运行；

api：作为K8S控制面的组件，开放K8S的API，相当于控制面的前端；
etcd：兼具一致性和高可用性的键值数据库，作为保存K8S数据的后台库;
scheduler：监听新建未指定运行节点的Pods，并为Pod选择运行节点；
controllermanager：运行控制器进程，逻辑上是一个单独的进程；

Node：节点组件：每个节点上运行，维护运行的Pod并提供Kubernetes运行环境；

kubelet：在每个节点上运行的代理，保证容器都运行在Pod中；
kube-proxy：每个节点上运行的网络代理，维护节点上的网络规则；

Container-Runtime：容器运行时，负责运行容器的软件，支持Docker、containerd、CRI-O等多个容器运行环境，以及任何实现Kubernetes-CRI容器运行环境接口。
二、环境配置 1、服务搭建使用Git拉取k8s-docker-desktop-for-mac仓库，执行load_images.sh脚本，会拉取本地docker对应的k8s版本，注意这里要等到脚本流程执行完毕，可能因为Git连接的问题，耗时较长，下面是脚本拉取的镜像：

docker images REPOSITORYTAG docker/desktop-kuberneteskubernetes-v1.21.5-cni-v0.8.5-critools-v1.17.0-debian k8s.gcr.io/kube-apiserverv1.21.5 k8s.gcr.io/kube-proxyv1.21.5 k8s.gcr.io/kube-controller-managerv1.21.5 k8s.gcr.io/kube-schedulerv1.21.5 docker/desktop-kit-controllerv2.0 docker/desktop-storage-provisionerv2.0 k8s.gcr.io/pause3.4.1 k8s.gcr.io/coredns/corednsv1.8.0 k8s.gcr.io/etcd3.4.13-0

上述镜像下载完成后，通过docker桌面软件启动k8s即可，这里启动时间相对偏长，启动成功之后界面左下角K8S显示绿色状态：

文章图片

2、环境查看

# 查看版本：kubectl version Client Version GitVersion:v1.21.5 Server Version GitVersion:v1.21.5# 查看集群：kubectl cluster-info Kubernetes control plane is running at local-host:6443# 查看节点：kubectl get nodes NAMESTATUSROLESAGEVERSION docker-desktopReadycontrol-plane,master23hv1.21.5

三、部署Docker镜像 1、核心组件在执行Docker镜像部署之前，首先要理解该流程中几个核心的概念：

Pod：是可以在Kubernetes中创建和管理的、最小的可部署的计算单元；就Docker概念的术语而言，Pod类似于共享命名空间和文件系统卷的一组Docker容器；
ReplicaSet：目的是维护一组在任何时候都处于运行状态的Pod副本的稳定集合；通常用来保证一定数量的、完全相同的Pod的可用性；
Deployment：为Pods和ReplicaSets提供声明式的更新能力，可以定义Deployment以创建新的ReplicaSet，或删除现有Deployment；
Service：抽象的方式将运行在一组Pods上的应用程序公开为网络服务，在K8S中逻辑上Pods集合与访问策略，这种模式被称为微服务；

2、脚本文件这里将Deployment与Service放在一个.yaml文件中；镜像加载设置imagePullPolicy:Never即本地读取；其中服务发现采用的是NodePort类型，并没有设置具体端口，控制平面会在默认范围内分配一个端口号；

文章图片

--- apiVersion: apps/v1 kind: Deployment metadata: name: cloud-app-deployment labels: app: cloud-app spec: selector: matchLabels: app: cloud-app template: metadata: labels: app: cloud-app spec: containers: - name: cloud-app image: Cloud_Url/cicada-image/cloud-app imagePullPolicy: Never ports: - containerPort: 8079 --- apiVersion: v1 kind: Service metadata: name: cloud-app-service labels: app: cloud-app spec: type: NodePort ports: - port: 8080 targetPort: 8079 selector: app: cloud-app

3、资源管理创建资源

kubectl create -f pod.yaml

查看资源

# 1、查看Pod信息 kubectl get pods -o wide# 2、查看Service信息 kubectl get svc -o wide# 3、查看Node信息 kubectl get nodes -o wide

也可以在K8S的Web控制台上，查看资源的可视化界面，下面截图几个脚本中明确声明的资源信息：

文章图片

删除资源

# 1、通过文件删除 kubectl delete -f pod.yaml# 2、通过具体资源名删除 kubectl delete pod cloud-app

4、访问资源

# 查看服务的详细描述 kubectl describe svc cloud-app-service Name:cloud-app-service NodePort:30930/TCP Endpoints:Pod_IP:Pod_端口

这里NodePort端口默认分配30930，当外部访问流量到达Service时，会路由到指定Endpoints（端点），通过上面的资源查看可知，这里Endpoints即Pod的IP与端口；
通过：本机IP:分配端口/API方式，即localhost:30930/client访问到docker容器中应用，也可以在Web界面的Pod模块查看具体的日志输出：