云原生技术的了解
参考资料
什么是云原生
- 云原生应用架构的几个主要特征：
- 符合12因素应用
- 面向微服务架构
- 自服务敏捷架构
- 基于API的协作
- 抗脆弱性
- 到了2015年Google主导成立了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：
- 应用容器化
- 面向微服务架构
- 应用支持容器的编排调度
- 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
- 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。
- 云原生本身甚至不能称为是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。
- 云原生系统的设计理念如下:
- 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
- 面向配置设计（Configuration）：一个镜像，多个环境配置；
- 面向韧性设计（Resistancy）：故障容忍和自愈；
- 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
- 面向交付设计（Delivery）：自动拉起，缩短交付时间;
- 面向性能设计（Performance）：响应式，并发和资源高效利用；
- 面向自动化设计（Automation）：自动化的 DevOps；
- 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
- 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；
- 云原生基础设施不等于在公有云上运行的基础设施。光是租用服务器并不会使您的基础设施云原生化。
- 云原生不是指在容器中运行应用程序。
- 不意味着您只能运行容器编排器（例如Kubernetes和Mesos）。容器编排器提供了云原生基础设施所需的许多平台功能，但并未按预期方式使用这些功能，这意味着您的应用程序会在一组服务器上运行，被动态调度。
- 编排器负责集群中的所有资源利用（例如：存储，网络和CPU）。该术语典型地用于描述执行许多任务的产品，如健康检查和云自动化。
- 调度器是编排平台的一个子集，仅负责选择运行在每台服务器上的进程和服务。
- 云原生不是微服务或基础设施即代码。
- 云原生应用程序也改变了应用程序和基础设施之间的关系。
- 云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。
- 弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。
- 敏捷性允许快速部署和快速迭代。
- 可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。
- 可观察性提供信息来回答有关应用程序状态的问题。
- 微服务、健康报告、遥测数据、弹性、声明式的，而不是命令式的
- 提供健康检查的应用程序示例包括Zookeeper的ruok命令和etcd的HTTP / 健康端点。
- 我们将在云原生应用程序中考虑弹性的两个主要方面：为失败设计和优雅降级。
- 尽管优雅的降级和失败处理都应该在应用程序中实现，但平台的多个层面应该提供帮助。
- 在云原生应用程序中，与任何事物进行通信的方式都是通过网络进行的。很多时候，网络通信都是通过RESTful HTTP调用完成的，但它也可以通过其他接口（如远程过程调用（RPC））来实现。
- Serverless: 无服务器平台是云原生化的，并通过设计对事件做出响应。他们在云中工作得很好的原因是他们通过HTTP API进行通信，是单用途功能，并且在他们所称的功能中声明。该平台还可以通过在云中进行扩展和访问来提供帮助。
- 云原生应用程序不能直接在PaaS上运行或与服务器的操作系统紧密耦合。它们期望在一个拥有大多数自治系统的动态环境中运行。
- 云原生基础设施在提供自主应用管理的IaaS之上创建了一个平台。该平台建立在动态创建的基础设施之上，以抽象出单个服务器并促进动态资源分配调度。
- 云原生是关于不需要人类做出决定的自治系统。它仍然使用自动化，但只有在决定了所需的操作之后。只有在系统不能自动确定正确的事情时才应该通知人。
- 云原生应用程序不依赖于人员设置ping检查或创建Syslog规则。他们需要从选择基本操作系统或软件包管理器的过程中提取自助服务资源，并依靠服务发现和强大的网络通信来提供丰富的功能体验。
- 云原生准确来说是一种文化，更是一种潮流，它是云计算的一个必然导向。它的意义在于让云成为云化战略成功的基石，而不是阻碍，如果业务应用上云之后开发和运维人员比原先还痛苦，成本还高的话，这样的云我们宁愿不上。
- 云原生也很好地解释了云上运行的应用应该具备什么样的架构特性——敏捷性、可扩展性、故障可恢复性。
- 敏捷, 可靠, 高弹性, 易扩展, 故障隔离保护, 不中断业务持续更新
- Kubernetes是Google基于Borg开源的容器编排调度引擎，作为CNCF（Cloud Native Computing Foundation）最重要的组件之一，它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动得达到和维持在这个状态。
- Kubernetes 用户可以通过编写一个yaml或者json格式的配置文件，也可以通过工具/代码生成或直接请求Kubernetes API创建应用，该配置文件中包含了用户想要应用程序保持的状态，不论整个Kubernetes集群中的个别主机发生什么问题，都不会影响应用程序的状态，你还可以通过改变该配置文件或请求Kubernetes API来改变应用程序的状态。
- restful api 详解
- Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了Service资源，并通过kube-proxy配合cloud provider来适应不同的应用场景。应用场景：
- Service：直接用Service提供cluster内部的负载均衡，并借助cloud provider提供的LB提供外部访问
- Ingress：还是用Service提供cluster内部的负载均衡，但是通过自定义LB提供外部访问
- Service Load Balancer：把load balancer直接跑在容器中，实现Bare Metal的Service Load Balancer
- Custom Load Balancer：自定义负载均衡，并替代kube-proxy，一般在物理部署Kubernetes时使用，方便接入公司已有的外部服务
- Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
- 技术路线: 容器->Kubernetes->微服务->Cloud Native（云原生）->Service Mesh（服务网格）->使用场景->Open Source（开源）。
- Kubernetes是容器编排系统的事实标准, Kubernetes——让容器应用进入大规模工业生产。
- Kubernetes有机会成为跨云的真正的云原生应用的操作系统。
- 包括微服务和FaaS/Serverless架构，都可以作为云原生应用的架构。
- 当前最成熟最完整的微服务框架可以说非Spring莫属，而Spring又仅限于Java语言开发，其架构本身又跟Kubernetes存在很多重合的部分，如何探索将Kubernetes作为微服务架构平台就成为一个热点话题。
- Kubernetes中则可以使用DNS、Service和Ingress来实现，不需要修改应用代码，直接从网络层面来实现。
- 我们知道Kubernetes中的所有应用的部署都是基于YAML文件的，这实际上就是一种Infrastructure as code，完全可以通过Git来管控基础设施和部署环境的变更。
- Kubernetes中的基本资源类型分成了三类：
- 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob
- 服务：Service、Ingress
- 存储：PV、PVC、ConfigMap、Secret
- Kubernetes主要由以下几个核心组件组成：
- etcd 保存了整个集群的状态；
- apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
- controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- scheduler 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
- kubelet 负责维护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的管理；
- Container runtime 负责镜像管理以及Pod和容器的真正运行（CRI）；
- kube-proxy 负责为Service提供cluster内部的服务发现和负载均衡；
- 除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：
- CoreDNS 负责为整个集群提供DNS服务
- Ingress Controller 为服务提供外网入口
- Prometheus 提供资源监控
- Dashboard 提供GUI
- Federation 提供跨可用区的集群
- 从Kubernetes的系统架构、技术概念和设计理念，我们可以看到Kubernetes系统最核心的两个设计理念：一个是容错性，一个是易扩展性。容错性实际是保证Kubernetes系统稳定性和安全性的基础，易扩展性是保证Kubernetes对变更友好，可以快速迭代增加新功能的基础。
- Kubernetes作为云原生应用的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下接口，可以分别对接不同的后端，来实现自己的业务逻辑：
- CRI（Container Runtime Interface）：容器运行时接口，提供计算资源
- CNI（Container Network Interface）：容器网络接口，提供网络资源
- CSI（Container Storage Interface）：容器存储接口，提供存储资源
- 以下列举的内容都是 kubernetes 中的 Object，这些对象都可以在 yaml 文件中作为一种 API 类型来配置:
- Pod
- Node
- Namespace
- Service
- Volume
- PersistentVolume
- Deployment
- Secret
- StatefulSet
- DaemonSet
- ServiceAccount
- ReplicationController
- ReplicaSet
- Job
- CronJob
- SecurityContext
- ResourceQuota
- LimitRange
- HorizontalPodAutoscaling
- Ingress
- ConfigMap
- Label
- CustomResourceDefinition
- Role
- ClusterRole
- Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
- Pod hook（钩子）是由Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook。
- Hook的类型包括两种：
- exec：执行一段命令
- HTTP：发送HTTP请求。
- Hook的类型包括两种：