一、任务 使用kubeadm搭建一个1master+2slaves的kubernates集群 于集群上部署Istio，运行其BookInfo示例 ​ 二、准备 在Vultr上租用三台VPS，配置均为2 vCore，4G RAM，OS都安装CentOS 7 x64。（实际搭建运行时未遇到性能问题。） 需要注意的是，很多海外VPS的IP都被封掉了，ping不通。（可到站长之家之类的网站去确认，国内ping不通，海外可通。）对此可重建VPS直至获取可访问的IP，或者依赖科学上网的跳板机。 另外，做验证只使用公网IP即可，无需使用数据中心的内网IP（当然实际的生产环境是使用内网IP的），甚至这三台VPS还可以是跨数据中心的，都可以搭建成功。 基本的知识依据为官网指南，按使用顺序依次为 安装kubeadm 注1 安装kubernates集群注1 安装Istio 安装BookInfo示例 Istio Ingress Controller介绍的*Verifying ingress*部分注2 注1：安装kubeadm和kubernates集群时，预想坑会比较多，还查阅了一些技术博客和官网对比了一下，但发现除了说明顺序不一样外（官网把很多细节放到Notes里），技术博客中提到的要点，在官网基本上都是有所体现。 注2：按说前4篇做完就应该结束了，但存在一个问题：Istio官网上的上述文档只给出了存在外部负载均衡的环境下查找ingress的对外IP和端口的方法，新装的环境并不具备外部负载均衡，因此还需要阅读第5篇的内容，使用不具备外部负载均衡环境下的相应手段找到对外IP和端口。 三、实施 步骤一：任选1台VPS部署Master节点。命令的流水账如下： systemctl stop firewalld systemctl disable firewalld cat <<EOF > /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF sysctl --system setenforce 0 swapoff -a yum update yum install -y docker systemctl enable docker && systemctl start docker cat <<EOF > /etc/yum. [Read More]

【问题域】 任务：搭建一个Istio的Bookinfo Sample 约束：搭建成果要求公网可访问可确认 资源：三个晚上的时间，一个Vultr账号，一台MacBook Pro ​ 【解决域】 一、选型 基于Kubernetes以外的平台 和Kubernetes平台比各方面未见优势，不考虑 ​ 基于在MacBook Pro上搭建的Minikube 公开到公网还需要花生壳等的支持，硬件有限时间更有限，或许可行，先不考虑 ​ 基于在Vultr上Creating Kubernetes from Scratch（2-3节点） 此方案最能匹配进行该任务的初衷（学习Kubernetes搭建），但步骤较多时间不够，NG ​ 基于在Vultr上使用kubeadm搭建的Kubernetes集群 步骤不多，时间上或许可行，可作为备选方案 ​ 在Google Cloud Platform 上搭建Kubernetes + Istio 一站式解决，步骤最少，自带免费服务器资源，选为首选方案 ​ 二、实施 到Istio官网找到Quick Start with Google Kubernetes Engine作为整个实施过程的指南资料。 到Google Cloud Platform，注册账号，提交信用卡信息，获取$300的一年免费资源。 虽然申请成功，但付款设置里的结算信用卡账号被冻结，需要向谷歌在线申诉，申诉填写的内容很简单，但需要上传身份证/护照照片和信用卡正面照片（卡号用手指遮挡只露出4位尾号即可），一天内得到邮件回复信用卡账号解冻。（信用卡账号冻结的情况网上也有反映，我申请免费资源时收到了$1的信用卡支付失败短信，我怀疑跟我使用海外IP使用信用卡有关，抑或是银行针对性的封锁。） 到Google Container Engine API打开对此API的使用（使用获赠的免费资源）。 到Cloud Console，找到Compute Engine default service account（账号格式为projectNumber-compute@developer. [Read More]

