spec

9-3 Scheduler --- 玩转pod调度（下） 创建web-dev-pod.yaml 验证pod的亲和性 apiVersion: apps/v1 kind: Deployment metadata: name: web-demo-pod namespace: dev spec: selector: matchLabels: app: web-demo-pod replicas: 1 template: metadata: labels: app: web-demo-pod spec: containers: - name: web-demo-pod image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: # 和app 名为web-demo的pod 运行在一起 matchExpressions: - key: app operator: In values: - web-demo # 运行的条件 会运行在同一个节点 topologyKey: kubernetes.io/hostname # 倾向于和名为web

简介 openstack的nova项目在创建虚拟机的时候，需要在多个主机中选择一个主机来创建虚拟机，这个选择的过程通过nova-scheduler完成，整个选择过程分析如下。 首先nova-scheduler收到创建的请求会在filter_scheduler通过类FilterScheduler的schedule_run_instance启动调度创建虚拟机的流程。 代码如下，红色为关键代码（红色加粗为获取可用主机的部分） def schedule_run_instance ( self , context , request_spec , admin_password , injected_files , requested_networks , is_first_time , filter_properties , legacy_bdm_in_spec ) : vm_uuids = request_spec . get ( 'instance_uuids' ) * #get available hosts for vm create weighed_hosts = self . _schedule ( context , request_spec , filter_properties , vm_uuids ) * instance_uuids = request_spec .

9-4 部署策略详解 --- 重建、滚动、蓝绿、金丝雀 部署策略实践 这两个是kubernetes 层面支持的策略 Rolling update Recreate 需要先停止旧服务 这两个是需要通过service的一些特征（labelselector）结合deployment一起完成 蓝绿部署 金丝雀 1 测试Recreate 创建web-recreate.yaml #deploy apiVersion: apps/v1 kind: Deployment metadata: name: web-recreate namespace: dev spec: # 策略为Recreate strategy: type: Recreate selector: matchLabels: app: web-recreate replicas: 2 template: metadata: labels: app: web-recreate spec: containers: - name: web-recreate image: harbor.pdabc.com/kubernetes/web:v3 ports: - containerPort: 8080 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 20

作者 | 子誉 蚂蚁金服高级技术专家 关注“阿里巴巴云原生”公众号，回复关键词 “入门” ，即可下载从零入门 K8s 系列文章 PPT。 Kubernetes 调度过程 搜小说 https://biqi.org/ 首先来看第一部分 - Kubernetes 的调度过程。如下图所示，画了一个很简单的 Kubernetes 集群架构，它包括了一个 kube-ApiServer，一组 Web-hook Controllers，以及一个默认的调度器 kube-Scheduler，还有两台物理机节点 Node1 和 Node2，分别在上面部署了两个 kubelet。 我们来看一下，假如要向这个 Kubernetes 集群提交一个 pod，它的调度过程是什么样的一个流程？ 假设我们已经写好了一个 yaml 文件，就是下图中的橙色圆圈 pod1，然后往 kube-ApiServer 里提交这个 yaml 文件。 此时 ApiServer 会先把这个待创建的请求路由给我们的 webhook Controllers 进行校验。 通过校验之后，ApiServer 会在集群里面生成一个 pod，此时生成的 pod，它的 nodeName 是空的，并且它的 phase 是 Pending 状态。在生成了这个 pod 之后，kube-Scheduler 以及 kubelet 都能 watch 到这个 pod

PHP SPL笔记 作者： 阮一峰 日期： 2008年7月 8日 这几天，我在学习PHP语言中的 SPL 。 这个东西应该属于PHP中的高级内容，看上去很复杂，但是非常有用，所以我做了长篇笔记。不然记不住，以后要用的时候，还是要从头学起。 由于这是供自己参考的笔记，不是教程，所以写得比较简单，没有多解释。但是我想，如果你是一个熟练的PHP5程序员，应该足以看懂下面的材料，而且会发现它很有用。现在除此之外，网上根本没有任何深入的SPL中文介绍。 ================ PHP SPL笔记 目录 第一部分 简介 1. 什么是SPL？ 2. 什么是Iterator？ 第二部分 SPL Interfaces 3. Iterator界面 4. ArrayAccess界面 5. IteratorAggregate界面 6. RecursiveIterator界面 7. SeekableIterator界面 8. Countable界面 第三部分 SPL Classes 9. SPL的内置类 10. DirectoryIterator类 11. ArrayObject类 12. ArrayIterator类 13. RecursiveArrayIterator类和RecursiveIteratorIterator类 14. FilterIterator类 15.

