资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/Kubernetes 核心概念

Kubernetes 核心概念

Cobub / 929人阅读

摘要：核心概念是最小的调度单元，可以由一个或者多个容器组成。该模式会跟云服务商有关，比如可以通过等创建一个外部的负载均衡器，将请求转发到对应的服务组。而可以提供外部服务可访问的负载均衡器等。

概述

Kubernetes 有各类资源对象来描述整个集群的运行状态。这些对象都需要通过调用 kubernetes api 来进行创建、修改、删除，可以通过 kubectl 命令工具，也可以直接调用 k8s api，或者使用对象语言的客户端库（例如：golang ， pythion ）。

每个 kubernetes 对象都会包含两个关键字段：Object Spec 和 Object Status。spec 描述了对象所期望达到的状态，status 描述了该对象的实际状态。

下面会宽泛的介绍一些 Kubernetes 的核心概念，便于初步的理解它们特征及工作模式。

核心概念 Pod

Pod 是 Kubernetes 最小的调度单元，可以由一个或者多个容器组成。

Pod 的设计理念是支持多个容器在一个 Pod 中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

Pod 的特征：

可以包含多个容器，它们之间共享 IPC、Network 、UTC、PID namespace，可以直接通过 localhost 进行通信。

支持 CPU / Mem 超卖

支持一个或者多个 init containers

Pod 可以共享 Volume，使得多个容器之间可以共享数据。

Pod 生命周期短暂，且不会自愈。需要结合 Deployment、DaemonSet、StatefulSet 等控制器来达到容错。

优雅退出：Pod 删除的时候先给其进程发送 SIGTERM，等待一段时间（grace period）后才强制停止依然还在运行的进程。

支持（反）亲和性

支持指定调度器

支持优先级和抢占性调度（v1.8 及以上）

支持配置 serviceAccount

kubernetes v1.8+ 且 docker >= 1.13.1 才支持容器之间共享 PID namespace，还需要配置 kubelet —docker-disable-shared-pid=false
Init Containers - Kubernetes
Labels & Selectors

Labels 是 Key-Value 对，k8s 用于标识其所有资源；而 Selectors 是标签选择器，用于选择特定 labels 的资源。

Selectors 目前支持两种选择器：Equality-based（基于平等） 和 Set-based（基于集合）。

1. Equality-based

基于相等的或者不想等的条件用标签的 keys 和 values 进行过滤。支持三种运算符：“=”，“==” 和 “!=”。还可以使用逗号操作符，连接多个运算符。

2. Set-based

Set-based 的选择器允许用一组 value 来过滤 key。
支持三种操作符：in，notin 和 exists（仅针对于 key 符号）。

例如：

env in (dev, test, staging, prod)
env notin (staging, prod)
partition
!partition

Set-based 可以和 Equality-based 条件结合使用。

Deployment

Kubernetes 有几个版本的副本控制器，比如 Replication Controller、Replica Set（RC 升级版）和 Deployments。

Deployment 是逻辑层的一种抽象，为 Pod 和 ReplicaSet 提供了一种声明式定义，来代替以前的 Replication Controller 更方便的管理应用。

在 Kubernetes 的实际使用中，RS 也属于底层概念，由 Deployment 来管理，因此用户一般都是与 Deployment 打交道。

Deployment 有几种 典型的应用场景，比如：

定义 Deployment 来创建 Pod 和 ReplicaSet

滚动升级和回滚应用，比如蓝绿发布，金丝雀发布等等

扩容和缩容

暂停和继续 Deployment

RC、RS、Deployment 等对象都是为了解决无状态服务而设计，下面还会针对有状态服务，介绍对应的对象。
Service

Kubernetes Pod 有自己的生命周期，可以随时被创建和销毁，而一旦销毁就永远结束了。而每个 Pods 都有自己的 IP，而 Pod 的生命周期也意味着 这些 IP 地址不总是稳定可靠的。所以需要有针对容器的服务发现与负载均衡机制，来访问这个 Pod 逻辑分组。

service 是对一组提供相同功能的 Pods 集合的抽象，为这组Pods提供统一的访问入口。借助 Service 可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。

在 Kubernetes 集群中，每个 Node 都会部署一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP (虚 IP)。

Service 有四种类型：

ClusterIP：默认类型，自动分配一个仅 cluster 内部可以访问的虚拟 IP。

NodePort：该模式会在每台机器上绑定一个端口，这样可以通过 NodeIP:NodePort 进行服务访问。

LoadBalancer：该模式会跟云服务商有关，比如可以通过 aliyun、aws 等创建一个外部的负载均衡器，将请求转发到对应的服务组。

ExternalName：支持将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externalName 设定）。需要 kube-dns 版本大于 1.7。

Ingress

通常情况下，Service 和 Pod 仅支持在集群内部进行服务访问。而 Ingress 可以提供外部服务可访问的 URL / 负载均衡器等。

Ingress 对象只是配置了一些规则，若要实现集群外部的访问，还需要部署一个 Ingress Controller，它会从 kube-apiserver 监听 Ingress 和 Service 的变更，并根据 Ingress 的规则配置负载均衡来提供访问入口。

Job

Job 负责批量处理短暂的一次性任务，仅执行一次，并保证处理的一个或者多个Pod成功结束。

