提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
前言
k8s学习记录。官网：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1/
一、k8s基本图解
二、k8s分层架构
三、核心概念及基本原理
1. 服务分类
有状态和无状态
无状态应用： 不会对本地环境产生任何依赖，例如不会存储数据到本地磁盘。（Nginx、Apache）
优点：对客户端透明，无依赖关系，可以高效实现扩容、迁移
缺点：不能存储数据，需要额外的数据服务支持
有状态应用： 会对本地环境产生依赖，例如：需要存储数据到本地磁盘。（Mysql、Redis）
优点：可以独立存储数据，实现数据管理
缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂
2. 资源分类
元数据型、集群级和命名空间级。
元数据型
Hoeizontal Pod Autoscaler（HPA）、PodTemplate、LimitRange等
Hoeizontal Pod Autoscaler（HPA）：可以根据CPU使用率或自定义指标（metrics）自动对Pod进行扩容和缩容。
——
控制管理器每隔30s（可以通过horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况。
——
支持三种metrices类型
- 预定义metrics（eg.Pod的CPU）以利用率的方式计算
- 自定义的Pod metrics，以原始值（raw value）的方式计算
- 自定义的object metrics
——
支持两种metrics查询方式：Heapster和自定义RESTAPI
——
支持多metrics
——
PodTemplate：关于Pod的定义，但是会被包含在其他的kubernetes对象中（例如Deployment、StatefulSet、DaemonSet等控制器）。控制器通过Pod Template信息来创建Pod。
LimitRange：可以对集群内Request和Limits的配置做一个全局的统一的限制，相当于批量设置了一个某一个范围内（某个命名空间）的Pod资源使用限制。
集群级别
Namespace、Node、ClusterRole、ClusterRoleBuinding等
Node：不像其他的资源（如Pod和Namespace），Node本质上不是kubernetes来创建的，Kubernates只是管理Node上的资源。虽然可以通过Manifest创建一个Node对象，但Kubernetes也只是去检查是否真的时有这么一个Node，如果检查失败，也不会网上调度Pod。
命名空间级
工作负载型
Pod（容器组）：
是Kubernetes中最小的可部署单元。一个Pod包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络IP地址、以及一些确定容器该如何运行的选项。Pod容器组代表了Kubernetes中的一个独立的应用程序运行实例，该实例可能由单个或者几个紧耦合在一起的容器组成。
Docker是Kubernetes Pod中使用最广泛的容器引擎，Kubernetes Pod同时也支持其他类型的容器引擎。
Kubernetes集群中的Pod存在如下两种使用途径：
1. 一个Pod中只运行一个容器。“onr-container-per-pod”是Kubernetes中最常见的使用方式。此时，可以认为Pod容器组是该容器的wrapper，Kubernetes通过Pod管理容器而不是直接管理容器。
2. 一个Pod中运行多个需要互相协作的容器。可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个Pod中。
副本（replicas）
一个Pod可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（Pod的名字、uid等）不一样意以外，其他信息都是一样的，譬如Pod内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。
Pod的“控制器”通常包含一个名为“replicas”的属性。“replicas”属性则指定了特定Pod的副本数量，当当前集群中按照Pod的数量与该属性指定的值不一致时，k8s会采取一些策略去使得当前状态满足配置的要求。
控制器
-
适用无状态服务：
RelplcationController(RC)（已被RS替代）、ReplicaSet(RS)、Deployment
RelplcationController(RC)：帮助我们动态更新Pod副本数。
ReplicaSet(RS)：帮助我们动态更新Pod副本数，可以通过selector来选择对哪些Pod生效。
Deployment：针对RS的更高层次的封装，提供了更丰富的部署相关功能。创建Replica Set/Pod、滚动升级/回滚、平滑扩容和缩容、暂停与回复Deployment（避免频繁更新（滚动升级），可先暂停等变更完成再恢复更新） -
适用有状态服务
StatefulSet:StateSet中每个Pod的DNS格式为statefulSetName-(0…N-1).serviceName.namespace.svc.cluster.local
——serviceName为Headless Service的名字
——0…N-1为Pod所在序号。从0开始带N-1
——statefulSetName为StatefulSet的名字
——namespace为服务所在的namespace。Headless Service和StatefulSet必须在相同的namespace
——.cluster.local为Cluster Domain
主要特点：稳定的持久化存储、稳定的网络状态、有序部署，有序扩展、有序收缩，有序删除
组成：Headless Service、volumeClaimTemplate
注意事项：
1、Kubernetesv1.5版本以上才支持
2、所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好
3、为了保证数据安全，删除StatefulSet时不会删除Volume
4、StatefulSet需要一个Headless Service来定义DNS domain（Domain Name Server：域名服务，将域名与IP绑定映射关系 服务名->访问路径（域名）->IP），需要在StatefulSet之前创建好。 -
守护进程
DaemonSet：保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：
——日志收集，比如fluentd，logstash等
——系统监控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
——系统程序，比如kube-proxy,Kube-dns,glusterd,ceph等
-
任务/定时任务
Job、CronJob。
Job：一次性任务，运行完成后Pod销毁，不再重新启动新容器。
CronJob：在Job的基础上加上了定时功能。
服务发现
Service
“Service"简写"svc”。Pod不能直接提供给外网访问，而是应该使用service。Service就是把Pod暴露出来提供服务。Service才是真正的“服务”。它的中文名就叫“服务”。
可以说Service是一个应用服务的抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。Service代理Pod集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端Pod中的容器。
Ingress
Ingress实现将k8s内部服务暴露给外网访问的服务
存储
Volume
数据卷，共享Pod中容器使用的数据。用来放持久化的数据，比如数据库数据。
CSI
Container Storage Interface 是由来自Kuberbetes、Mesos、Docker等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。
CSI规范定义了存储提供商实现CSI兼容的Volume Plugin的最小操作集和部署建议。CSI规范主要焦点是生命Volume Plugin必须实现的接口。
特殊类型配置
ConfigMap
Kubernetes 中用于存储非敏感配置数据的 API 对象，支持以键值对（Key-Value）或文件的形式存储配置，允许将配置与镜像解耦，实现配置的集中管理和动态更新。
Secret
Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以colume或者环境变量的方式使用。
Secret有三种类型：
——Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
——Opaque：base64编码格式的Secret，用来存储密码、密钥等
——Kuberbetes.io/dockercinfigjson：用来存储私有dockerregistry的认证信息。
DownwardAPI
downwardAPI这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是来进行容器和宿主机的数据交换的，而是让Pod里的容器能够直接获取到这个Pod对象本身的一些信息。
downwardAPI提供了两种方式用于将Pod的信息注入到容器内部：
环境变量：用于单个变量，可以将Pod信息和容器信息直接注入容器内部
volume挂载：将pod信息生成为文件，直接挂载到同期内部中去。
其他
Role
一组权限集合，例如Role可以包含列出Pod权限及列出Deployment权限，Role用于给某个Namespace中的资源进行鉴权。
RoleBinding
用于将角色（Role）绑定到一个或多个主体（Subject），从而授予这些主体在特定命名空间中的权限。RoleBinding 可以引用同一命名空间中的 Role 或全局命名空间中的 ClusterRole。
RoleBinding 的定义包括以下几个关键部分：
apiVersion: 指定 API 版本，例如 rbac.authorization.k8s.io/v1。
kind: 资源类型，这里是 RoleBinding。
metadata: 包含对象的元数据，例如名称和命名空间。
roleRef: 引用被绑定的角色，包含角色的 API 组、类型和名称。
subjects: 包含被授予权限的主体列表，可以是用户、用户组或服务账户
3. 对象规约和状态
规约（spec）：描述了对象的期望状态——希望对象所具有的特征。当创建Kubernetes对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本星系（例如名称）
状态（Status）：表示对象的实际状态，该属性由k8s自己维护，k8s会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
