K8s云原生

组件和各自的作用

• apiserver： 入口，以RESTFul接口方式提供给外部客户和内部组件调用(可以非常方便的做定制化开发)
• scheduler： 资源调度，为新建和重启的pod分配机器。
• controller-manager: 执行各种控制器，如：定期关联 service 和 pod
• kubelet: 负责管控docker容器。它会定期从 etcd获取分配到本机的 pod，并根据 pod 信息启动或停止相应的容器。同时，它也会接收 apiserver 的 HTTP 请求，汇报 pod 的运行状态。
• kube-proxy: 为pod 提供代理。当某个客户 pod 要访问其他 pod 时，访问请求会经过本机proxy做转发。
• Container Runtime ： 容器运行时。 为真正的docker。

常用工具和指令

• Kubeadm 用于初始化安装
• Kubectl 执行k8s操作pod等等指令。 他需要手动配置自动补全
• kubectl create： 通过 yaml/json 文件或者标准输入创建一个资源对象。
• kubectl run 创建并运行一个或多个容器镜像
• kubectl explain 查看资源对象的详细信息
• kubectl get 获取一个或多个资源对象的信息
• kubectl get pod -o wide 查看pod资源
• kubectl describe 显示一个或多个资源对象的详细信息
• kubectl logs 输出 pod 资源对象中一个容器的日志
• kubectl attach 连接到一个运行的容器
• kubectl exec 在指定容器内执行命令
• kubectl label 增删改资源的标签
• kubectl get pod -w 监听pod节点变化
• watch -n 1 kubectl get pod 每隔1s执行 kubectl get pod指令。
• kubectl get sa 查看service account安全证书的内容。
• kubectl get ep 查看ip和端口，也叫端点
• kubectl get svc 查看服务和对应的CLUSTER-IP、EXTERNAL-IP
• kubectl api resouce 查看简写。
• kubectl apply/delete . 当前目录下所有的yaml文件都执行。
• kubectl rollout 暂停/继续/回滚/历史记录 ： 支持版本滚动升级和版本回退；

dashboard(仪表板)

2种登录方式： token 、kubeconf

重要概念

• node : 节点，都安装了Kubeadm, Kubelet, Kubectl,kube-proxy等等组件
• Namespace : 命名空间隔离， 4个初始命名空间： default、kube-system、kube-public、kube-node-lease
• Pod：最基本的部署调度单元，可以包含多个Container，逻辑上表示某种应用的一个实例。
• Service： 用户操作的基本单元，是真实应用服务的抽象，对应多个pod。通过 Proxy 的 port 和服务 selector 决定服务请求传递给后端提供服务的容器。
• 模型对象: 、 ReplicationController ： 复制集抽象， 保证实际运行Pod数量总是与该复制数量相等
• Label: 为pod加上一组标签，Service和RC通过Label和Pod进行关键。

Pod

• 每启动一个Pod都会附加启动基础容器（pause），它只做网络和等待挂起。
• 生命周期管理: 挂起（Pending）、运行（Running）、成功（Succeeded）、失败（Failed）、未知（Unknown）
• 重启策略 ： Always(默认策略，总是重启), OnFailure(失败重启), Never（决不重启）
• 配额（requests）和限制（limits）对应的 cpu/内存。 【当节点的资源不够时，先删除没有指定、再删除设置的不一致、最后再删除参数一致的。】
• 静态Pod ： 只受所在节点的kubelet控制，防止误删除，通常用于部署核心组件应用。
• 初始化容器 | init 容器 ：通常应用于： 初始化一些配置项，校验依赖服务。

仅当 init 容器完成后，才能运行应用容器，允许多个且顺序执行，失败触发重启策略，执行过程中是处于pending状态。

• Pod 的设计 ： 无状态和有状态分多个pod；一个pod内多个子应用，来实现一个功能；负载采用多个pod；

Pod健康检查

探测方式：

• Exec 探针：执行进程的地方，容器的状态由进程的退出状态代码0确认；
• Http get 探针：向容器发送 HTTP GET 请求，通过响应的 HTTP 状态代码判断容器是否准备好；如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的
• Tcp socket 探针：它打开一个 TCP 连接到容器的指定端口，如果连接己建立，则认为容器己准备就绪。
• gRPC 探针 ： 需要配置开启gRPC功能。 探测结果：
• 成功：容器通过了诊断。
• 失败：容器未通过诊断。 若未通过检查，则根据不同的探测类型,不同的处理方式。
• 未知：表示说当前这次检查操作没有完整执行，可能是因为超时或一些脚本没有及时返回。此时Readiness-probe或Liveness-probe不做任何操作，会等待下一次的机制来进行检验。

