综合上述几篇文章，从微服务架构向云原生的架构转换以及这其中的问题做出如下的总结。
1.Kubernetes的集群架构
控制节点即为master节点，其同其他架构中的master节点的作用相同，包含node controller、route controller、以及service controller。
针对node controller，主要涉及到节点的更新状态的更新，收集节点的数据信息，节点的hostname以及网络地址，核实节点的健康状态。
route controller（路由控制器）主要用于部署在k8s集群中应用的路由，以便不同的container之间可以进行数据的交换，实现完整的应用功能。
service controller整合集群中的基础设施组件的管理，比如load balancers、IP address等功能的管理。 但是别忘记，在这里一切都是container，这些服务的提供也是同样的原理，当公司内部需要对master的功能进行拓展或者修改，需要根据源码对其对应修改。如果使用的是阿里云托管的集群，master节点有对应的托管管理办法，但是其功能是针对master的节点，部署微服务到对应的节点。 这里插入一点，阿里云的k8s相关内容使用go编写的，之后是对其代码的组织架构进行说明。 node 上的组件主要包括几个部分，分别是kubelet kube-proxy container runtime dns等其他部分。
2.微服务应用的持续性部署和交付过程
请牢记这张图，他包含了Kubernetes中基本的概念以及其中的关系，通过他，即可追根溯源。
利用大家看得懂的简单的语言来说，就是pod就是我们微服务中的部署单元（单个服务，服务类型未知），单个服务在集群中的部署以及交付在Kubernetes集群中存在两种方式或者成为形态，分别是deployment以及stateful set。如下图所示。
关于服务的部署，pod的实际运行即为服务的运行，关于后续的服务升级，其中以deployment形式部署的服务，利用deployment以及replica set完成服务的rolling。(replica set副本数量集，即replica set的数量即为pod的个数) replica set是为了管理相同的可替换的pods而设计，而stateful set是为管理不可替换的独特服务（含有不同的数据）而设计。 其中以stateful set形式运行的服务，其中多副本的stateful set中每个pod所承载的数据都不相同，其中涉及到服务的升级以及可并行的服务的数量以及数据的扩容等问题。见下图，其中identity是其他pod保证运行的元构建块。（当然可以设置单副本的stateful set）针对多副本的stateful set的相关问题会在后续文章中涉及。
3.微服务应用的访问以及各服务间的访问
服务发现策略（service discovery）
**3.1集群内部的服务发现 **
Kubernetes运行一个DNS服务器，所有pod都可以自动配置使用。当一个新的服务被创建时，它会自动获得一个新的DNS条目，所有的Pods都可以开始使用（或者成为可以获取其地址）。假设客户端知道它想要访问的服务的名称，它可以通过一个完全限定的域名(FQDN)到达服务，比如random-generator.default.svc.cluster.local。
cluster IP
DNS lookup
3.2集群内部访问外部系统
直接使用外部地址，但是需要将该地址封装成服务进行访问
使用域名访问.
这个Service定义只使用DNS映射到externalName所指向的内容。它使用DNS CNAME为外部端点创建别名的方法，而不是通过带有IP地址的代理。
使用方法见下图：其中以C处的DNS地址为结尾的任何域名，将会转到D处的DNS服务器进行解析。
这里涉及一个知识点，即A记录与CNAME记录的区别和联系。
3.3外部客户端访问集群内部服务
Node port
如何配置
Load Balance
如何配置
4.最后，从内到外解析了微服务的部署与交付，针对源码级别的设置，即container的配置做出简单的介绍。
在之前的文章就针对在分布式领域中的各国概念在对应的Kubernetes中的概念对应，其中pod与Java中的jar包对应，其中一个jar包中包含多个class，其中container的概念可以由此对应。
这里的配置是指针对pod其中的container的设置。首先或许需要针对pod进行初始化设置，可以在pod的配置文件中设置init container,同样其中的command操作进行关于pod的初始化设置，因为init container可严格在main container之前运行成功。
