Kubernetes培训

12月 18, 2019 kubernetes

Kubernetes培训

K8s:

Kubernetes是一个可移植的,可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes的服务,支持和工具广泛可用。

传统部署时代: 早期,组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况,结果,其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但这并没有随着资源利用不足而扩展,并且组织维护许多物理服务器的成本很高。

虚拟化部署时代:作为解决方案,引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机(VM)。虚拟化允许应用程序在VM之间隔离,并提供安全级别,因为一个应用程序的信息不能被另一应用程序自由访问。

虚拟化可以更好地利用物理服务器中的资源,并可以实现更好的可伸缩性,因为可以轻松地添加或更新应用程序,降低硬件成本等等。借助虚拟化,您可以将一组物理资源呈现为一组一次性虚拟机。

每个VM是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。

容器部署时代:容器类似于VM,但是它们具有轻松的隔离属性,可以在应用程序之间共享操作系统(OS)。因此,容器被认为是轻质的。与VM相似,容器具有自己的文件系统,CPU,内存,进程空间等。由于它们与基础架构分离,因此可以跨云和OS分发进行移植。

容器之所以受欢迎,是因为它们提供了额外的好处,例如:

  • 敏捷的应用程序创建和部署:与使用VM映像相比,容器映像创建的简便性和效率更高。
  • 持续的开发,集成和部署:通过快速简单的回滚(由于图像不可更改),提供可靠且频繁的容器映像构建和部署。
  • 开发和运营的关注点分离:在构建/发布时而不是在部署时创建应用程序容器映像,从而将应用程序与基础架构分离。
  • 可观察性不仅可以显示操作系统级别的信息和指标,还可以显示应用程序的运行状况和其他信号。
  • 跨开发,测试和生产的环境一致性:在便携式计算机上与在云中相同地运行。
  • 云和操作系统分发的可移植性:可在Ubuntu,RHEL,CoreOS,本地,Google Kubernetes Engine和其他任何地方运行。
  • 以应用程序为中心的管理:提高抽象级别,从在虚拟硬件上运行OS到使用逻辑资源在OS上运行应用程序。
  • 松散耦合,分布式,弹性,解放的微服务:应用程序被分解成较小的独立部分,并且可以动态部署和管理–而不是在一台大型单机上运行的整体堆栈。
  • 资源隔离:可预测的应用程序性能。
  • 资源利用:高效率和高密度

功能:

  • 服务发现和负载平衡
    Kubernetes可以使用DNS名称或使用其自己的IP地址公开容器。如果到容器的流量很高,Kubernetes可以负载平衡并分配网络流量,从而使部署稳定。
  • 存储编排
    Kubernetes允许您自动挂载您选择的存储系统,例如本地存储,公共云提供商等。
  • 自动部署和回滚
    您可以使用Kubernetes描述已部署容器的所需状态,并且可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化Kubernetes来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。
  • 自动垃圾箱打包
    您为Kubernetes提供了一个节点集群,可用于运行容器化任务。您告诉Kubernetes每个容器需要多少CPU和内存(RAM)。Kubernetes可以将容器安装到您的节点上,以充分利用您的资源。
  • 自我修复的
    Kubernetes会重启失败的容器,替换容器,杀死对用户定义的运行状况检查没有响应的容器,并且在准备好服务之前不会将其通告给客户端。
  • 秘密和配置管理
    Kubernetes允许您存储和管理敏感信息,例如密码,OAuth令牌和SSH密钥。您可以部署和更新机密和应用程序配置,而无需重建容器映像,也无需在堆栈配置中公开机密。

主要概念:

Pod:

一组紧密关联的容器集合,支持多个容器在一个Pod中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式完成服务,是Kubernetes调度的基本单位。Pod的设计理念是每个Pod都有一个唯一的IP。

  • 包含多个共享IPC、Network和UTC namespace的容器,可直接通过localhost通信
  • 所有Pod内容器都可以访问共享的Volume,可以访问共享数据
  • 优雅终止:Pod删除的时候先给其内的进程发送SIGTERM,等待一段时间(grace period)后才强制停止依然还在运行的进程
  • 特权容器(通过SecurityContext配置)具有改变系统配置的权限(在网络插件中大量应用)
  • 支持三种重启策略(restartPolicy),分别是:Always、OnFailure、Never
  • 支持三种镜像拉取策略(imagePullPolicy),分别是:Always、Never、IfNotPresent
  • 资源限制,Kubernetes通过CGroup限制容器的CPU以及内存等资源,可以设置request以及limit值
  • 健康检查,提供两种健康检查探针,分别是livenessProbe和redinessProbe,前者用于探测容器是否存活,如果探测失败,则根据重启策略进行重启操作,后者用于检查容器状态是否正常,如果检查容器状态不正常,则请求不会到达该Pod
  • Init container在所有容器运行之前执行,常用来初始化配置
  • 容器生命周期钩子函数,用于监听容器生命周期的特定事件,并在事件发生时执行已注册的回调函数,支持两种钩子函数:postStart和preStop,前者是在容器启动后执行,后者是在容器停止前执行

Namespace:

是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或者用户组。常见的pod、service、replicaSet和deployment等都是属于某一个namespace的(默认是default),而node, persistentVolumes等则不属于任何namespace。

  1. 删除一个namespace会自动删除所有属于该namespace的资源。
  2. default 和 kube-system 命名空间不可删除。
  3. PersistentVolumes是不属于任何namespace的,但PersistentVolumeClaim是属于某个特定namespace的。
  4. Events是否属于namespace取决于产生events的对象。

Node:

Pod真正运行的主机,可以是物理机也可以是虚拟机。Node本质上不是Kubernetes来创建的, Kubernetes只是管理Node上的资源。为了管理Pod,每个Node节点上至少需要运行container runtime(Docker)、kubelet和kube-proxy服务。

Service:

对一组提供相同功能的Pods的抽象,并为他们提供一个统一的入口,借助 Service 应用可以方便的实现服务发现与负载均衡,并实现应用的零宕机升级。Service通过标签(label)来选取后端Pod,一般配合ReplicaSet或者Deployment来保证后端容器的正常运行。service 有如下四种类型,默认是ClusterIP:

  • ClusterIP: 默认类型,自动分配一个仅集群内部可以访问的虚拟IP
  • NodePort: 在ClusterIP基础上为Service在每台机器上绑定一个端口,这样就可以通过 NodeIP:NodePort 来访问该服务
  • LoadBalancer: 在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器,并将请求转发到 NodeIP:NodePort
  • ExternalName: 将服务通过DNS CNAME记录方式转发到指定的域名

另外,也可以将已有的服务以Service的形式加入到Kubernetes集群中来,只需要在创建 Service 的时候不指定Label selector,而是在Service创建好后手动为其添加endpoint。

Ingress:

Kubernetes中的负载均衡我们主要用到了以下两种机制:

Service:使用Service提供集群内部的负载均衡,Kube-proxy负责将service请求负载均衡到后端的Pod中

Ingress Controller:使用Ingress提供集群外部的负载均衡

Service和Pod的IP仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到service所在节点暴露的端口上,然后再由kube-proxy通过边缘路由器将其转发到相关的Pod,Ingress可以给service提供集群外部访问的URL、负载均衡、HTTP路由等,为了配置这些Ingress规则,集群管理员需要部署一个Ingress Controller,它监听Ingress和service的变化,并根据规则配置负载均衡并提供访问入口。

常用的ingress controller:

nginx

traefik

Kong

Openresty

Service Account

Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的

授权

Service Account为服务提供了一种方便的认证机制,但它不关心授权的问题。可以配合RBAC(Role Based Access Control)来为Service Account鉴权,通过定义Role、RoleBinding、ClusterRole、ClusterRoleBinding来对sa进行授权。

Secret 密钥

Sercert-密钥解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。有如下三种类型:

Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中;

Opaque:base64编码格式的Secret,用来存储密码、密钥等;

kubernetes.io/dockerconfigjson: 用来存储私有docker registry的认证信息。

ConfigMap配置映射

ConfigMap用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。ConfigMap跟secret很类似,但它可以更方便地处理不包含敏感信息的字符串。ConfigMap可以通过三种方式在Pod中使用,三种分别方式为:设置环境变量、设置容器命令行参数以及在Volume中直接挂载文件或目录。 可以使用 kubectl create configmap从文件、目录或者key-value字符串创建等创建 ConfigMap。也可以通过 kubectl create-f value.yaml 创建。

shijy

作者shijy

发表评论

电子邮件地址不会被公开。 必填项已用*标注