K8s网络和分布式事务

Posted 2021-04-25 云架构师大白

本期主题有点混搭的意思，不过我喜欢，您呢。

 

回顾下k8s基础概念：

1、Pod

    Pod 是 Kubernetes 管理的最小工作单元，每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。一般一个pod里只允许一个容器，如果是交互非常频繁需要资源共享的容器可以放在一个pod里（pod内部容器通过localhost通信）

 

2、Controller

    Kubernetes 通常不会直接创建 Pod，而是通过Controller 来管理和运行这个后 Pod 的。Controller中定义了 Pod 的部署特性，比如有几个副本，在什么样的Node（虚拟机或物理机）上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment（创建pod）、ReplicaSet（多副本管理）、DaemonSet（每个node只允许一个该类型的pod，一般用于监控代理日志采集代理等）、StatefuleSet、Job （结束既删除的应用，如定期任务类）等

 

3、Service

    Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service为 Pod 提供了负载均衡。又可以分为如下几种：

ClusterIP 
    Service 通过 Cluster 内部的 IP 对外提供服务，只有 Cluster 内的节点和 Pod 可访问

NodePort 
    Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过 <NodeIP>:<NodePort> 访问 Service。Nodeport和clusterip底层实现都是iptables，Nodeport是将node节点IP负载到一组pod，clusterip是将一个内部ip负载到一组pod

LoadBalancer 
    Service 利用 cloud provider 特有的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。支持的 cloud provider 有 GCP、AWS、Azur 等。

     

4、Namespace

    实现资源逻辑上的隔离，实现多租户。Kubernetes默认创建了两个 1、 Namespace。default -- 创建资源时如果不指定，将被放到这个 Namespace 中。2、kube-system -- Kubernetes 自己创建的系统资源将放到这个 Namespace 中。

 

5、master节点

    Master 是 Kubernetes Cluster 的大脑，运行的服务有kube-apiserver（提供API）、kube-scheduler（调度pod在哪个node）、kube-controller-manager(负责管理各类资源，如Deployment、StatefulSet、DaemonSet等)、etcd （负责保存配置信息）和 Pod 网络（本文讨论的重点后面再说）。

 

6、node节点

    Node 是 Pod 运行的地方，Kubernetes 支持 Docker、rkt 等容器Runtime。Node上运行的 Kubernetes 组件有 kubelet（接收Scheduler信息创建和管理pod）、kube-proxy（负责接收service的请求并负载到实际容器） 和 Pod 网络。

 

7、HealthCheck

    包括Liveness （探测是否存活以便重启服务自愈）和Readiness(探测服务状态是否为ready，是否可以对外提供服务，可用于滚动升级、服务是否就绪是否可以加入service)

 

8、helm

    完成复杂的容器逻辑编排能力，并可以做到高度复用

 

9、其他

    普罗米修斯监控、日志采集

 

10：K8s网络

    K8s是通过CNI插件，可以选择不同的网络插件，常用的如下

Calico:采用iptables走BGP实现通信，没有走opverlay性能更好，同时支持ACL。（生产使用）

 

 

事务

• 单机事务

单机事务的acid属性（理论，具体实现不一定能全部满足）

原子性：事务中的所有操作要么成功，要么回退undo

一致性：

隔离性：分为不同的隔离级别，事务隔离级别分为串行化、可重复读、读已提交、读未提交。性能依次变强、问题依次变多。

事务隔离级别	脏读	不可重复读	幻读
读未提交:一个事务修改了数据但是还没有commit就允许其他事务读修改的内容 这样如果回滚会造成脏读，也就是你读到了一个脏数据。	是	是	是
读已提交：一个事务操作过程中可以读取到其他事务已经提交的最新数据。大多数关系型数据库默认使用（oracle\sqlserver） 会造成不可重复读，如一次事务两次读之间数据被修改会造成两次读的数据不一致，既造成不可重复读。	否	是	是
可重复读: 一个事务操作中对于一个读取操作不管多少次，读取到的结果都是一样的。mysql默认的模式，采购了间隙锁锁住查询的范围，防止其他事务插入数据。 会造成幻读：如事务A修改表中所有某字段值为0然后查询值，但是同时有另一个事务修改值为1，会造成事务A查询的值是1，好像产生了幻觉	否	否	是
串行化:事务依次排队执行	否	否	否

 

持久性：事务执行完成后就是持久的，不会因为故障等原因被破怪。比如redo binlog写入完成才能代表事务执行完成

 

1.2 mysql为什么默认隔离级别是可重复读

    因为老的主从复制模式只有statement（记录的SQL语句）一种方式，这种在使用读已提交的隔离模式时可能会出现从库数据错乱问题。

    新版本的mysql主从复制请使用row（记录的是数据变化）方式，不会出现上述问题，请修改隔离级别为读已提交。

 

• 分布式事务

    概念：首选说下分布式数据库的CAP原理，既在保障P分区的情况下，强一致性和可用性只能满足其中一个，如数据同步就相当于选择了一致性放弃了可用其，采用最终一致性（柔性事务）的方案就相当于选择了可用性放弃了强一致性。

 

2.1 分布式事务可以分为如下三种形式：

1、单服务多数据库

2、单服务分库分表：一般可通过mycat等类似中间件进行数据库分片和分布式事务

3、多服务多数据库

 

2.2 分布式事务解决方案

TCC：第一步查询检测做资源预留，第二步确认提交，失败则补偿回滚。实际这种方式还是有问题的。

可靠消息最终一致性：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态。目前只有rocketMQ实现了分布式事务消息的支持。推荐这种方式

最大努力通知：主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。当然通知失败需要有记录可以查询到即可。