探测类型： 通过不同的探针实现不同的检测功能。

• livenessProbe/存活探针 ： 许多长时间运行的应用程序最终会转变为损坏状态，除非重新启动，否则无法恢复。
• readinessProbe/就绪探针 ： 有时应用程序暂时无法提供流量，您不想杀死应用程序，但也不想向它发送请求。
• startupProbe/启动探针 ： 您必须处理在首次初始化时可能需要额外启动时间的遗留应用程序。

Pod调度

• 第一步预选策略,强制性规则，选出合适的Node。 第二步优选策略，打分选最优。 调度类型有 ：
• 自动调度： 选使用率最小的节点
• 定向调度： 选nodeName或者标签
• 亲和性调度 : 提高性能,如同机房.
• 反亲和性调度 : 高可用,如灾备。
• 污点（容忍）调度3种类型 ： 不再优先调度；不再调度；不执行；

工作负载

• ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
• ReplicaSet：使 Pod 拥有自愈，多副本，扩缩容的能力
• Deployment：通过ReplicaSet来控制pod，并支持滚动升级、版本回退,适合于无状态应用批量启动。
• DaemonSet：在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务,适合于日志收集、节点监控等
• Job：它创建出来的pod只要完成任务就立即退出，用于执行一次性任务
• Cronjob：它创建的pod会周期性的执行，用于执行周期性任务
• StatefulSet（sts）：管理有状态应用，拥有固定的网络标记、持久化存储、顺序部署/删除/更新,适合于数据库,中间件等等

使用 volumeClaimTemplates来选择存储; Pod DNS ： $(StatefulSet 名称)-$(序号).$(服务名称).$(名字空间).svc.cluster.local Pod 主机名 : $(StatefulSet 名称)-$(序号)

• Horizontal Pod Autoscaler(HPA)：可以根据集群负载自动调整Pod的数量，实现削峰填谷。 需要定义min/max副本、目标期望(cpu/内存)的利用率设置。扩的比较快，缩的比较慢

服务 Service | 微服务的概念

• 定义： Kubernetes 为Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。
• 通过标签选择器与pod绑定
• Headless Services | 无头服务 ： 给了所有的pod的ip列表 ， 用于自主选择具体的ip或者配置sts使用。
• 可以通过环境变量发现服务的IP 地址和端口号
• 在pod里可以用service name 访问(垮namespace 访问需要 name.Namespace)；也可以用service ip访问。
• 负载均衡的实现: ClusterIP(别名service ip);NodePort;LoadBalancer
• LoadBalancer访问链路: LoadBalancer:port(云产商提供的ip) -> NodeIp:port(公网) -> externlIp:port(外部ip,通常为内网ip) -> clusterIP:port (service的虚拟ip) -> podIP: targetPort (具体的pod的虚拟ip)

Ingress | 进入

• 外部访问有nodeport ，loadbance 2种方式。 但是比较麻烦/不安全，所以有ingress。 类似于网关。
• 目前有Nginx，和apisix等等其他的。
• Ingress-nginx 的高可用 : Ingress + LoadBalancer

存储

• Volume： 挂载，Pod 内部共享资源存储，生命周期和 Pod 相同。
• PersistentVolume（PV） ： 持久化的，pod删除后还存在。
• PV的访问模式 (VolumeMode) ： ReadWriteOnce(RWO) 、 ReadOnlyMany(ROM)、ReadWriteMany(RWM)、ReadWriteOncePod(RWOP)： 卷可以被单个 Pod 以读写方式挂载
• PersistentVolumeClaim (PVC) ： 对PV资源的请求。
• PVC 只有绑定了 PV 之后才能被 Pod 使用，而 PVC 绑定 PV 的过程即是消费 PV 的过程，这个过程是系统自动实现的、且有有一定规则的。
• PVC 和 PV 是一一对应的，必须先删pvc再删pv
• Dynamic Provisioning 动态供给 : 就是pvc创建过程中会自动创建PV(动态供应PV卷)
• StorageClass : 相当于实现类，实现不同的功能 如 NFS、ceph、iSCSI 和云提供商指定的存储系统（把存储放到云产商）
• 3种使用方式: pod直接访问(直接写路径)；静态provision供给(绑定静态的pvc)；动态provision供给(绑定动态的pvc)

Configmap / Secrets