原文 在需要时从数据存储（data store）往缓存加载数据。这种模式可以提高性能，并有助于保持缓存与数据存储间的数据一致性。 背景和问题 应用程序使用缓存，以优化对数据存储中的信息的反复访问。但如果期望缓存与数据存储中的数据总是完全一致，通常却是不切实际的。应用程序需要实施这样一种策略，一方面确保在缓存中的数据是尽可能的最新状态，另一方面当缓存中的数据过期时，要能够对其察知和处理。 解决方案 许多商业缓存系统提供read-through和write-though/write-behind操作。（译者注：关于xxx-aside/though/behind这些晦涩的用语，请参考Using Read-through & Write-through in Distributed Cache和Cache memory。）在这些系统中，应用程序通过引用缓存获取数据。如果数据不在缓存中，数据会被透明地从数据存储中取得并添加到缓存中。对缓存中的数据的任何修改也都会被自动写回到数据存储中。 对于那些不提供上述功能的缓存，对缓存中数据的维护工作就成为了使用缓存的应用程序的职责。 一个应用程序可以通过实现Cache-Aside策略来模拟read-through缓存的功能。该策略高效地将数据按需载入缓存。图1总结了这一过程的各个步骤。 图1 - 使用Cache-Aside模式在缓存中存储数据 如果一个应用程序要更新信息，它可以按照如下步骤来模拟write-through策略： 修改数据存储中的数据。 将缓存中的相应项目置为无效。 当下一次需要使用该项目时，根据Cache-Aside策略，应用程序会从数据存储中取得更新后的数据，并将其添加回缓存。 问题和注意事项 在决定如何实施这一模式时，请考虑以下几点： 缓存数据的生命周期。许多缓存实现了一个过期策略，根据过期策略，如果缓存中的数据持续一段规定的期限没有被访问，相应数据就会被置为无效，并被从缓存中删除。为了Cache-Aside模式的高效实施，需要确保过期策略与使用数据的应用程序的访问模式相匹配。不要使有效期限太短，因为这会导致应用程序不断地从数据存储中获取数据并把它添加到缓存。同样，不要使有效期限太长，因为这会导致缓存数据容易变得陈旧。请记住，针对相对静态的数据，或者频繁被读取的数据，缓存才是最有效的。 清除数据。相对于作为数据源头的数据存储来说，大部分缓存只具备有限的数据容量，并且在必要时缓存将会清除数据。大多数缓存采用了最少最近使用（least-recently-used）策略来选择要清除的对象项目，但清除策略是可定制的。请配置缓存的全局过期属性和其它属性，以及每个缓存项目的过期属性，以帮助确保缓存在成本上是高效的。而对缓存中的所有项目都施加一个全局清除策略可能不总是适当的。例如，如果从数据存储中获取一个缓存项目的开销非常大，那么如下策略可能会更为有利：在缓存中保持这一获取开销巨大的项目，为此而清除那些更频繁被访问但获取开销更小的项目。 预装缓存。许多解决方案在启动处理中，会用那些可能会被应用程序需要的数据来预填充缓存。如果发生某些数据过期或被清除的情况，Cache-Aside模式可能仍然是有用的。 一致性。实现Cache-Aside模式不保证数据存储和缓存之间的一致性。在数据存储中的项目可在任何时间被一个外部进程来改变，而这种改变可能直到下一次该项目被载入缓存时才能在缓存中被反映。在跨数据存储复制数据的系统中，如果同步发生得非常频繁，这个问题可能会变得特别尖锐。 本地（内存内）缓存。对一个应用程序实例来说，缓存可以是本地的，存储在内存中。如果一个应用程序反复访问相同的数据，Cache-Aside模式在这样的环境中是有用的。然而，本地缓存是私有的，因此对于相同的缓存数据，不同应用程序实例可能各自拥有它的一个副本。数据在各个缓存间可能很快就变得不一致了，因此可能需要更为频繁的使私有缓存中的数据过期并对其刷新。在这些场景下，可能适合于考虑使用共享式或分布式缓存机制。 何时使用这种模式 使用此模式时： 缓存不提供原生的read-through和write-through操作。 资源需求是不可预测的。这种模式使应用程序能够按需加载数据。对于应用程序需要哪些数据，它不提前做任何假设。 这种模式可能不适合： 当缓存的数据集是静态的。如果这样的数据能够被放入可用的缓存空间，那么请在启动中预装入这些数据，并对其实施数据不会过期的策略。 对于在署在Web服务器群（web farm）上的Web应用程序的会话状态信息的缓存。在这种环境下，你应该避免引入基于客户端—服务器关系的依赖。 示例 在Windows Azure中，你可以使用Windows Azure Cache来创建一个可供多个应用程序实例共享的分布式缓存。下面的代码示例中的GetMyEntityAsync方法展示了Cache-Aside模式基于Windows Azure Cache的一个实现。该方法使用read-though方式从缓存获取一个对象。 一个对象通过使用一个整数ID作为Key来唯一标识。GetMyEntityAsync方法基于此Key生成一个字符串值（Windows Azure Cache的API使用字符串作为Key值），并尝试使用该Key从缓存中获取相匹配的项目。如果该匹配项目被找到，则将其返回。如果在缓存中没有相应匹配项目，GetMyEntityAsync方法会从数据存储获取该对象，并把它添加到缓存，然后返回它（因为依赖于具体的数据存储实现，所以实际从数据存储取得数据的代码被省略了）。注意，为防止由于别处发生的更新导致的缓存数据陈旧，缓存项目被进行了过期设置的配置。 C# [Read More]

