增加、删除node

删除node14

#ansible-playbook r.move.node14.yml -k \
-e docker_bin_dir=”/usr/bin” \
-e kube_network_plugin=”calico-rr”

#kubectl delete node node14

#kubectl get nodes node14就删除完毕

 

增加node14

在hosts.ini的nodes部分加上node别名即可，当然的提前ssh-key打通

ansible-playbook -i inventory/sk/hosts.ini scale.yml -b -k

root@node10:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node10 Ready master 20h v1.9.5+coreos.0
node11 Ready node 3d v1.9.5+coreos.0
node12 Ready node 3d v1.9.5+coreos.0
node13 Ready node 3d v1.9.5+coreos.0
node14 Ready node 36s v1.9.5+coreos.0

基于云os的以太仿矿机操作系统

近期我们将推迟基于云os的以太仿矿机操作系统1.0，本系统是专门针对显卡矿机的。支持各类amd显卡（rx470\rx480\570)，算力稳定，系统稳定！

1.本系统是基于linux操作系统，原版claymore挖矿程序。

2.u盘即插即用，不需要win10那样繁琐。

3.支持大批量系统部署。

4.原始矿机固态硬盘可以不要，只需要购买我们的U盘系统即可。

5.通过web云平台管理所有矿机设备，钱包地址、矿池以及矿工名。

6.比ethos更人性化，更稳定可靠。

ethos

有意者请联系我们！

关于Kubernetes Master高可用的一些策略

Kubernetes高可用也许是完成了初步的技术评估，打算将生产环境迁移进Kubernetes集群之前普遍面临的问题。 为了减少因为服务器当机引起的业务中断，生产环境中的业务系统往往已经做好了高可用，而当引入Kubernetes这一套新的集群管理系统之后， 服务器不再是单一的个体，位于中央位置的Kubernetes Master一旦中断服务，将导致所有Node节点均不可控，有可能造成严重的事故。

总体来讲这是一个被多次讨论，但暂时没有形成统一解决方案的话题。今天主要介绍一些Kubernetes Master高可用的策略，供大家参考。

一个小目标

高可用是复杂的系统工程。出于篇幅的考虑以及能力的限制，今天我们先关注一个小目标：所有的Kubernetes Master服务器没有单点故障，任何一台服务器当机均不影响Kubernetes的正常工作。

实现这一目标带来的直接收益是我们可以在不影响业务正常运行的前提下实现所有服务器的滚动升级，有助于完成系统组件升级以及安全补丁的下发。

为了实现没有单点故障的目标，需要为以下几个组件建立高可用方案：

这些组件的关系可参考下面这张集群架构示意图。 继续阅读 →

mysql-5.7密码

1.默认随机密码会过期，提示如下

mysql> show databases;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

解决办法：

2.SET PASSWORD = PASSWORD(‘your new password‘);

3. ALTER USER ‘root’@’localhost’ PASSWORD EXPIRE NEVER;

4.flush privileges;

 

收工！

Docker网络方案-Calico

  • Calico，基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。

Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。通过将整个互联网的可扩展IP网络原则压缩到数据中心级别，Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。

这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。 继续阅读 →

关于https证书的类型

关于https证书

https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
目前大部分网站都在忘https上转，Chrome也将https作为浏览器的默认连接，如果网站没采用https的话，就会出现！的标识。

苹果宣布了一个最后期限：到2017年1月1日 App Store中的所有应用都必须启用 App Transport Security安全功能。App Transport Security（ATS）是苹果在iOS 9中引入的一项隐私保护功能，屏蔽明文HTTP资源加载，连接必须经过更安全的HTTPS。苹果目前允许开发者暂时关闭ATS，可以继续使用HTTP连接，但到年底所有官方商店的应用都必须强制性使用ATS。

所以，推行https是整个互联网行业的趋势。

证书

目前主流的SSL证书主要分为DV SSL 、 OV SSL 、EV SSL。

DV SSL

DV SSL证书是只验证网站域名所有权的简易型（Class 1级）SSL证书，可10分钟快速颁发，能起到加密传输的作用，但无法向用户证明网站的真实身份。

目前市面上的免费证书都是这个类型的，只是提供了对数据的加密，但是对提供证书的个人和机构的身份不做验证。

OV SSL

OV SSL,提供加密功能,对申请者做严格的身份审核验证,提供可信身份证明。

和DV SSL的区别在于，OV SSL 提供了对个人或者机构的审核，能确认对方的身份，安全性更高。

所以这部分的证书申请是收费的~

EV SSL

超安=EV=最安全、最严格 超安EV SSL证书遵循全球统一的严格身份验证标准，是目前业界安全级别最高的顶级 (Class 4级)SSL证书。

金融证券、银行、第三方支付、网上商城等，重点强调网站安全、企业可信形象的网站，涉及交易支付、客户隐私信息和账号密码的传输。

这部分的验证要求最高，申请费用也是最贵的。

 

复习-12Factor方法论

今天继续复习了一下12Factor方法论，更深一步了解其精华所在：

1.微服务。标准：子系统以及其代码，可以独立部署。

2.依赖声明与环境隔离。很多研发很不讲究“代码卫生”，这点作为SRE非常bs。

3.配置存储在Unix环境变量中。这点在现实中实现起来有好有坏，研发人员对配置变量的管理和规划需要提前做出存储计划。

4.外部db、cache以及其他子系统的依赖声明成资源。需要研发人员有整体全局意识，不能只顾某个算法的实现、某个串的序列号结果。而不顾全大局。

5.严格区分打包和运行环境。

6.应用作为无状态的进程运行。sticky session必须被避免哦

7.通过绑定端口对外提供服务。

8.通过多进程模型进行扩容。

9.快速启动，优雅关闭。最小化短时间启动，以前有个恶劣的程序员写了个程序，每次启动要30-45分钟左右，简直是灾难。

10.开发、测试、部署环境尽量接近。

11.log当事件流集中处理。

12.一次性的系统管理任务。

 

kubernetes中创建secret

在k8s的集群里面，我们需要批量下发dep jobs到k8s的node上，由于node上我们通过play-books进行初始安装k8s-proxy后，hub信息都是空。不信任私我们的HUB（harbor）。

在k8s中，我们需要建立secret，然后在后续的运维部署任务中使用他。

建立secrset如下：

参数
kubectl create secret docker-registry NAME –docker-username=user –docker-password=password –docker-email=email
exp：
master@root#kubectl create secret docker-registry sk-hub –docker-server=hub.sklinux.com –docker-username=sk –docker-password=passwordjiushipassword –docker-email=sklinux@qq.com