Devops

• Ansible：应用编排工具，实现手动执行的编排应用工具
• Docker：面向容器的编排实现
  docker compose：适用于单机编排
  docker swam：多台主机的编排
  docker machine：快速初始化的预处理工具

以上为原来docker的三剑客

• mesos：也是编排工具（资源分配工具），marathon
• kubernetes（80%以上的份额）

Devops 微服务 Blockchain 敏捷开发
从单体到微服务
现在不是分层，而是拆开，类似于import class，因为有了容器

CI：持续集成
CD：持续交付（delivery）
CD：持续部署（deployment）

蓝绿，灰度，金丝雀部署

开发团队做计划，架构设计，开发，（build（可以通过工具来进行，后面如果可以自动进行，叫持续集成），当提交代码后能自动进行构建+测试），测试（各种测试，有问题打回去）----运维（部署）（持续发布）

一收到提交就会进行构建（持续集成），只需要开发，还有自动化测试工具，然后交付给运维（还会自动打包到给运维docker）持续交付，还有工具自动触发不需要运维来部署叫（持续部署）（如果有bug还会自动打回去给开发）

这就是devops，因为docker，一切都容易实现了，dockerfile，自动部署，太爽了

微服务人工去监控是不可能的，必要要用容器编排工具来实现

devops不一定用容器，但是docker真的会很方便

docker和k8s的出现是devops得以落地

k8s：舵手，飞行员（4-5年时间）

原身是borg系统用go语言重新写了一遍

云平台原生支持k8s（云原生的k8s应用）

k8s（华为，阿里）都有
swam docker原生在企业发行版当中支持k8s
将k8s整合到自己的东西里来

红帽现在也在做

paas平台及服务

k8s：自动装箱，自我修复（kill掉重新起一个），关注群体，不关注个体，水平扩展（只要物理平台够用），服务发现，负载均衡，实现自动做负载均衡，自动发布和回滚（运维任务），支持秘钥和配置管理。云原生（环境变量）加载外部的配置信息，外部组件保存配置信息，配置中心，起docker自动加载配置中心，如果改了配置中心，不需要自己推过去，加载配置信息放在一个服务器上，不是文件，不在本地加载配置，通过网络获取配置信息，告诉重新加载某些配置，在k8s中也可以实现

就是秘钥和配置管理工具

存储编排，存储卷时根据自身的需求自动获取

批量执行

k8s官方给的说明

k8s：集群，组合多台主机并对外提供计算能力的集群，多个主机当一个主机来使用，安装应用程序，主机分角色，有p2p的，中心节点的。

HDFS：也是有中心节点的集群系统，master-node的模型，主节点可以做冗余就够了，蜂王，和蜂后，干活的。

master做高可用，node就是容器的节点，客户端的请求交给master有个调度器分析node的状态，并调度上去，node检查本地是否有镜像，到registry里面下载，registry也可以是容器，可以运行在k8s之上。

k8s的功能模型，cluster，通过套接字服务，（api） 通过客户端打交道，apiserver k8s（api server） 负责接收请求处理请求，创建一个容器，运行在node之上，调度器scheduler，docker可以做资源限制，可以设定pod的上限和下限，调度器根据最低需求来进行评估

优选，从三个当中选一个最佳的（调度器） 负责调度

容器内部的健康状态监测（可用性探测）

k8s要有自愈能力，如何确保健康，持续监控，控制器用来监控是否是健康的不停地loop 周期性探测，需要确保时钟不断的向用户所用的状态进行迁移，控制器管理器（控制器管理健康）

控制器管理器，都要做冗余

api server schedular 控制器管理器（确保控制器健康，控制器才控制pod的健康）

pod给docker做了抽象的封装，用来放容器

pod有个工作特点，将docker联合起来，共享底层net uts ipc

usr pid互相隔离，pod模拟虚拟机，里面的docker可以用127.0.0.1

还共享存储卷

一般一个pod放一个docker 除非

收集日志nginx 比如一个放nginx，一个放log监控的

都是pod 原子单元
node是k8s的工作节点，核心以pod进行运作

如何理解云计算
SOA和微服务的区别
比如需要起4个nginx

pod的元数据（pod用标签识别）用标签的值来识别pod用于以后k8s的调度，自动完成一些事情
dockerfile打上标签

k8s有个标签选择器（selector）根据标签选择符合pod的插件

是restful风格的api，所有的操作都是对象资源

master（3个）node可以成千上万
node里面运行pod，pod时k8s调度的原子单元
pod有标签，可以通过标签选择器来过滤
master：api server scheduler controller
node：kubelet（接收任务），容器引擎（docker），。。。
逻辑上是pod，没有这么个东西
pod：元数据，kv类型的数据，定义完之后，就可以用标签选择器筛选
同一类pod可能不止一个，pod通过控制器来管理

pod有两类：自助式pod（自我管理），pod控制管理pod

pod：可以被称为有生命周期的对象，nginx作为守护进程运行，容器编排平台提供的功能，最早叫replicationcontrollar（副本控制器）
多退少补，用户生命，定义期望的pod，可是实现滚动更新，nginx的升级，创建一个新的，删除一个老的。

pod控制器

replicaset，deployment（声明式的管理，支持二级，水平扩容，HPA自动扩展伸缩，比如cpu控制在多少范围之内）（只能管理无状态的）