• 相当于配置中心，存配置的，在一个namespace中公用。
• 使用方式 : 环境变量,volume
• Secrets就是使用时自动base64解密了。

部署yaml编写

• pod工作负载是Deployment、HPA、sts。
• 存储： sts就动态存储，其他是pvc、pv
• selector : 亲和性设置，还是默认，还是label设置。
• service 的模式
• ConfigMap、Secrets 配置文件。

spring-cloud-kubernetes 框架的使用

• 注册中心、配置中心、服务发现 k8s自带了。
• 负载均衡 ，该项目里面实现了，可以自定义负载均衡。(通过调用API获取 Kubernetes 下的服务列表进行服务发现。之后里面robbion做自定义的负载均衡。)
• RPC调用、服务熔断都是spring-cloud封装好了的。
• 服务网关、限流、降级都是istio去操作的
• 链路追踪、分布式事务都是开源框架去做的。

ServiceMesh | Istio

解决服务间的网络通信的问题。（延迟、可靠、带宽有限、拓扑结构会变、网络可能异构）

主要功能

服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求，比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。

• 流量控制: 路由、流量转移、超时重试、熔断、故障注入、流量镜像（影子流量）、弹性、测试、A/B 测试、金丝雀发布
• 策略配置: 限流、黑白名单
• 网络安全: 授权和身份认证,控制可访问的域名；
• 可观察性: 指标（Promethuse）、日志、分布式追踪（结合skywalking）。 kiali 使用（服务拓补图）
• Gateway ingress、Egress ，入口、出口流量的控制。

类比

Kubernetes关系：

• k8s解决pod的生命周期的调度管理，为Service Mesh提供基础。
• k8s只是他底层的支持，k8s可以用其他的替换，如swarm等。
• Istio 在运维层面解决了，网络和流量管理的问题。 更多承担是的网络代理框架的角色。

和API网关关系：

• 功能有重叠。
• 边界不同: mesh是在应用内部的，网关是外部的。

Serverless | Knative

• 为了帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。在k8s和Istio的基础上做的扩展，和封装，达到简单使用。
• Serverless = Faas + Baas；Faas 无状态（业务逻辑），Baas 有状态（通用服务：数据库，认证，消息队列）。
• 优势： 便利性、标准化、成熟的生态、自动伸缩（支持蓝绿发布、回滚功能，缩容到0）、应用监控集成（收集日志和调用关系）
• 组件： Serving（服务,流量控制策略）、Event（跨语言和平台的事件）、Queue-proxy（流控）

背景

• 资源利用率 ： 中长尾应用（大部分时间都没有流量），将实例缩容为 0，避免闲置。
• 弹性伸缩 ： Knative KPA 它可以根据 请求量扩速容，支持缩容到 0 和从 0 启动，反应更迅速适合流量突发场景。比k8s的HPA更灵活。
• 按比例灰度发布 : 封装成了ksvc，使其更容易实现灰度发布。 k8s原生（需要一个按流量分发的网关，两个 service，两个 deployment ，两个 ingress ，hpa，prometheus）
• 用户运维复杂性 ： k8s 本质上还是基础设施的抽象；对应 pod 的管控，服务的发布，镜像的构建等等需要上层的包装。 而这就是Knative的目标。

开发运维一体化

术语

敏捷开发 : 重在build代码通过。以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 CI-持续集成 : 重在单元test通过。源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。 CI 的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。 CD-持续交付 : 重在release版本发布。可自动将已验证的代码发布到存储库。 它目标是拥有一个可随时部署到生产环境的代码库。 CD-持续部署 : 重在deploy版本部署。所有的变更都会被自动部署到生产环境中。 DevOps : 是一种方法论，为了实现上面的目标。用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运维之间的壁垒和鸿沟。 持续交付和持续部署的异同:

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。 持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段

Jenkins

• Jenkins Pipeline : 放到项目中由开发者维护。
• Pipeline基本概念： Node（Jenkins运行的节点），Stage（一个逻辑分组，展示给用户查看），Step（ 最基本的操作单元）
• Tekton ： 他属于云原生的ops工具。用产商提供的task流水线模板，而无需开发者编写。
• Argo支持k8s的滚动更新。 istio的流量管理。 Argo-Rollout主要集成了Ingress和ServiceMesh两种流量控制方法

插件

intput（）插件可以让用户输入交互。 checkout : 源码管理,在凭证中进行定义gitId withCredentials : 可以从获得凭据的账号和密码。 kubernetes CLI ： 配置kubernetes 的 kubeconfig