设定 git config --global http.proxy http://127.0.0.1:1080 git config --global https.proxy http://127.0.0.1:1080 注意：有些例子把代理服务的URL用单引号括上，但在我的环境里带单引号的设置导致了错误。 取消 git config --global --unset http.proxy git config --global --unset https.proxy 查看 git config --global --get http.proxy git config --global --get https.proxy 其它协议 HTTP仅仅是Git支持的协议之一。官网上如是说： Git can use four major protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. 有关SSH代理的设置，可以参考这里。(未经验证) [Read More]

目前Hugo官方一共提供了135款主题（Themes），下面归类简介其中的25款。 挑选标准：3分代表性 + 6分个人喜好 + 1分随机 :p 常规博客类 Heather Hugo：单列极简，源自Jekyll。 DEMO Beautiful Hugo：单列黑白，源自Jekyll。DEMO Dark Simplicity：单列黑暗。DEMO Startbootstrap Clean Blog：单列背景头部，源自Start Bootstrap。DEMO Dgraph：单列一文一图。DEMO LIVE Hyde：双列左边栏，基于base16可变换配色，源自Jekyll，hugo作者作品。DEMO Hugo Bootstrap Premium：hyde系改版之一，功能多多，未提供demo。 Hugo Geo：双列彩色左边栏。DEMO Twenty Fourteen：双列黑白左边栏，源自WordPress。DEMO Nixon：双列黑白左边栏，hugo作者博客用同款。DEMO LIVE Hugo Octopress：双列黑白右边栏，源自Octopress，定制文档详尽。DEMO 特色设计类 Material Design：贴纸风，material design。DEMO Creative portfolio：贴纸风，源自Bootstrapious。DEMO Remark Minion：基于remark.js的slides秀。DEMO Shapez Theme：基于SVG,花哨。DEMO 特色实现类 Blank：空白theme，各种定制的起点。DEMO Light Hugo：基于normalize.css(sass)，无javascript。DEMO Hugo Future Imperfect：强化响应式布局，源自HTML5 UP 。DEMO Aglaus：AMP加速。DEMO 专用功能类 Landing Page：单列个人/企业展示，图文，源自Jekyll。DEMO Freelancer：单列个人/企业展示,彩色，源自Jekyll。DEMO Github project Page：开发项目主页用。DEMO Material Docs：在线文档用，material design。DEMO Hugo FAQ Theme：FAQ用。DEMO Orbit：个人简历用。DEMO [Read More]

This is my first post, how exciting! [Read More]