spec

一、Job （1）Job概述 Job负责处理短暂的一次性任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。 Kubernetes支持以下几种Job： 非并行Job： 通常创建一个Pod直到其成功结束； 固定结束次数的Job： 在spec字段下添加completions字段。创建多个Pod，直到满足completions规定的数值。如果不添加的话，默认情况下是1个； 带有工作队列的并行Job： 在spec字段下添加Parallelism字段。表示几个job同时并行工作。如果不添加的话，默认情况下是1个； 根据可以设置completions字段、Parallelism字段，可以将Job分为以下几种： （2）Job Controller Job Controller负责根据Job yaml文件中Spec字段定义的内容创建Pod，并持续监控Job的状态，直至其成功结束。如果失败，则根据restartPolicy（只支持OnFailure和Never，不支持Always）决定是否创建新的pod再次重试任务。 如图： （3）应用示例 一个简单的小示例： [root@master job]# cat job.yaml kind: Job apiVersion: batch/v1 metadata: name: test-job spec: template: metadata

一 Deployment相对于RC的优势 RS与Deployment主要用于替代RC。RS的全称为Replica Set。相对于RC，RS与Deployment的优势如下： RC只支持基于等式的selector，如env=dev或者environment!=qa。但在RS中，还支持新的基于集合的selector，如version in (v1.0,v2.0)或者env not in (dev,qa)。这给复杂的运维管理带来方便 使用Deployment升级Pod只需要定义Pod的最终状态，k8s会为你执行必要的操作。虽然使用kubectl rolling-update也可以完成滚动升级，但它是在客户端与服务端多次交互控制RC完成的，所以REST API中并没有rolling-update的接口，这为定制自己的管理系统带来了一些麻烦。Deployment拥有更加灵活的升级、回滚功能。 Replica Set目前与RC的区别只是支持的selector不同，后续会加入更多的功能。Deployment使用了Replica Set，是更高一层的概念。除非需要自定义升级功能或者根本不需要升级Pod，否则还是建议使用Deployment而不直接使用Replica Set。 二 Deployment是简单使用 2.1 同时安装三个nginx pod [root@docker-server1

环境介绍 主机 IP地址 服务 master 192.168.1.21 k8s+httpd+nginx node01 192.168.1.22 k8s node02 192.168.1.23 k8s 基于[ https://blog.51cto.com/14320361/2464655 ]() 的实验继续进行 一、Pod的liveness和readiness探针 　　Kubelet使用liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去 　　Kubelet使用readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。 Probe支持以下三种检查方法： <1>exec-命令 在用户容器内执行一次命令，如果命令执行的退出码为0，则认为应用程序正常运行，其他任务应用程序运行不正常。 livenessProbe: exec: command: - cat - /home

Deployment介绍 Deployment是kubernetes 1.2引入的概念，用来解决Pod的编排问题。Deployment可以理解为RC的升级版（RC+Reolicat Set）。特点在于可以随时知道Pod的部署进度，即对Pod的创建、调度、绑定节点、启动容器完整过程的进度展示。 使用场景 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。 检查Deployment的状态来确认部署动作是否完成（Pod副本的数量是否达到预期值）。 更新Deployment以创建新的Pod(例如镜像升级的场景)。 如果当前Deployment不稳定，回退到上一个Deployment版本。 挂起或恢复一个Deployment。 Service介绍 Service定义了一个服务的访问入口地址，前端应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端的Pod副本集群之间是通过Label Selector来实现“无缝对接”。RC保证Service的Pod副本实例数目保持预期水平。 外部系统访问Service的问题 IP类型 说明 Node IP Node节点的IP地址 Pod IP Pod的IP地址 Cluster IP Service的IP地址 环境介绍 主机 IP地址 服务 master 192.168.1.21

一，两种创建资源的方法 1. 基于命令的方式： 简单直观快捷，上手快。 适合临时测试或实验。 2. 基于配置清单的方式： 配置文件描述了 What ，即应用最终要达到的状态。 配置文件提供了创建资源的模板，能够重复部署。 可以像管理代码一样管理部署。 适合正式的、跨环境的、规模化部署。 这种方式要求熟悉配置文件的语法，有一定难度。 环境介绍 主机 IP地址 服务 master 192.168.1.21 k8s node01 192.168.1.22 k8s node02 192.168.1.23 k8s 二. 配置清单（yam，yaml） 在k8s中，一般使用yaml格式的文件来创建符合我们预期期望的pod，这样的yaml文件我们一般称为资源清单 /etc/kubernetes/manifests/ k8s存放（yam、yaml）文件的地方 **kubectl explain deployment（通过explain参数加上资源类别就能看到该资源应该怎么定义） kubectl explain deployment.metadata 通过资源类别加上带有Object标记的字段，我们就可以看到一级字段下二级字段的内容有那些怎么去定义等 kubectl explain deployment.metadata.ownerReferences 通过加上不同级别的字段名称来看下字段下的内容

注：本文使用的Traefik为1.x的版本 在生产环境中，我们常常需要控制来自互联网的外部进入集群中，而这恰巧是Ingress的职责。 Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务。这与Ingress控制如何将外部流量路由到集群有异曲同工之妙。接下来，我们举一个实际的例子来更清楚的说明Ingress的概念。 首先，想象一下在你的Kubernetes集群中有若干个微服务（小型应用程序之间彼此通信）。这些服务能够在集群内部被访问，但我们想让我们的用户从集群外部也能够访问它们。因此，我们需要做的是使用反向代理将每个HTTP（S）（例如， service.yourdomain.com ）路由与相应的后端关联，并在该服务的不同实例之间（如，pod）进行负载均衡。与此同时，由于Kubernetes的性质会不断发生变化，因此我们希望跟踪服务后端的更改，以便能够在添加或删除新Pod时将这些HTTP路由重新关联到新Pod实例。 使用Ingress资源和关联的Ingress Controller，你可以实现以下目标： 将你的域 app.domain.com 指向你的私有网络中的微服务应用程序 将路径 domain.com/web 指向你的私有网络中的微服务web 将你的域 backend.domain.com 指向你的私有网络中的微服务后端

适用环境： 数据库版本：MySQL 5.7.26 操作系统：CentOS 7 制作思路： 将数据库初始化和配置工作放到安装脚本中方便定制： 1、打包MySQL应用目录 2、不自动生成配置文件 3、不自动生成数据目录 4、不自动初始化数据 Spec代码： # ========================================= # # MySQL参数配置 # mysql源码路径 # 源码包版本 %global src_base mysql %global version 5.7.26 %global src_dir %{src_base}-%{version} %global cmake_bin /home/rpmbuilder/cmake-3.16.2-Linux-x86_64/bin/cmake Name: %{src_base} Version: %{version} # 安装版本 Release: 1 # 安装包介绍 Summary: MySQL Server # 遵循协议 License: GPLv2 # 打包需要 # BuildRequires: cmake /sbin/useradd /sbin/groupadd /bin/bash /bin/sh /bin/chown # 安装需要 # Requires: ncurses ncurses-devel

适用环境： 数据库版本：MySQL 5.7.26 操作系统：CentOS 7 制作思路： 将数据库初始化和配置工作放到安装脚本中方便定制： 1、打包MySQL应用目录 2、不自动生成配置文件 3、不自动生成数据目录 4、不自动初始化数据 Spec代码： # ========================================= # # MySQL参数配置 # mysql源码路径 # 源码包版本 %global src_base mysql %global version 5.7.26 %global src_dir %{src_base}-%{version} %global cmake_bin /home/rpmbuilder/cmake-3.16.2-Linux-x86_64/bin/cmake Name: %{src_base} Version: %{version} # 安装版本 Release: 1 # 安装包介绍 Summary: MySQL Server # 遵循协议 License: GPLv2 # 打包需要 # BuildRequires: cmake /sbin/useradd /sbin/groupadd /bin/bash /bin/sh /bin/chown # 安装需要 # Requires: ncurses ncurses-devel

Label（标签） 我们为什么要使用label呢？ 当相同类型的资源对象越来越多，为了更好的管理，才按照标签分为一个小组，为的是提升资源的管理效率。 lable是附着到object上（例如pod）的键值对。可以在创建object的时候指定，也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义，只是对用户才有意义。 "labels": { "key1" : "value1", "key2" : "value2" } 语法和字符集 Label key的组成： * 不得超过63个字符 * 可以使用前缀，使用/分隔，前缀必须是DNS子域，不得超过253个字符，系统中的自动化组件创建的label必须指定前缀，kubernetes.io/ 由kubernetes保留。 * 起始必须是字母（大小写都可以）或数字，中间可以有连字符，下划线和点。 Label value的组成: 不得超过63个字符 起始必须是字母（大小写都可以）或数字，中间可以有连字符，下划线和点。 常用的，多维度标签分类： 版本标签（release）： stable（稳定版），canary（金丝雀版本），beta（测试版） 环境类（environment）： dev（开发），qa（测试），production（生产），op（运维） 应用类（applaction）： ui（设计），as（应用软件），pc

index.html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=gb2312" /> <title></title> <link href="css/css.css" type="text/css" rel="stylesheet"> <SCRIPT src="js/jquery1.42.min.js" type=text/javascript></SCRIPT> <SCRIPT src="js/index.js" type=text/javascript></SCRIPT> </head> <body style="text-align:center"> <div id="product"> <div class="proobj" id="spec-n1"><img src="images/img04.jpg" height=350 width=350> <