statefulset（有状态的）daemonset job（不需要一致运行的） ctonjob（确保始终运行的）

为了确保不同的需求被用户使用

node节点启动此pod

pod不是原来的pod了，客户端怎么去访问呢，地址变化了，主机名也变了怎么办？服务发现功能

理解为一个登记表，哪个人走了，哪个人来了需要登记一下

怎么做？每一组提供了service（标签选择器）用标签来实现

动态探测端口的是什么，客户端的请求，service只是一个iptable的xxx规则，可以在协议栈进行相应，service名解析成ip，DNSpod
（基础型的附件pod）
addons：附件，插件
k8s的附件dns只是其中一个，还会动态生成，解析的service（端口代理实现）
LVS做负载均衡1.11版当中将iptable改成LVS规则，公网，内网，高防的防火墙，

k8s是机房，集群地址就行啦，固定访问入口

物理节点----转发到service—LBaas（负载均衡及服务）

基础云计算的调度器，将k8s运行在阿里云

每一个都有一个service（调度流量） 控制器来创建（nginx有自己的） 控制器通过标签

定义一个nginx控制器，控制器（维持4个nginx）创建pod，在创建个service。

k8s基本组件，因为有生命周期所以不固定，所以抽象出来一个service，controller，标签和标签选择器

节点网络 service是vip （集群网络） pod以IP地址(pod网络）

pod之间的通信，多个容器间的通信

pod的节点地址，节点地址，pod节点不冲突，物理桥接

overlay network（隧道叠加网络，二层叠加，三层报文）
pod之间的通信，docker0桥，172,.17网段，二层网络中

云计算最难理解在网络中

pod之间不会直接通信，有生命周期有service，pod有pod网络，service有service网络，service地址只是iptable规则中的地址，指向网关（docker0桥的地址） 通过iptables规则表，pod改变通过标签选择器，ipvs，iptables，需要专门的组件，kube-proxy（随时与apiserver通信） 反应在iptables ipvs里面，kube-proxy
动态管理apiserver存在etcd中（三节点，类似于zookeeper）

通过https通信

一个内部通信，一个外部通信，证书

api server：https通信 有证书（CA） 签署证书

通信间都需要证书，手动创建5套CA（）二进制部署，双向认证，客户端，服务端认证，双向认证，apiserver集群

三层网络架构：节点网络，集群网络，pod网络（插件化）

CNI（容器网络接口）：flannel 网络策略功能

namespace：管理的边界 ，可以定义iptables规则

网络策略和网络功能是两个东西

calico：支持网络配置，网络策略（3层隧道网略）

flannel简单，不支持网络策略，
calico：困难
canal：第一种提供网路，第二种提供策略

k8s一共3年，kubeadm安装部署（简单）把除了kubelet都容器化，并且托管到gcr的镜像仓库当中gcr：不能直接访问。

minikube（不适用）

还是使用使用kubeadm

flannel默认10.244
service：10.96.0.0/12

kubelet：在外面安装

系统级守护进程：不好，繁琐而复杂

手动部署至少需要一天 github上面有简单的部署方式，都是系统级的守护进程

将k8s的核心组件也部署为node

kubelet+docker在外面

master：etcd api server schedler controller都是pod
node：proxy

这些都是静态pod：不是自托管pod
每一个节点都要部署fannel，以便于可以互相通信（不是静态pod，由k8s管理）
也可以做自托管，不过不好理解

kops组件 kubeadm（管理工具，部署用的）

kube-proxy dns addon（附件）

bootstrap引导启动过程

步骤

• master，node安装kubelet kubeadm docker

• master：kubeadm init

• node：kubeadm join

时间同步是基础服务

部署

pod service replicaset state

taint：污点 能容忍就可以加入

describe：描述
logs
exec
attach
port-forward：端口转发
apply
wait
label
annotate：注解（长度不受限）

kubectl
kubectl cluster-info
corcedns kube-proxy fannel

kubectl run nginx-deploy（控制器名称） --image=nginx：1.14-alpine replicas=5（5个）  restart=Never（自动补充） --schedular
deployment job：pod的控制器

kubectl get deployment（期望起多少个）

kubectl get

kubectl expose （暴露端口）

kubectl get svc（service）

集群ip（service）集群内部访问

支持curl +服务名

yum -y install bind-utils

控制器动态修改的myapp具体在哪个节点上需要调度器来决定

-o wide

kubectl rollout 回滚操作

监控系统的部署

用yaml文件定义资源

iptables -vnl nat模式 网络地址转换

• 资源：对象

• workload：pod replicaset deployment daemonset job（工作负载型资源）

• 服务发现及服务均衡service

• 配置与存储：volume CSI ceph

• configmap（配置中心）

• secret（保存敏感资源）

• downwardapi

• 集群级的资源 ：namespace，noderole clusterrode（集群角色） rolebinding 集群角色绑定

• 提供元数据 元数据型资源 HPA（自动调整元数据的信息）

• podtemplate 进行资源限制

还可以使用配置清单来创建

apiversion

api server只接受接送格式相比于yaml比较重量

只需要缩进就可以了
通过yaml文件提供配置清单，api server可以自动转成json

核心的配置清单由：
apiversion（kubectl api-version），kind（资源类别），metadata：元数据（name，namespace，labels），annitations（资源注解）