pod

一、官方介绍 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment为Pod和Replica Set提供声明式更新。 你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。 注意：您不该手动管理由 Deployment 创建的 Replica Set，否则您就篡越了 Deployment controller 的职责！下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例，请直接在 Kubernetes 的代码库中提 issue。 二、Deployment可以帮我们做什么 定义一组Pod期望数量，Controller会维持Pod数量与期望数量一致 配置Pod的发布方式，controller会按照给定的策略更新Pod，保证更新过程中不可用Pod维持在限定数量范围内 如果发布有问题支持回滚 三、Deployment原理 控制器模型 在Kubernetes架构中，有一个叫做kube

写在前面 前面的系列文章已介绍kubernetes架构，安装，升级和快速入门，读者通过文章的实操已对kubernetes已有初步的认识和理解，从本章开始逐步介绍kubernetes中的基础概念概念和核心概念，基础概念包括：namespace，labels，annotations，pods，volumes等；核心概念包含kubernetes中各种controller，包含以下几种： 应用副本控制器有：Deployments，ReplicaSets，DaemonSets，StatefulSets； 批处理任务控制器Jobs和CronJob 存储控制器PersistentVoloume，PersistentVolumeClaim，StorageClass； 服务负载均衡Service，Ingress，NetworkPolicy和DNS名称解析； 配置和密钥ConfigMaps和Secrets 本文从最基础的概念pod开始讲解，后续逐步介绍应用部署，存储，负载均衡等相关的控制器，kubernetes内部由多个不同的控制器组成，每个控制器完成不同的功能。 1. 深入学习pod 1.1 Container介绍 容器是一种便携式，轻量级别的容器虚拟化技术，使用linux cggroup技术实现各种资源的隔离，如cpu，memory，pid，mount，IPC等，相比于虚拟化技术如KVM

一、持续交付工具链全图 上图源自网络。上图很清晰地列出了CD几个阶段使用的工具。 CD的工具链很长，但并不是每个模块所有工具都那么流行；换言之，我们在每个模块用好一种工具就足够了。 Build 在SCM的模块中：Git系列用的比较多，如Gitlab； 在CI模块中：Jenkins显然是最流行的； 在Build模块中：Maven、docker用的较多； Test 在Testing模块中：Junit、Jmeter用的较多； Deploy 在配置管理模块中：前些年Puppet比较火，这两年Ansible用的比较多；、 在Artifact管理中：Dockerhub是在线的，docker registry是离线的。Openshift的集成镜像仓库用的就是docker registry技术。Quay是CoreOS的镜像仓库工具，有在线也有离线的，相信后续会被整合到Openshift中。 Run 在Cloud/IaaS/PaaS模块中：这两年PaaS的活跃程度超过IaaS，我接触比较多的是其中的Openshift。 在编排模块中：K8S目前是主流，无可争议。 在BI/Monitoring/Logging中：EFK之前用的比较多，但大家普遍看好普罗米修斯。 二、红帽的Devops全图 上图是一个比较典型的Devops流程。包括产品立项、需求分析、应用设计、开发、测试、持续发布、生产运维、回顾阶段。

1.kubectl用法 $~: kubectl [command] [TYPE] [NAME] [flags] [command] 子命令。用于操作Kubernetes集群资源对象。 可取值：[create | delete | describe | get | apply] [TYPE] 资源对象的类型。区分大小写 备注：可以通过单数形式、复数形式、简写形式表示。 # 例：不同写法的Type,但是效果一致 kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 [NAME] 资源对象名称。区分大小写 备注： 如果不指定名称，将返回属于 TYPE 的所有对象列表。 # 例：返回所有对象列表 kubectl get pods [flags] kubectl子命令的可选参数 2.kubectl操作实例 创建资源对象 # 由配置文件(*.yaml)创建一次性对象 # 创建一个对象 kubectl create -f service.yaml # 创建对个对象 kubectl create -f service.yaml -f pod.yaml 查看资源对象 # 查看所有Pod列表 kubectl get pods # 查看指定对象 kubectl get service,pod 资源对象详情 # 显示Node的详细信息

前言 为了避免修改第三方库之后，使用pod install的时候 更新了库，采用参数 --verbose --no-repo-update ,只安装新添加的库 code #!/bin/sh #该命令只安装新添加的库，已更新的库忽略 pod install -- verbose -- no - repo - update #该命令只更新指定的库，其它库忽略 #pod update 库名 --verbose --no-repo-update exit 0 % 来源： CSDN 作者： u011018979 链接： https://blog.csdn.net/u011018979/article/details/103830017

