最近参加了极客时间的云原生培训，准备写点东西记录下学习心得，并且对一些需要深挖的点做个记号
想想自己也做了将近4年的DevOps，猛然被这么一问不禁有点懵，忙了半天，什么是云原生呢

什么是云原生

课堂笔记

• 在公有云、私有云、混合云等动态环境中的构建和运行规模化应用的能力
• 云原生是一种思想，是技术、企业管理方法的集合
  • 技术层面
    • 应用程序从设计之初就为在云上运行而做好准备
    • 云平台基于自动化体系
  • 流程层面
    • 基于DevOps， CI/CD
• 基于多种手段
  • 应用容器化封装
  • 服务网格
  • 不可变的基础架构
  • 声明式API
• 云原生的意义
  • 提升系统适应性、可管理性、可观察性
  • 使工程师能以最小的成本进行频繁和可预测的系统变更
  • 提升速度和效率，助力业务成长，缩短I2M （Idea to Market）

深入理解

查了一些资料，似乎并没有云原生的确切定义，比较合意的解释来自英文Cloud Native is Patterns
换成中文的话，差不多就是云原生是一套技术体系和方法论，它生在云上，长在云上。它涵盖了很多，并且随着时间推进，它的定义也在不断完善更新。云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径

Patterns for What

• Availability - Micro-services for everyone
• Automation - Deployment & Management
• Acceleration - CI/CD & “the ABCDE” of automation
• Anywhere! - Containers are portable

云原生的一些要素

• 微服务
  几乎每个云原生的定义都包含微服务，切分微服务的时候，需要遵循的准则是高内聚，低耦合
• 容器化
  上云第一件事应该就是容器化了，所谓容器化实际上是一种轻量级的虚拟化技术。只不过相对于VM，属于进程级别的隔离（通过linux namespace实现），而K8S则是容器编排技术
• DevOps
  不打算把持续交付列进去，因为即使不上云，持续交付也是运维人员的功课。但是DevOps是在云原生中应运而生的。它的理念在我看来就是为云原生量身定制的

尝试

当自己动手开始写一个operator的时候，还是可以学到很多东西，也会发现自己的golang基础并不牢固，很多时候写代码还是要靠查文档。收获也很大，可以巩固go语言，也对k8s的operator模式有了深入的了解。
摘了一段别人的总结，非常简短但是到位

The k8s api raise events when a resource is created, edited and deleted. By Watching Resources we can re-trigger the reconcile to ensure a desired stated on the cluster.

You can define them in the function SetupWithManager that you can find in the controller.go. In the following example, we will be setting up controller Watches in a simplified way which has the controller Builder:

func (r *KindReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&cachev1alpha1.MyKind{}). // primary ( API defined in the Operator ) to be watched.
        Owns(&appsv1.Deployment{}). // secunary resources to be watched. 
        Complete(r)
}
When developing operators, it is essential for the controller’s reconciliation loop to be idempotent. By following the Operator pattern you will create Controllers which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster. Breaking this recommendation goes against the design principles of controller-runtime and may lead to unforeseen consequences such as resources becoming stuck and requiring manual intervention.

Reconcile()

The reconcile function is responsible for synchronizing the resources and their specifications according to the business logic implemented on them. In this way, it works like a loop, and it does not stop until all conditionals match its implementation. The following is pseudo-code with an example that clarifies it.

reconcile App {
 
   // Check if a Deployment for the app exists, if not create one
   // If has an error, then go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{}, err 
   } 
    
   // Check if a Service for the app exists, if not create one 
   // If has an error, then go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{}, err 
   }  
 
   // Looking for Database CR/CRD 
   // Check the Database Deployments Replicas size
   // If deployment.replicas size != cr.size, then update it
   // Then, go to the beginning of the reconcile
   if err != nil {
       return reconcile.Result{Requeue: true}, nil
   }  
   ...
    
   // If it is at the end of the loop, then:
   // All was done successfully and the reconcile can stop  
   return reconcile.Result{}, nil
 
}
The following are a few possible return options to restart the Reconcile:

With the error: return ctrl.Result{}, err
Without an error: return ctrl.Result{Requeue: true}, nil
Therefore, to stop the Reconcile, use: return ctrl.Result{}, nil
Reconcile again after X time: return ctrl.Result{RequeueAfter: nextRun.Sub(r.Now())}, nil

我和云原生

在做DevOps之前，我大概做了六七年的软件测试工程师。
大概四年前，正好赶上公司转型，从一个拥有大型本地数据中心的重型公司转变成一个“云上”公司，公司的大部分业务，在拆分的时候都搬上了公有云。我在那时，加入了DevOps，何其有幸，目睹了公司的蜕变
我们先做的是将服务拆分成微服务，然后将各个微服务容器化，期间也在CICD上一步步探索提升，从自动发布到云上的虚拟机，到后来自动发布到公有云的k8s集群，从手动触发发布，到全自动PR触发
到现在，我们专注于监控，自动告警，OC，SLA/SLO，以及在此过程中敏捷的注入。回看起来，似乎有高人在背后指点，我们所做的每一步都契合着云原生
随着队伍的壮大，我们的版图也越来越大，此时你又发现，自己所做的一切又是云原生的冰山一角。
所以，云原生，任重道远，道阻且长。
DevOps全技术栈镇楼

参考资料

https://zhuanlan.zhihu.com/p/150190166
https://www.oracle.com/cloud/cloud-native/what-is-cloud-native/
https://builtin.com/cloud-computing/what-is-cloud-native