http://machael.blog.51cto.com/829462/213477 上一篇日志写到，为什么要制作rpm包，以及如何使用.src.rpm文件生成rpm包。最后部分还看到.src.rpm的内容，实际上 就是由.tar.gz源码、补丁软件和.spec脚本组成的。由此知道，使用.spec生成rpm包是比较简单的，因为.src.rpm通常都是由软件开 发者或者第三方的专业制作人根据源码调试好的，所以，只要处理好平台兼容性和相关的版本，不会遇到太大的问题。 但我觉得单纯明白用.spec生成rpm是不够的。常见有两个原因值得我们去了解用如何用源码制作rpm： 引用 1、并不是所有的软件都提供.rpm方式的。 这是最常见的原因。负责任的开发者应提供rpm方式的二进制软件包，以便用户选择使用。但也很常见就是软件作者只是发布了源码，最后一部分的编译和安装需要用户自行解决。我不想深究对错问题，反正知道有这样的情况就可以了； 2、自行打包一些文件或自己开发了一套软件 当 然，使用tar包或cpio等也可以打包文件，甚至比制作rpm要简单很多。但如果您想在安装的过程中就把一套额外的软件部署完毕，那使用rpm方式通常 是是唯一的方法。而且rpm还有数据库协助软件升级、文件校验等，结合yum升级方式，没有理由不选择rpm，特别是对于最终用户，我认为提供rpm包是 最佳的方法。 一

在此次阅读之前我并不知道原来软件还有规格说明，也不知道文档对一个软件从业者竟是如此重要。 规格说明指的是系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。一般来说，软件产品需求规格说明书（SRS）的可能目的是：定义软件总体要求，作为用户和软件开发人员之间相互了解的基础;提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础;作为软件总体测试的依据。 规格说明书（Specification）简称Spec，分为以下两种： 1、软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）。 2、软件技术说明书（Technical Spec），又称为设计文档（Design Doc），主要用来说明软件内部的实际规范（把软件当作一个透明的箱子）。 功能说明书是指从客户的角度出发描述产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部的实现细节。而写好Spec就是把一件事情描述清楚。要定义好相关的概念、好处、目标等；规范好一些假设；避免一些误解，界定一些边界条件，要避免二义性的情况，让大家讨论，形成共识，同时还要征求客户的意见；描述主流的用户/软件交互步骤；一些好的功能可能会有副作用，我们要把这些副作用明明白白的写出来；服务质量说明

规格说明指的是系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。一般来说，软件产品需求规格说明书（SRS）的可能目的是：定义软件总体要求，作为用户和软件开发人员之间相互了解的基础;提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础;作为软件总体测试的依据。 规格说明书（Specification）简称Spec，分为以下两种： 1、软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）。 2、软件技术说明书（Technical Spec），又称为设计文档（Design Doc），主要用来说明软件内部的实际规范（把软件当作一个透明的箱子）。 功能说明书是指从客户的角度出发描述产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部的实现细节。而写好Spec就是把一件事情描述清楚。要定义好相关的概念、好处、目标等；规范好一些假设；避免一些误解，界定一些边界条件，要避免二义性的情况，让大家讨论，形成共识，同时还要征求客户的意见；描述主流的用户/软件交互步骤；一些好的功能可能会有副作用，我们要把这些副作用明明白白的写出来；服务质量说明，软件团队要说明服务质量是什么等级，意味着什么，不然就会人云亦云，以谬传缪。 而我们要做的就是实践

1. PodPreset 的作用 将一些公用的参数设置到pod中去，例如 时区统一设置为东八区等 2. API Server 开启PodPreset 编辑文件 /etc/kubernetes/manifests/kube-apiserver.yaml，添加配置 --runtime-config=settings.k8s.io/v1alpha1=true，添加PodPreset到--admission-control(新版本是--enable-admission-plugins) 重启kubelet服务，sudo systemctl restart kubelet 3. 部署统一时区的PodPreset yaml文件如下： apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: setting-timezone spec: selector: matchLabels: env: - name: TZ value: Asia/Shanghai 其中 selector、matchLabels是必须的，不写任何的值就代表全局启用。 4. 禁用PodPreset 在一些情况下，用户不希望 Pod 被 Pod Preset 所改动，这时，用户可以在 Pod spec 中添加形如 podpreset

Deployment apiVersion: extensions/v1beta1 kind: Deployment metadata: name: test-web spec: replicas: 4 template: metadata: labels: app: web spec: containers: - name: test-web image: 192.168.1.70:5000/httpd:v1 ports: - containerPort: 80 PS：注意，在Deployment资源对象中，可以添加Port字段，但此字段仅供用户查看，并不实际生效 service kind: Service apiVersion: v1 metadata: name: web-svc spec: type: NodePort selector: app: web ports: - protocol: TCP port: 80 //clusterIP的端口 targetPort: 80 //Pod的端口 nodePort: 30123 SNAT：Source NAT（源地址转换） DNAT：Destination NAT（目标地址转换） MASQ：动态的源地址转换 service实现的负载均衡：默认使用的是iptables规则 第二种方案：IPVS 回滚到指定版本