k8s基础

会有一股神秘感。 提交于 2020-03-22 18:13:01

1.kubernetes架构与组件

Kubernetes集群是由一组节点,也就是node节点组成,可以是物理服务器,也可以是虚拟机。
每个node节点上都安装了kubelet和kube-proxy这两个node组件。
而安装了master组件的节点称为master node。
node组件通过kubelet组件与master组件进行交互,维护着该node上的pod的生命周期。
一个典型的master集群是由一个master node和若干个承载工作负荷的node组成。
kubernetes通过etcd存储着集群中的所有对象和状态。
kubernetes还提供了集群维护的超级命令行工具kubectl。

 

(1)master

master组件主要包括:Apiserver、Scheduler、Controller Manager和etcd。
Api Server是master组件的中枢,其余的master组件都是通过调用Api的接口,实现各自的功能。
API server是整个集群控制的前端,是唯一可以修改集群状态和数据库的组件。

master组件是Kubernetes集群的大脑。
所有集群的控制命令都传递给Master组件并在其上执行。
每个Kubernetes集群至少有一套Master组件。来负责控制和管理整个集群,才能保证集群的正常运转。
它协调集群中的所有活动,包括集群中应用的调度、状态维护、应用升级和伸缩,以及对外的API接口。

API Server:
  集群控制的唯一入口,是提供Kubernetes集群控制Restful API的核心组件。封装了核心对象的增删改查等操作。
  提供集群控制的安全机制(身份认证、授权以及admission control)。

Scheduler:
  通过API Server的Watch接口监听新建Pod副本信息,并通过调度算法为该Pod选择一个最合适的Node。
  支持自定义调度算法provider。
  默认调度算法内置预选策略和优选策略,决策考量资源需求、服务质量、软硬件约束、情缘性、数据局部性等指标参数。

ControllerManager:
  集群内各种资源controller的核心管理者。
  针对每一种具体的资源,都有对应的Controller。
  保证其下管理的每个Controller所对应的资源始终”处于期望状态“。

  

Etcd:
  Kubernetes集群的主数据库,存储着所有资源对象以及状态。
  默认与Master组件部署在一个Node上。
  Etcd的数据变更都是通过API Server进行的。

 

(2)Node组件

Kubernetes集群中真正的工作负载均衡节点。
Kubernetes集群由多个Node共同承担工作负载,Pod被分配到某个具体的Node上执行。
Kubernetes通过node controller对资源进行管理。支持动态在集群中添加或刪除Node。
每个集群Node1上都会部署Kubelet和Kube-proxy两个组件。

Kubelet:
  位于集群中每个Node上的非容器形式的服务进程组件,Master和node之间的桥梁。
  处理master下发到本Node上的Pod创建、启停等管理任务,向APIServer注册Node信息。
  监控本Node上容器和节点资源情况,并定期向master汇报资源占用情况。

Kube-proxy:
  Service抽象概念的实现,将到Service的请求按策略(负载均衡)算法分发到后端Pod上。
  默认使用iptables mode实现。
  支持nodeport模式,实现从外部访问集群内的service。

 

2.Kubernetes基本概念

(1)kubernetes对象和对象模型

Kubernetes对象是一种持久化的、用于表示集群状态的实体。
一种声明式的意图的记录,一般使用yaml文件描述对象。
Kubernetes集群使用Kubernetes对象来表示集群的状态。
通过API/kubectl管理Kubernetes对象。

 

(2)常用的metadata属性

Name和UID:
  Kubernetes集群中所有对象都通过name和UID明确标识。
  在Kubernetes集群的整个生命周期内创建的每个对象实例都具有不同的UID。

Namespace:
  不仅仅是一个属性,本身也是一个object。
  用于将物理集群划分为多个虚拟集群。
  常用来隔离不同的用户及权限。
  内置三个Namespaces:default、kube-system和kube-public、Node和PersistentVolume不属于任何namespace。

Label:
  用于建立集群对象之间的灵活的、松耦合的多维关联关系。
  一个label是一个键值对,其中key、value均由用户自己定义。
  label可以附着在任何对象上,每个对象也可以有任意个标签。
  标签可在对象定义时附加上,也可以通过命令动态管理标签。
  Label可以将有组织目的的结构映射到集群对象上,从而形成一个与现实世界管理结构同步对应松耦合的、多维的对象管理结构。
  通过label select查询和刷选建立对象间的关系。

  

 

Annotations(注解):
  可以将任意非标识性元数据附加到对象上。也是以键值对形式呈现。
  工具和库可以检索到并使用这些Annotation元数据。
  将数据作为Annotation附着在对象上,有利于创建一些用于部署、管理和做内部检查的共享工具或客户端。

 

(3)kubernetes对象分类

Kubernetes中的对象有很多,主要可以分为以下:

Pod:
  一个有特定关系的容器集合。
  Pod是集群中可以创建和部署的最小且最简的Kubernetes对象单元。
  Pod也是一种封装。它封装了应用容器,存储资源,独立的网络以及决定容器如何运行的策略选项。
  每个Pod中预置一个Pause容器,其名字空间、IPC资源、网络和存储资源被Pod内其它容器共享。
  Pod中所有容器紧密协作并且作为一个整体被管理、调度和运行。
  Pod是一个非持久性实体,在调度失败、节点故障、缺少资源等情况下都可以被终止掉。
  即使只有一个Pod,也不应该手动创建。

  Pod的生命周期图如下:

  

