provisioning

本文环境为Kubernetes V1.11，操作系统版本为 CentOs 7.3，Kubernetes集群安装可以参考 kubeadm安装kubernetes V1.11.1 集群 容器中的存储都是临时的，因此Pod重启的时候，内部的数据会发生丢失。实际应用中，我们有些应用是无状态，有些应用则需要保持状态数据，确保Pod重启之后能够读取到之前的状态数据，有些应用则作为集群提供服务。这三种服务归纳为无状态服务、有状态服务以及有状态的集群服务，其中后面两个存在数据保存与共享的需求，因此就要采用容器外的存储方案。 Kubernetes中存储中有四个重要的概念：Volume、PersistentVolume PV、PersistentVolumeClaim PVC、StorageClass。掌握了这四个概念，就掌握了Kubernetes中存储系统的核心。我用一张图来说明这四者之间的关系。 Volumes是最基础的存储抽象，其支持多种类型，包括本地存储、NFS、FC以及众多的云存储，我们也可以编写自己的存储插件来支持特定的存储系统。Volume可以被Pod直接使用，也可以被PV使用。普通的Volume和Pod之间是一种静态的绑定关系，在定义Pod的同时，通过 volume 属性来定义存储的类型，通过 volumeMount 来定义容器内的挂载点。 PersistentVolume

SD-WAN（Software Defined Wide Area Network）是近年来网络技术创新的一个热点，笔者结合自己的体会，和大家一起回顾这一领域的发展过程，对现状作一总结，对未来作一展望。篇幅所限，文中的示例以Cisco的解决方案为主，兼顾其它厂商。欢迎大家发表评论，共同切磋探讨。 一、广域网优化回顾 SDWAN通过转发面与控制面的分离，简化广域网的运行和管理。其技术涵盖两个方面：一是广域网优化，即通过压缩、缓存、传输层和应用层的协议优化等传统广域网优化技术加上广域网接口的流量调度，实现广域网传送效率的最大化。在以前广域网带宽受限的条件下（如MPLS链路～10M带宽），压缩、缓存、协议优化曾经是广域网优化的重点，如今得益于Internet 广域网接口千兆级（Gigabit ）的带宽，广域网优化的重点是流量调度；二是广域网的部署、配置与运维的自动化，即所谓的软件定义（Software Defined）部分，例如策略下发的自动化、设备配置的模版化。 广域网优化的代表厂商有Riverbed、Cisco等。Riverbed更专注压缩、缓存、协议优化，Cisco则兼而有之，其流量调度的历史可以追溯到Cisco企业业务路由器ASR/ISR/CSR的两个功能：基于策略的路由控制（Policy Based Routing）和基于性能的路由控制（Performance Routing)

esxi 精简置备只增不减问题解决方法 众所周知Thin Provisioning模式下的虚拟机 磁盘 的空间会随需增长，可以很大程度上帮助我们节约空间，可是，凡增长过后的空间，即使清除了导致增长的文件后，这部分空间依然无法自动释放，也就是说：空间只能增加不能减少。 网站大部分的解决方法是通过ghost或者converter来解决，但那样解决起来相对比较麻烦，操作不方便 我的解决方法：通过vmkfstools先转换成厚置备模式，然后在转换精简置备模式即可 通过ssh可以远程直接操作亦可通过vcenter+vmontion来操作 现磁盘空间容量： 先迁移到另外一个盘符，模式更改成厚置备模式 迁移后 硬盘容量： 迁移完成后，在重新迁移回原来的磁盘内，模式更改为精简置备 迁移完成后 在查看容量情况 完成 命令格式： 精简置备转换至厚置备置零： vmkfstools --inflatedisk /vmfs/volumes/DatastoreName/VMName/VMName.vmdk 厚置备延迟置零转换至精简备置： vmkfstools --thin /vmfs/volumes/DatastoreName/VMName/VMName.vmdk 来源： oschina 链接： https://my.oschina.net/u/4387790/blog/3599940

痞子衡嵌入式半月刊： 第 1 期 这里分享嵌入式领域有用有趣的项目/工具以及一些热点新闻，农历年分二十四节气，希望在每个交节之日准时发布一期。 本期刊是开源项目（GitHub: JayHeng/pzh-mcu-bi-weekly ），欢迎提交 issue，投稿或推荐你知道的嵌入式那些事儿。 唠两句 今天是农历庚子鼠年正月十五，传统元宵佳节，但因为 2019-nCoV 肺炎疫情不减，节日气氛平淡了些。 原计划这个半月刊能按二十四节气交节之日准时发布，但这第一期就没能准时，离立春已经过去4天了，也罢，规矩一开始就破了，底下发布时间压力上也就小了。 大家都知道痞子衡东家是飞思卡尔/恩智浦半导体，所以这第一期咱偏袒一下东家，多给恩智浦相关产品一些特写。 本期共收录 3条资讯、3个项目、2个工具，希望对你有帮助！ 资讯类 <font color="red">1、划时代 1GHz 主频 MCU 恩智浦 i.MXRT1170 有望 2020 年下半年面市</font> 2019年10月2日恩智浦半导体隆重发布了 i.MXRT1170，这是一款划时代的 MCU。因为它，单片机首次迈入 1GHz 主频大关，这对于嵌入式从业人员来说，是个值得铭记的时刻。 这款性能炸裂的 MCU 大家都非常期待，在各大嵌入式技术交流群里，它也被频繁提及和讨论，它什么时候能供货是大家最关心的问题。据目前进展来看，i

