Download: 极客时间云原生训练营|最新高清
云原生介绍
伴随云计算的滚滚浪潮，云原生（Cloud Native）的概念应运而生，云原生很火，火得一塌糊涂，都9102年了，如果你还不懂云原生，那真的Out了。
什么是云原生？
云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。
Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
云原生为什么越来越重要？
未来的天下，一定是云原生的
未来的软件，从诞生起，就是生在云上，长在云上的。这个说法绝对不是没有根据的，看看现在的互联网大厂在做的事情，你就知道了：
Kubernetes 作为云原生的核心平台，吸引了越来越多的程序员去了解、学习、掌握它。我知道的很多人，因为会使用 Kubernetes，跳槽薪资非常不错。
云原生Kubernetes实战开发
Flink on TKE 半托管服务，极致的Flink云原生使用体验
Flink on TKE 半托管服务提供了Flink集群部署、日志、监控、存储等一站式的服务，用户可以将其他在线业务与Flink运行在同一个集群中，从而最大程度提高资源资源使用率，达到统一资源、统一技术栈、统一运维等能力。
我们基于 TKE 容器平台构建 Flink Kubernetes 计算集群。根据已有的 Flink 作业运行情况，我们发现绝大多数 Flink 作业主要是耗费内存，而CPU利用率普遍较低，在机型选择上我们推荐选择内存型机器。
apiVersion: flinkoperator.Kubernetes.io/v1beta1
kind: FlinkCluster
metadata:
name: flink-hello-world
spec:
image:
name: flink:1.11.3
jobManager:
resources:
limits:
memory: "1024Mi"
cpu: "200m"
taskManager:
replicas: 2
resources:
limits:
memory: "2024Mi"
cpu: "200m"
job:
jarFile: /opt/flink/examples/streaming/helloword.jar
className: org.apache.flink.streaming.examples.wordcount.WordCount
args: ["--input", "/opt/flink/README.txt"]
parallelism: 2
flinkProperties:
taskmanager.numberOfTaskSlots: "2"通过上述的声明式 API 方式提交部署，我们可以看到用户 jar 包需要事先打到 image 里，作为平台提供方，当然不可能让每个用户自己去打 docker image，有些用户甚至都不知道怎么用 docker，所以我们应该对用户屏蔽 docker image，用户只需要上传 jar 包等资源即可。Flink Operator 提供了 initContainer 选项，借助它我们可以实现自动下载用户上传资源，但是为了简单，我们直接修改 docker entrypoint 启动脚本，先下载用户上传的资源，再启动 Flink 相关进程，用户上传的资源通过环境变量声明。例如：
apiVersion: flinkoperator.Kubernetes.io/v1beta1
kind: FlinkCluster
metadata:
name: flink-hello-world
spec:
image:
name: flink:1.11.3
envVars:
- name: FLINK_USER_JAR
value: hdfs://xxx/path/to/helloword.jar
- name: FLINK_USER_DEPENDENCIES
value: hdfs://xxx/path/to/config.json,hdfs://xxx/path/to/vocab.txt
...极客时间云原生训练营 - Kubernetes 架构
Kubernetes 最初源于谷歌内部的 Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理 / 虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
// ImageService defines the public APIs for managing images.
service ImageService {
// ListImages lists existing images.
rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {}
// ImageStatus returns the status of the image. If the image is not
// present, returns a response with ImageStatusResponse.Image set to
// nil.
rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {}
// PullImage pulls an image with authentication config.
rpc PullImage(PullImageRequest) returns (PullImageResponse) {}
// RemoveImage removes the image.
// This call is idempotent, and must not return an error if the image has
// already been removed.
rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {}
// ImageFSInfo returns information of the filesystem that is used to store images.
rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {}}
极客时间云原生训练营 - Kubernetes集群扩展
使用自定义资源扩展 API
自定义资源是对 Kubernetes API 的扩展，kubernetes 中的每个资源都是一个 API 对象的集合，例如我们在 YAML 文件里定义的那些 spec 都是对 kubernetes 中的资源对象的定义，所有的自定义资源可以跟 kubernetes 中内建的资源一样使用 kubectl 操作。
TPR
假如我们要创建一个名为 cron-tab.stable.example.com 的 TPR，yaml 文件定义如下：
apiVersion: extensions/v1beta1
kind: ThirdPartyResource
metadata:
name: cron-tab.stable.example.com
description: "A specification of a Pod to run on a cron style schedule"
versions:
- name: v1
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
name: d-tab.l5d.io
description: stores dtabs used by namerd
versions:
- name: v1alpha1CRD
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
# 名称必须符合下面的格式：.
name: crontabs.stable.example.com
spec:
# REST API 使用的组名称：/apis//
group: stable.example.com
# REST API 使用的版本号：/apis//
version: v1
# Namespaced 或 Cluster
scope: Namespaced
names:
# URL 中使用的复数名称: /apis///
plural: crontabs
# CLI 中使用的单数名称
singular: crontab
# CamelCased 格式的单数类型。在清单文件中使用
kind: CronTab