由于github的私有库需要收费，因此我们使用码云(gitee)的私有库，免费。 1、创建WJSpec远程私有仓库，用来存放podspec文件。 1.1 在码云中创建私有项目： 1.2 添加你的私有Repo到你的CocoaPods pod repo add WJSpec https://gitee.com/winjayq/WJSpec.git 1.3 如果需要删除，则使用终端命令： pod repo remove WJSpec 2、创建WJCategory远程仓库，用来存放项目工程文件 2.1 创建pod私有仓库的模板 pod lib create WJCategory 执行完会自动打开工程： 2.2 代码拖到classes 将代码拖到ReplaceMe.m的文件目录下，删除ReplaceMe.m 2.3 pod安装进行测试 cd 到Example目录 安装成功 在Example工程里引入头文件就可以使用了 2.4 修改podspec描述文件 2.5 自己本地端检测 pod lib lint 修改完成后,cd 到WJCategory目录下，然后验证podspec文件 pod lib lint 出现WJCategory passed validation.则验证通过。 2.6 提交项目到远程仓库 cd 到WJCategory目录下 git add . git commit -m

CronJob Cron Job 管理基于时间的 Job ，即： 在给定时间点只运行一次 周期性地在给定时间点运行 一个 CronJob 对象类似于 crontab （cron table）文件中的一行。它根据指定的预定计划周期性地运行一个 Job，格式可以参考 Cron 。 前提条件 当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 < 1.8，启动 API Server（参考 为集群开启或关闭 API 版本 获取更多信息）时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启 batch/v2alpha1 API。 典型的用法如下所示： 在给定的时间点调度 Job 运行 创建周期性运行的 Job，例如：数据库备份、发送邮件。 CronJob Spec .spec.schedule ：调度，必需字段，指定任务运行周期，格式同 Cron .spec.jobTemplate ：Job 模板，必需字段，指定需要运行的任务，格式同 Job .spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限 .spec

Job Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。 Job Spec格式 spec.template格式同Pod RestartPolicy仅支持Never或OnFailure 单个Pod时，默认Pod成功运行后Job即结束 .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1 .spec.parallelism 标志并行运行的Pod的个数，默认为1 spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试 一个简单的例子： apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: metadata: name: pi spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never $ kubectl create -f ./job.yaml job "pi" created $ pods=$(kubectl get pods --selector=job-name=pi --output

ReplicaSet RC：ReplicationController（老一代的Pod控制器） 用于确保由其管控的Pod对象副本数量，能够满足用户期望，多则删除，少则通过模板创建。 特点： ​ 确保Pod资源的对象的数量精准 ​ 确保Pod监控运行 ​ 弹性伸缩。 同样，它也可以通过yaml或json格式的资源清单来创建。其中spec字段一般嵌套一下字段 ​ replicas：期待的Pod对象副本数量 ​ selector：当前控制器匹配Pod对象副本的标签选择器 ​ template：Pod副本的模板 与RC相比而言，RS不仅支持基于等值的标签选择器，而且还支持基于集合的标签选择器。 标签：解决同类型的资源对象越来越多，为了更好的管理，按照标签分组。 常用标签分类： release(版本信息)：stable(稳定版), canary(金丝雀版本), beta(测试版) environment(环境变量)：dev(开发)，qa(测试), production(生产) application(应用)：ui, as(application software 引用软件), pc, sc tier(架构层级)：frontend(前端), backend(后端), cache(缓存) partition(分区)：customerA(客户A), customerB(客户B) triack

Job资源对象 服务类的Pod容器：RC、RS、DS、Deployment. 工作类的Pod容器：Job--->执行一次，或者批量执行处理程序，完成之后推出容器。 [root@master ~]# cat job.yaml kind: Job apiVersion: batch/v1 metadata: name: test-job spec: template: metadata: name: test-job spec: containers: name: hello image: busybox command: ["echo","hello k8s job!"] restartPolicy: Never [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE test-job-qgc6p 0/1 Completed 0 55s [root@master ~]# kubectl logs test-job-qgc6p hello k8s job! PS：注意，如果容器内执行任务有误，会根据容器的重启策略操作容器，不过这里的容器重启策略只能是：Never、OnFailure 提高Job的执行效率 我们可以在Job.spec字段下加上parallelism选项。表示同时运行多少个Pod执行任务