K8S适用场景及功能

1. 多台机器集群管理和配置（单机，直接docker + docker-compose）

2. Kubernetes 可以为你提供集中式的管理集群机器和应用，加机器、版本升级、版本回滚，那都是一个命令就搞定的事，不停机的灰度更新，确保高可用、高性能、高扩展。

Kubernetes 集群架构

 

master

主节点，控制平台，不需要很高性能，不跑任务，通常一个就行了，也可以开多个主节点来提高集群可用度。

worker

工作节点，可以是虚拟机或物理计算机，任务都在这里跑，机器性能需要好点；通常都有很多个，可以不断加机器扩大集群；每个工作节点由主节点管理

 pod

 K8S 调度、管理的最小单位，一个 Pod 可以包含一个或多个容器，每个 Pod 有自己的虚拟IP。一个工作节点可以有多个 pod，主节点会考量负载自动调度 pod 到哪个节点运行。

Kubernetes 组件

kube-apiserver API 服务器，公开了 Kubernetes API。Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。

etcd 键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库
kube-scheduler 调度 Pod 到哪个节点运行
kube-controller 集群控制器
cloud-controller 与云服务商交互

Pod、 Deployment、Replication Controller 区别

Pod是k8s的最小调度单位，一个Pod中可以有多个containers，彼此共享网络等，这是k8s的核心概念。

其他资源基本上都是围绕着Pod而展开，比如RC（Replication Controller）或者RS（Replication Set），这两种资源可以控制Pod的副本数，所以它们就比Pod高级一点，在定义它们的时候和Deployment一样，需要在template中定义Pod中的容器等内容，而Deployment是比RC或者RS更高级的一种资源，它不但可以控制Pod的副本数，同时还可以控制Pod的版本，所以这么高级的资源并不是时时刻刻都需要的，比如你就想暂时性的部署一个小程序，用完就不要了，那么你就没有必要使用RS或者RC，更没有必要去用Deploment。

—————————————-

从开发者角度看，deployment顾明思意，既部署，对于完整的应用部署流程，除了运行代码(既pod)之外，需要考虑更新策略，副本数量，回滚，重启等步骤，而运行代码的方式有很多种，例如有一次性的也就是job，有定时执行的也就是crontabjob，有排号的也就是sts，为了复用运行代码的功能所以抽象为pod，从而进行复用。

—————————————-

pod是单一亦或一组容器的合集。

deployment是pod版本管理的工具 用来区分不同版本的pod。

单独创建pod的时候就不会有deployment出现，但是创建deployment的时候一定会创建pod,因为pod是一个基础的单位。

任何的控制器单位的具体实现必须落到pod去实现。

Replication Controller

Replication Controller为Kubernetes的一个核心内容，应用托管到Kubernetes之后，需要保证应用能够持续的运行，Replication Controller就是这个保证的key，主要的功能如下：

• 确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。

• 确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。

• 弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。

• 滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

Deployment

Deployment同样为Kubernetes的一个核心内容，主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：

• Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。

• 事件和状态查看：可以查看Deployment的升级详细进度和状态。

• 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。

• 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。

• 暂停和启动：对于每一次升级，都能够随时暂停和启动。

• 多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。

yaml解释

pod

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec: # 期望状态
  # 定义容器，可以多个
  containers:
    - name: test-k8s # 容器名字
      image: ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v1 # 镜像

kind为pod类型就是直接创建指定pod

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  # 部署名字
  name: test-k8s
spec: #期望状态
  replicas: 2 # 告知 Deployment 运行 2 个与 template 匹配的 Pod
  # 用来查找关联的 Pod，所有标签都匹配才行
  selector:
    matchLabels:
      app: test-k8s
  # 定义 Pod 相关数据 
  template:  # template 与上面 pod 得配置几乎一模一样
    metadata:
      labels: # 标签的 Key 对于给定对象必须是唯一的（可以多个标签，但多个标签不能全部重复）
        app: test-k8s
    spec:
      # 定义容器，可以多个
      containers:
      - name: test-k8s # 容器名字
        image: ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v1 # 镜像

deployment则可以创建多个pod

在想要创建的 Kubernetes 对象所对应的 .yaml 文件中，需要配置的字段如下：

• apiVersion – 创建该对象所使用的 Kubernetes API 的版本
• kind – 想要创建的对象的类别
• metadata – 帮助唯一性标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
• spec – 你所期望的该对象的状态

 

ReplicaSet

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

 

StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象。

StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

用途

StatefulSet 是用来管理有状态的应用，例如数据库。
前面我们部署的应用，都是不需要存储数据，不需要记住状态的，可以随意扩充副本，每个副本都是一样的，可替代的。
而像数据库、Redis 这类有状态的，则不能随意扩充副本。
StatefulSet 会固定每个 Pod 的名字

使用 StatefulSet

StatefulSet 对于需要满足以下一个或多个需求的应用程序很有价值：

• 稳定的、唯一的网络标识符。
• 稳定的、持久的存储。
• 有序的、优雅的部署和扩缩。
• 有序的、自动的滚动更新。

服务（Service）

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡

定义 Service

Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样，Service 定义可以基于 POST 方式，请求 API server 创建新的实例。 

 

ClusterIP

默认的，仅在集群内可用

NodePort

暴露端口到节点，提供了集群外部访问的入口
端口范围固定 30000 ~ 32767

LoadBalancer

需要负载均衡器（通常都需要云服务商提供）
会额外生成一个 IP 对外服务
K8S 支持的负载均衡器：负载均衡器

Headless

适合数据库
clusterIp 设置为 None 就变成 Headless 了，不会再分配 IP，后面会再讲到具体用法

 

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongodb
spec:
  serviceName: mongodb
  replicas: 3
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
        - name: mongo
          image: mongo:4.4
          # IfNotPresent 仅本地没有镜像时才远程拉，Always 永远都是从远程拉，Never 永远只用本地镜像，本地没有则报错
          imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:
  name: mongodb
spec:
  selector:
    app: mongodb
  type: ClusterIP
  # HeadLess
  clusterIP: None
  ports:
    - port: 27017
      targetPort: 27017

 

 

数据持久化

介绍

kubernetes 集群不会为你处理数据的存储，我们可以为数据库挂载一个磁盘来确保数据的安全。
你可以选择云存储、本地磁盘、NFS。

• 本地磁盘：可以挂载某个节点上的目录，但是这需要限定 pod 在这个节点上运行
• 云存储：不限定节点，不受集群影响，安全稳定；需要云服务商提供，裸机集群是没有的。
• NFS：不限定节点，不受集群影响