容器编排-K8s

分类于
字数统计: 1,364

➤ 什么是Kubernetes:

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。
使用Kubernetes可以：

  • 自动化容器的部署和复制
  • 随时扩展或收缩容器规模
  • 将容器组织成组，并且提供容器间的负载均衡
  • 很容易地升级应用程序容器的新版本
  • 提供容器弹性，如果容器失效就替换它，等等..

K8s架构

k8s-cluster

上图可以看到如下组件，使用特别的图标表示Service和Label：

  • Kubernetes Master（Kubernetes主节点）
  • Replication Controller（复制控制器）
  • Node（节点）
  • Label: 标签🏷
  • Service: 服务, 图中红色Service指向带有相同 Label的 Pod

➤ Kubernetes Master:
组件包括: Kubernetes API Server/ Replication Controller 等..

➤ Node:
节点（上图橘色方框）是物理或者虚拟机器，作为 Kubernetes worker，通常称为 Minion。每个节点都运行如下 Kubernetes关键组件：

  • Kubelet：是主节点代理, 每个Node运行一个, 作为 Node和 Kubernetes master之间的代理
  • Kube-proxy：Service使用其将链接路由到Pod
  • Container: Docker 或 Rocket, Kubernetes使用的容器技术来创建容器

➤ Lable:
Label是attach到Pod的一对键/值对，用来传递用户定义的属性。例如通过Label（tier=frontend, app=myapp）来标记前端Pod容器,
在deployment描述文件中, 使用Selector: tier=frontend, app=myapp 指定用哪些Pods

➤ Service:
Service是将一组Pod公开为网络服务的抽象, Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。
当访问一个Service时，通过 Node上运行的代理（kube-proxy），对 Pod进行负载均衡

➤ Pod:
Pod（上图绿色方框）安排在节点上, 一个Pod内可以包含多个容器和卷, 这些容器共享网络地址和文件系统;
Kubernetes 提供了几种资源来管理众多的Pods:

  • Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用
  • StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。 例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来
  • DaemonSet 定义提供节点本地支撑设施的 Pods, 例如作为网络链接的辅助工具或者作为网络 插件 的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，则控制面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
  • Job 和 CronJob。 定义一些一直运行到结束并停止的任务。Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。

Deployments

@ref: Deployments | Kubernetes

ReplicaSet

@ref: ReplicaSet | Kubernetes

StatefulSets

@ref: StatefulSets | Kubernetes

Service

@ref: 服务 | Kubernetes

Ingress

@ref: Ingress | Kubernetes

K8s命令

➤ K8s命令模式: kubectl [command] [TYPE] [NAME] [flags]

  • command: for example create, get, describe, delete
  • TYPE: 描述 resource type, for example pod, pods, app, service, resource type不区分大小写/复数单数/缩写形式
  • NAME: 描述 resource name, for example kubectl get pod example-pod1 example-pod2
  • flags: 描述 optional flags, for example -s, --server

kubectrl 操作的常用 Resource type, 及缩写形式:

  • cm: configMaps
  • ns: namespaces
  • po: pods
  • rs: replicaSets
  • svc: services
  • sts: statefulSets
  • ing: ingresses
  • deploy: deployments
    @ref: kubectl 概述 资源类型

➤ 常用命令:

  • 列出资源:
    • kubectl get pods -o wide: 列出全部Pods
    • kubectl get pods -l app=nginx: 列出具有某label的Pods
    • kubectl get rc,service: 列出全部 rc(replicationControllers) & service
    • kubectl get sts: 列出所有stateful
  • 获取资源描述:
    • kubectl describe nodes: 显示所有Node的详细信息
    • kubectl describe pods: 显示所有Pod的详细信息
    • kubectl describe pod ${podname}: 显示某个Pod的详细信息
  • 编辑资源:
    • kubectl delete pod ${podname}: 删除后自动重启pod
    • kubectl edit sts ${stsname}: // edit后不会回写yaml文件
    • kubectl edit app ${appname}:
  • 发布:
    • kubectl apply -f deployment.yaml
    • kubectl apply -f deployment-update.yaml // 执行后会应用新的yaml配置
  • 对Pod中的容器执行命令:
    • kubectl exec -it ${podname} bash

K8s & Docker

@ref: 容器技术之容器引擎与江湖门派 - 知乎

容器管理系统分为三层：

  1. High-level Container Management：容器管控的UI层。直接实现容器的管控和使用界面，也是用户最熟悉的子系统。
  2. High-level Container Runtime：容器状态及资源供给。包括镜像管理、网络接入、容器状态、调用Low Level Runtime执行容器等功能。习惯上这层称之为容器引擎（Container Engine）。
  3. Low-level Container Runtime：容器执行层。负责具体构建容器运行环境并执行容器进程。习惯上这层直接简称为容器运行时（Container Runtime）。

High-level Container Management和Container Engine之间的接口规范是CRI，Container Engine和Container Runtime之间的接口规范是OCI。支持CRI接口的容器引擎主要有docker、rkt、pouch、containerd和cri-o等
container-level

@ref: 为什么 Kubernetes 要替换 Docker-InfoQ

Kubernetes 引入容器运行时接口（Container Runtime Interface、CRI）隔离不同容器运行时的实现机制，容器编排系统不应该依赖于某个具体的运行时实现；
Docker 没有支持也不打算支持 Kubernetes 的 CRI 接口，需要 Kubernetes 社区在仓库中维护 Dockershim；

Deployment.yaml文件解析