Day02 关于CNCF、还有一些侧重点

CNCF

云原生是什么？
云原生（Cloud Native）是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
关键组成要素：
容器化：容器化为微服务提供实施保障，起到应用隔离作用。每一个服务都能被封装到容器里，可以无差别地管理和维护。
微服务：微服务的本质是把大块的应用拆分成多个低耦合的小服务。这样，每个小服务出现问题时，其他服务还能正常提供服务。
DevOps：包含开发和运维两个方面，旨在打破传统开发和运维之间的壁垒，实现更高效的协同工作。
持续交付：在不影响用户使用服务的前提下，频繁地把新功能发布给用户使用。
这四个方面包含了12个要素。
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
云原生是做什么的？
云原生（Cloud Native）是一种构建和运行应用程序的方法，它充分利用了云计算提供的优势，如弹性、可扩展性、可靠性、安全性和高效性。云原生应用程序是专为云环境而设计的，它们能够快速地适应和响应变化，无论是在开发、测试还是生产环境中。

云原生主要涵盖了以下几个关键领域：

容器化：
容器技术（如Docker）是云原生的基石之一。容器允许开发者将应用程序及其依赖项打包成独立的单元，这些单元可以在任何支持容器的环境中运行，从而实现了应用程序的标准化和可移植性。
微服务架构：
微服务是一种将应用程序拆分成多个小型服务的架构模式。每个服务都运行在独立的进程中，并通过轻量级的通信机制（如REST API或消息队列）进行通信。这种架构模式使得应用程序更加灵活、可维护，并且能够更好地适应变化。
DevOps：
DevOps是一种强调开发和运维之间协作和沟通的文化、方法和技术。它打破了传统开发和运维之间的壁垒，使得团队能够更快速地响应变化，提高交付速度和质量。云原生应用程序的开发和运维通常采用自动化工具和技术，如持续集成/持续部署（CI/CD）流水线、自动化测试和监控等。
可观察性和监控：
云原生应用程序需要具备强大的可观察性和监控能力，以便及时发现和解决问题。这包括收集和分析日志、度量指标和跟踪信息，以便了解应用程序的运行状态和性能。
自动化：
云原生强调自动化，以减少手动操作和降低出错率。自动化可以应用于许多方面，如部署、测试、监控、扩展和恢复等。
服务网格：
服务网格是一个用于处理服务间通信的专用基础设施层。它负责处理跨服务调用、路由、重试、熔断、限流和监控等任务，使得开发者可以更加专注于业务逻辑的实现。
云原生存储：
云原生存储解决方案为应用程序提供了高可用、可扩展和持久化的数据存储能力。这些解决方案通常基于分布式存储技术，如Kubernetes的持久卷（Persistent Volumes）和分布式文件系统（如Ceph）。
通过采用这些技术和方法，云原生应用程序能够更好地适应快速变化的环境，提高交付速度和质量，并降低运维成本。它们可以快速地响应业务需求，扩展资源以满足不断增长的工作负载，并在出现故障时迅速恢复服务。因此，云原生已成为现代软件开发和运维的重要趋势之一。
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
CNCF是什么？
CNCF基金会，全称Cloud Native Computing Foundation（云原生计算基金会），是一个开源协作，旨在推进云原生技术的普及和应用。以下是对CNCF基金会的详细介绍：

一、成立背景与宗旨

CNCF成立于2015年12月11日，其宗旨是坚持和整合开源技术来让编排容器作为微服务架构的一部分，推动云原生应用的发展和普及。云原生计算是一种利用云计算交付模型的优势来构建和运行应用的方式，通过容器化、微服务、DevOps等技术，实现应用程序的快速迭代、高可扩展性和弹性伸缩。

二、核心组件与特性

CNCF基金会主要关注云原生技术的开源协作和推广，其核心组件包括多个开源项目和工具，其中最著名的是Kubernetes。Kubernetes是一个开源的容器编排系统，用于自动化部署、扩展和管理容器化应用程序。CNCF基金会还支持其他与云原生相关的开源项目，如Prometheus（监控和告警）、Envoy（服务网格）、Helm（包管理器）等。

三、合作与生态系统

CNCF基金会与全球范围内的云原生技术公司、开源项目、研究机构等建立了广泛的合作关系，共同推动云原生技术的发展。这些合作伙伴包括Google、Microsoft、Amazon等大型云计算公司，以及诸多开源项目的贡献者和用户。CNCF基金会通过合作，形成了一个庞大的云原生生态系统，为用户提供了丰富的技术选择和支持。

四、认证与培训

CNCF基金会提供了云原生技术的认证和培训服务，以帮助企业和个人提升在云原生领域的技术能力和竞争力。例如，CNCF基金会提供了Certified Kubernetes Administrator（CKA）和Certified Kubernetes Application Developer（CKAD）等认证项目，以验证个人在Kubernetes领域的专业知识和技能。此外，CNCF基金会还提供了各种在线课程、研讨会和文档等培训资源，帮助用户学习和掌握云原生技术。

五、社区与活动

CNCF基金会拥有一个庞大的全球社区，包括数千名活跃的贡献者、用户和支持者。社区成员通过GitHub、Slack、邮件列表等渠道进行交流和协作，共同推动云原生技术的发展和应用。此外，CNCF基金会还定期举办各种活动和会议，如KubeCon+CloudNativeCon（云原生大会）等，聚集全球的云原生技术爱好者、开发者、企业和机构，分享最新技术动态和实践经验。

综上所述，CNCF基金会是一个致力于推进云原生技术发展的开源协作组织，通过支持开源项目、建立合作关系、提供认证和培训服务以及举办社区活动等方式，推动云原生技术的普及和应用。
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.