一.主要流程参见[1] 参考文章： 1.https://www.cnblogs.com/lidongxu/p/5150119.html 2.https://www.v2ex.com/t/167934 3.http://blog.csdn.net/hxpp777/article/details/50276623 4.http://blog.csdn.net/minggeqingchun/article/details/70049401 如果如[2]中在xcode的Preferenses->Accounts里面一同步，Xcode就会自动生成N个iOSTeam Provisioning Profile，那么就不要同步。采取步骤： （1）清除所有的mobileprovision[3] 通过File Finder-->应用程序-->实用工具-->终端进行删除 首先cd到目录”~/Library/MobileDevice/Provisioning\ Profiles” cd ~ /Library/ MobileDevice / Provisioning \ Profiles / 然后删除里面所有的mobileprovision文件 rm *. mobileprovision 或者通过界面方式删除[4] 切到桌面，选择文件---->前往，这时还缺少一个隐藏功能，选中Alt键，就会出现“资源库”

简介： 众所周知，K8s 的持久化存储（Persistent Storage）保证了应用数据独立于应用生命周期而存在，但其内部实现却少有人提及。K8s 内部的存储流程到底是怎样的？PV、PVC、StorageClass、Kubelet、CSI 插件等之间的调用关系又如何，这些谜底将在本文中一一揭晓。 作者 | 孙志恒（惠志） 阿里巴巴开发工程师 导读： 众所周知，K8s 的持久化存储（Persistent Storage）保证了应用数据独立于应用生命周期而存在，但其内部实现却少有人提及。K8s 内部的存储流程到底是怎样的？PV、PVC、StorageClass、Kubelet、CSI 插件等之间的调用关系又如何，这些谜底将在本文中一一揭晓。 更多相关内容： 点击这里 ​ K8s 持久化存储基础 在进行 K8s 存储流程讲解之前，先回顾一下 K8s 中持久化存储的基础概念。 1. 名词解释 in-tree ：代码逻辑在 K8s 官方仓库中； out-of-tree ：代码逻辑在 K8s 官方仓库之外，实现与 K8s 代码的解耦； PV ：PersistentVolume，集群级别的资源，由 集群管理员 or External Provisioner 创建。PV 的生命周期独立于使用 PV 的 Pod，PV 的 .Spec 中保存了存储设备的详细信息； PVC

试图重建一个昨天工作的应用程序。 收到个人资料已过期的消息，因此我将其从iPod和iTunes中删除。 当我选择一个新的配置文件（标识符中带有*）时，我现在收到一个错误： 代码签名错误：无法找到供应配置文件（长字符串）。 我错过了什么？ 我查看了相关问题，但没有看到这种情况。 #1楼 只花了一个小时左右这样做，并在布拉德的建议和一些额外的改变的帮助下，这一切都奏效了。 我使用以下内容完成了此操作：10.7.3，Xcode 4.3.2，iOS 5.1顺便说一句。 1）右键单击 myapp.xcodeproj 并选择包内容 2）使用文本编辑器打开 project.pbxproj （不建议使用textedit，因为它可能会搞乱格式化） 3）完全向下滚动，直到找到 /* Begin XCBuildConfiguration section */ 4）请注意，您有一个调试和发布部分 5）在发布部分看一下 CODE_SIGN_IDENTITY ＆ "CODE_SIGN_IDENTITY[sdk=iphoneos*]" 它看起来应该是这样的： CODE_SIGN_IDENTITY = "iPhone Distribution: MyCompany LLC"; "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: MyCompany

1.综述 一句话： 关注 CNCF 基金会 Cloud Native 云原生互动全景图 CNCF云原生互动全景图 打开网站，全景图是可以点击的，在图中找你关注的领域 2.找到你关注的分类领域 比如我关注“API Gateway API网关”，就点击他的图标就可以看到相关信息 APISIX KrakenD 非常直观的一个概览 项目开发语言，代码提交柱状图，等开源代码维护情况信息 可以说CNCF的全景图就是一张开启云原始大门的大地图，地图在手开始遨游吧 3.CNCF分类大纲 （截止2020年02月08日） CNCF云原生互动全景图 App Definition and Development 应用定义和开发 Database 数据库 Streaming & Messaging 流处理和消息系统 Application Definition & Image Build 应用程序定义和图像构建 Continuous Integration & Delivery 持续集成与交付 Orchestration & Management 编排和管理 Scheduling & Orchestration 计划与编排 Coordination & Service Discovery 协调与服务发现 Remote Procedure Call 远程过程调用 Service Proxy 服务代理 API

[TOC] 核心原理：控制器模式 控制器逻辑中包括controller, sensor 和system 三个逻辑组件，通过修改spec中相关的字段来触发事件，controller通过比较当前状态和期望状态，来触发对系统的具体操作。 sensor中则包括reflector, informer, indexer 三个组件， reflector通过list&watch apiserver 来获取资源的数据， list 用来在controller重启或者watch中断的情况下，对资源进行全量的更新。 watch则在多次list之间进行增量的更新。 reflector会在获取资源信息之后，会在delta queue中加入一个包括资源信息本身和资源对象事件类型的delta数据，delta队列可以保证同一个对象在队列中仅有一条记录，从而避免在reflector list&watch的时候产生重复的记录。 informer组件不断从delta队列中弹出delta记录，一方面把资源对象交给资源回调函数，同时又把资源对象交给indexer, indexer默认将资源对象记录在缓存中，通 过namespace作为其索引值，并且能被controller-manager的多个controller进行资源共享。 控制循环的控制器函数，主要由 事件处理函数 和worker组成。 事件处理函数，会监听资源的新增