具体的可以查看：深入K8S Job(一)：介绍

PV & PVC

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供网络存储资源，而 PVC 请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起来。PV 和 PVC 可以将 pod 和数据卷解耦，pod 不需要知道确切的文件系统或者支持它的持久化引擎。

PV 也是集群的资源（等同于cpu / mem），但不同于 pod volume，它是独立于 Pod 的生命周期。

支持类别划分，比如不同的服务质量级别（SSD / SATA），不同的备份策略等。
支持动态 PV（StorageClass）。
支持卷的扩容及快照（v1.8+ 特性）。
支持 Local Volume，允许将 Node 本地的磁盘、分区或者目录作为持久化存储使用。但是需要注意该模式不支持动态创建，使用前需要预先创建好 PV。

PV 是存储资源，而 PVC 是对 PV 的请求。PVC 和 Pod 类似，Pod 消费 Node 资源，而 PVC 消费 PV 资源；Pod 能够请求 CPU 和内存资源，而 PVC 请求特定大小和访问模式的数据卷。

StatefulSet

StatefulSet 用于支持部署有状态服务，而有状态的服务很关键的就是持久化存储，这就依赖上面介绍的 PV & PVC 了。

StatefulSet 的应用场景包括：

稳定的持久化存储，即不需要关心 Pod 的重新调度，服务访问的还是相同的持久化数据。

稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变。

有序部署，即 Pod 的创建是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行创建，基于 init containers 来实现。

有序收缩（删除）。

参考案例：Running ZooKeeper, A Distributed System Coordinator - Kubernetes

推荐在 k8s v1.9 + 的版本使用 statefulSet。


为了保证数据安全，删除 StatefulSet 是不会删除 PV 的，需要考虑清理策略。


StatefulSet 需要提前创建一个 Headless Service 来定义 DNS domain。
Other

还有很多别的资源对象，这里暂不一一介绍了，因为涉及的篇幅会比较长。
对于上面或者未提及的资源对象需要多了解一下的，建议查阅官方文档。

比如：

Namespace

Node

Secret：集群的秘药管理

ConfigMap：集群的配置管理

Event：记录k8s集群运行所遇到的各种大事件

HPA（HorizontalPodAutoscaler）：自动扩缩容

DaemonSet：保证每个Node上都运行一个容器副本，常用于部署一些集群服务的agent(日志／监控…), 也可以基于Pod进行亲和部署。

GPU云服务器 云服务器 Kubernetes Kubernetes 入门基础 kubernetes 容器云 apt kubernetes

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/32743.html

相关文章

  • Kubernetes概念与术语

    摘要：标识是与操作对象间的纽带。集群为每个对象维护三类信息对象元数据期望状态与实际状态元数据指对象的基本信息，比如命名标签注释等等，用于识别对象期望状态一般由用户配置来描述的实际状态是由集群各个组件上报的集群实际的运行情况。 综述 学习Kubernetes时，发现它的概念和术语还是比较多的，光靠啃官方文档比较晦涩。所以边学习边整理，对主要的概念和术语做一下分类及简要说明。感觉把重要概念都理解...

    _Suqin 评论0 收藏0

  • Kubernetes系统架构演进过程与背后驱动的原因

    摘要：本文中，我们将描述系统的架构开发演进过程，以及背后的驱动原因。应用管理层提供基本的部署和路由，包括自愈能力弹性扩容服务发现负载均衡和流量路由。 带你了解Kubernetes架构的设计意图、Kubernetes系统的架构开发演进过程，以及背后的驱动原因。 showImg(https://segmentfault.com/img/remote/1460000016446636?w=1280...

    wuaiqiu 评论0 收藏0

  • 灵雀云CTO陈恺：从“鸿沟理论”看云原生，哪些技术能够跨越鸿沟？

    摘要：早在年针对高科技行业和高科技企业生命周期的特点，提出了著名的鸿沟理论。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。回过头来看，灵雀云从早期全力投入技术栈，是最早进行产品化的厂商。 历史进入2019年，放眼望去，今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节，我们来梳理和展望一下整个云原生技术趋势的发展，是一件很有意义的事情，这其中有些变...

    hss01248 评论0 收藏0

  • 容器监控实践—Metrics Server

    摘要：出现后，新的监控架构将变成上图的样子核心流程黑色部分这是正常工作所需要的核心度量，从等获取度量数据，再由提供给控制器等使用。本文为容器监控实践系列文章，完整内容见 概述 从 v1.8 开始，资源使用情况的监控可以通过 Metrics API的形式获取，具体的组件为Metrics Server，用来替换之前的heapster，heapster从1.11开始逐渐被废弃。 Metrics-S...

    libxd 评论0 收藏0

  • 容器监控实践—Metrics Server

    摘要：出现后，新的监控架构将变成上图的样子核心流程黑色部分这是正常工作所需要的核心度量，从等获取度量数据，再由提供给控制器等使用。本文为容器监控实践系列文章，完整内容见 概述 从 v1.8 开始，资源使用情况的监控可以通过 Metrics API的形式获取，具体的组件为Metrics Server，用来替换之前的heapster，heapster从1.11开始逐渐被废弃。 Metrics-S...

    lmxdawn 评论0 收藏0

发表评论

登陆后可评论

0条评论

Cobub

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<