十二要素

当然，以下是云原生十二要素的具体说明，按照分点表示和归纳的形式进行整理：

1. 基准代码（Codebase）
定义：一份基准代码，多份部署。基准代码是控制系统中代码仓库的参考点，在分布式版本控制系统中，它指的是最上游的代码仓库。
实践：所有部署的基准代码保持一致，但每个部署可以使用其特定版本。
2. 依赖（Dependencies）
定义：显式声明依赖关系。应用程序不会隐式依赖系统级类库，而是通过“依赖清单”明确声明所有依赖项。
实践：在容器应用中，应用的依赖、环境的依赖和软件的安装等，都是通过Dockerfile来完成声明的。
3. 配置（Config）
定义：将应用的配置存储于环境变量中。环境变量允许应用程序在不同的部署间修改配置，而不需要改动代码。
实践：判断一个应用是否正确地将配置排除在代码之外，可以检查其基准代码是否可以立即开源而不泄露敏感信息。
4. 后端服务（Backing Services）
定义：把后端服务当作附加资源。后端服务是程序运行所需的各种通过网络调用的服务，如数据库、消息队列等。
实践：对应用程序而言，本地或第三方服务都是附加资源，通过统一资源定位器(URL)或其他存储在配置中的服务定位/服务证书来获取数据。
5. 构建、发布、运行（Build, Release, Run）
定义：严格区分构建、发布、运行三个阶段。
实践：直接修改运行中的代码通常是不推荐的，因为这很难同步回构建阶段。部署工具应提供发布管理功能，如回退到之前稳定的发布版本。
6. 进程（Processes）
定义：以一个或多个无状态进程运行应用。
实践：任何需要持久化的数据都应存储在后端服务中，如数据库。
7. 端口绑定（Port Binding）
定义：通过端口绑定提供服务。
实践：应用通过端口绑定来提供服务，无需依赖任何网络服务器即可创建一个面向网络的服务。
8. 并发（Concurrency）
定义：通过进程模型进行扩展。
实践：应用进程借鉴Unix守护进程模型进行设计，以支持并发操作。
9. 易处理（Disposability）
定义：快速启动和优雅终止，最大化健壮性。
实践：应用进程应可分解，可以瞬间开启或停止，以支持快速、弹性伸缩应用。
10. 开发环境与生产环境等价（Dev/Prod Parity）
定义：尽可能保持开发、预发布、线上环境相同。
实践：缩小本地和生产环境的差异，要求不同环境下的后端服务也要一致。
11. 日志（Logs）
定义：把日志当作事件流。
实践：日志使得应用程序运行的动作变得透明，不应考虑存储到自己的输出流，而应使用统一的日志记录工具。
12. 管理进程（Admin Processes）
定义：把后台管理当作一次性进程运行。
实践：一次性管理进程应该和正常的常驻进程使用同样的环境。
这些要素为云原生应用的开发、部署和维护提供了一套指导原则，有助于确保应用程序的健壮性、可扩展性和可维护性。
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.

框架的分类

application definition & image build 应用定义和镜像构建
helm
artifactHub
backstage
 buildpacks.io
kubevirt
kubevela
dapr
Continuous integration & Delivery 持续集成交付工具
argo
flux
keptn
jenkins
openkruise
tekton
spinnaker
Database
kv
vitess
druid
tidb
druid
oceanbase
hadoop
starrocks
Streaming & Messaging 实时计算和消息推送
spark
akka (spark内置有)
flink
kafka
pusar
cloudevents
strimzi
storm 大数据实时计算框架
talend
kubeMQ
Scheduling & Orchestration
KEDA (hPa 的扩展框架)
K8S
karmada （多集群管理框架）
Knative(下一个十年的技术，按需走向 serviceless 无服务器框架）
volcano
nomad(被誉为可以取代k8s的框架)
openNebula
koordinator(调度框架，k8s的补充)
kube-green(扫描框架)
Service Mesh
istio
LiNKERD
consul（注册框架）
remote Procedure call
grpc
service proxy
envoy
metaIlB
Haproxy -代理
nginx
OpenResty
OpenELB
OpenResty(nginx二次开发)
Sentinel
gateway 网关
ingress
APISIX (轻量级-网关匹配）
Higress
Kong
Coordination & service discovery 服务解析
coredns
etcd
Apache Zookeeper
nacos
cloud native storage 存储
rook
cubeFS（很重要）
LONGHORN
csi
ceph
swift
minio(k8s的备份和prometheus 高可用)
Gluster
Alluxio
Cloud Native Network 网络
cilium(非常重要)
cni
flannel
calico
ovs
weave (容器跨主机通信)
container runtime 容器运行时
cri-o
containerd
isulad
gVisor(加固containerd)
Security & compliance 安全这块掌握一款
Falco (k8s扫描框架)
kyberno
trivy（镜像代码扫描）
kube-bench(k8s测试框架，也可以做扫描)
terrascan
container regisrty 镜像仓库
harbor
Automation & configuration
kubeEdge 边缘计算 - 最好会
ansible
apollo
puppet
CFEngine
Terraform(只能在云上用)
openstack
Key Management 证书生成工具
spiffe
Observability
fluentd 收集日志
JAEGER 调用链
cortex 可以做Prometheus的高可用
Prometheus
thanos（可做prometheus高可用）
OpenTelemetry
Elastic
garfana
Grafana Loki
HertzBeat 集大成者 可以做prometheus的异地存储
pixie 链路监控工具
sensu
skywalking
chaos engineering 混沌工程
CHAOS MESH 项目压测
rainbond(信创比例不低 要学)
rancher
kubersphere