Service:
  与云原生应用中”微服务“概念对应。
  Kubernetes集群为每个Service分配一个集群唯一的IP地址。
  在service的生命周期内,该IP地址不变;在内部DNS的支持下,轻松实现服务发现机制。
  Service通过label selector关联到实际支撑业务运行的Pod上,
  并通过集群内置的负载均衡将服务请求分发到后端Pod。
  通过nodeport或设置loadbalancer机制实现集群外部对service的访问。

Controllers:
  Controller是Kubernetes核心对象之一。
  Controller用于保证集群内一组Pod能始终按照某种期望的状态正常运行。
  状态包括:Pod副本数量、节点选择、资源约束、持久化数据维持等。
  Kubernetes支持多种Controller,常用的Deployment、replicaset、statefulset、daemonset等。
  ReplicaSet:
    确保健康Pod的副本数始终满足用户定义的数量。
    前身是ReplicationController(rc),相比rc,增加集合式label selector的支持。
    支持单独使用,但更多隐藏在Deployment控制器后面,由deployment自动管理。

  deployment
    为Pod和ReplicaSet提供了声明式的定义(declarative)。
    用户在deployment文件中描述期望状态,Deployment controller就会自动将Pod和Reploca Set的实际状态变更到期望状态。
    Deployment支持Pod的RollingUpdate,并自动管理背后的Replicaset。
    Deployment支持将pod Rollback到之前的任意revision。

  StatefulSet
    StatefulSet提供对有状态的应用的部署和控制的支持。
  使用场景:稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序刪除、有序自动滚动升级等。
  Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class进行配置,或由管理员预先配置好。
  考虑数据安全性,伸缩或刪除StatefulSet不会刪除关联的存储;
  另外StatefulSet目前要求Headless Service负责Pod的网络身份,用户有责任创建此服务。

  DaemonSet
    保证每个Node上都运行一个Pod副本。
    适用场景:系统Daemon程序、监控跟踪、日志收集等。
    可指定Node:nodeSelector、nodeAffinity、podAffinity

  ConfigMap
    常用来向Pod提供非敏感的配置信息。
    ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。
    ConfigMap可以适用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建。
    ConfigMap可以通过三种方式在Pod中使用:环境变量、命令行参数或以文件形式通过数据卷插件挂载到Pod中。

  Secret
    解决的是集群内密码、token、密钥等敏感的数据的配置问题。
    常用于与ServiceAccount股那里,存储在tmpfs文件系统中,刪除后Secret文件也会对应的刪除。
    支持Opaque、kubernetes.io/Service Account,kubernetes.io/dockerconfigjson三种类型。
    Secret可以以Volume或者环境变量配合使用。  

  Service:
与云原生应用中”微服务“概念对应。
Kubernetes集群为每个Service分配一个集群唯一的IP地址。
在service的生命周期内,该IP地址不变;在内部DNS的支持下,轻松实现服务发现机制。
Service通过label selector关联到实际支撑业务运行的Pod上,
并通过集群内置的负载均衡将服务请求分发到后端Pod。
通过nodeport或设置loadbalancer机制实现集群外部对service的访问。

Controllers:
Controller是Kubernetes核心对象之一。
Controller用于保证集群内一组Pod能始终按照某种期望的状态正常运行。
状态包括:Pod副本数量、节点选择、资源约束、持久化数据维持等。
Kubernetes支持多种Controller,常用的Deployment、replicaset、statefulset、daemonset等。
(1)ReplicaSet
确保健康Pod的副本数始终满足用户定义的数量。
前身是ReplicationController(rc),相比rc,增加集合式label selector的支持。
支持单独使用,但更多隐藏在Deployment控制器后面,由deployment自动管理。

(2)deployment
为Pod和ReplicaSet提供了声明式的定义(declarative)。
用户在deployment文件中描述期望状态,Deployment controller就会自动将Pod和Reploca Set的实际状态变更到期望状态。
Deployment支持Pod的RollingUpdate,并自动管理背后的Replicaset。
Deployment支持将pod Rollback到之前的任意revision。

(3)StatefulSet
StatefulSet提供对有状态的应用的部署和控制的支持。
使用场景:稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序刪除、有序自动滚动升级等。
Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class进行配置,或由管理员预先配置好。
考虑数据安全性,伸缩或刪除StatefulSet不会刪除关联的存储;
另外StatefulSet目前要求Headless Service负责Pod的网络身份,用户有责任创建此服务。

(4)DaemonSet
保证每个Node上都运行一个Pod副本。
适用场景:系统Daemon程序、监控跟踪、日志收集等。
可指定Node:nodeSelector、nodeAffinity、podAffinity


(5)ConfigMap
常用来向Pod提供非敏感的配置信息。
ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。
COnfigMap可以适用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建。
ConfigMap可以通过三种方式在Pod中使用:环境变量、命令行参数或以文件形式通过数据卷插件挂载到Pod中。

(6)Secret
解决的是集群内密码、token、密钥等敏感的数据的配置问题。
常用于与ServiceAccount股那里,存储在tmpfs文件系统中,刪除后Secret文件也会对应的刪除。
支持Opaque、kubernetes.io/Service Account,kubernetes.io/dockerconfigjson三种类型。
Secret可以以Volume或者环境变量配合使用。  

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!