etcd

[toc] RBAC: Role-Based Access Control，基于角色的权限控制，有以下三种角色 Role：角色，定义了一组API对象的操作权限 Subject：被作用者，可以是人，也可以是机器，也可以是k8s的用户，最常使用的就是ServiceAccoun RoleBinding：定义了Subject和Role的绑定关系 简单地说，RoleBinding指定ServiceAccount对应的Role，Pod绑定这个ServiceAccount获得挂载的secret访问APIServrer，ApiServer验证相应的权限 Pod使用RBAC示例 演示pod使用绑定了Roler的ServiceAccount示例 1.创建一个ServiceAccount apiVersion: v1 kind: ServiceAccount metadata: namespace: default name: cqh 2.创建一个Role kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: cqh rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]

作者 | 匡大虎、阚俊宝 导读： OLM(Operator Lifecycle Manager) 作为 Operator Framework 的一部分，可以帮助用户进行 Operator 的自动安装，升级及其生命周期的管理。同时 OLM 自身也是以 Operator 的形式进行安装部署，可以说它的工作方式是以 Operators 来管理 Operators，而它面向 Operator 提供了声明式 (declarative) 的自动化管理能力也完全符合 Kubernetes 交互的设计理念。本文我们将来了解一下 OLM 的基本架构和安装使用。 OLM 组件模型定义 OLM 的出现是为了帮助没有如大数据，云监控等领域知识的用户能够自助式地部署并管理像 etcd、大数据分析或监控服务等复杂的分布式应用。因此从它的设计目标来说，OLM 官方希望实现面向云原生应用提供以下几个方向上的通用管理能力，包括： 生命周期管理：管理 operator 自身以及监控资源模型的升级和生命周期； 服务发现：发现在集群中存在哪些 operator，这些 operators 管理了哪些资源模型以及又有哪些 operators 是可以被安装在集群中的； 打包能力：提供一种标准模式用于 operator 以及依赖组件的分发，安装和升级； 交互能力：在完成了上述能力的标准化后，还需要提供一种规范化的方式（如 CLI

一 、基本概念 kubernetes 中的 Node 、 Pod 、 Replication Controller 、 Service 等都是一种“资源对象”，基本都可以通过 kubectl 或者通过API编程调用，执行增删改查操作都保存在ETCD中持久化存储 1.1 Master 作用：每个k8s集群都需要一个mater节点来管理，master一般是单独部署 核心组件： Kubernetes API Server（kube-apiserver），提供HTTP REST 接口的关键服务进程，是k8s里所有资源增删改查 等操作的唯一入口 Kubernetes Controller Manager （kube-controller-manager），k8s所有资源的自动化控制中心。 Kubernetes Scheduler（kube-scheduler），调度（POD）的进程。 ETCD，master节点一般还启动一个ETCD Server进程，所有资源对象的数据全部保存在ETCD中 1.2 Node 除了Master，k8s集群的其他节点都称为Node节点，Node节点是k8s集群中的工作负载节点，当某个Node宕机，骑上的工作负载会被master自动转移到其他节点上 核心组件： kubelet：负责Pod对象的容器创建、启停等任务，同时与Master节点密切协作 kube

Apache Flink 进阶（四）：Flink on Yarn / K8s 原理剖析及实践 周凯波（宝牛） Flink 中文社区 本文根据 Apache Flink 进阶篇系列直播课程整理而成，由阿里巴巴技术专家周凯波（宝牛）分享，主要介绍 Flink on Yarn / K8s 的原理及应用实践，文章将从 Flink 架构、Flink on Yarn 原理及实践、Flink on Kubernetes 原理剖析三部分内容进行分享并对 Flink on Yarn/Kubernetes 中存在的部分问题进行了解答。 Flink 架构概览 Flink 架构概览–Job 用户通过 DataStream API、DataSet API、SQL 和 Table API 编写 Flink 任务，它会生成一个JobGraph。JobGraph 是由 source、map()、keyBy()/window()/apply() 和 Sink 等算子组成的。当 JobGraph 提交给 Flink 集群后，能够以 Local、Standalone、Yarn 和 Kubernetes 四种模式运行。 Flink 架构概览–JobManager JobManager的功能主要有： 将 JobGraph 转换成 Execution Graph，最终将 Execution Graph 拿来运行；

如何删除不一致状态下的 rc,deployment,service 在某些情况下,经常发现 kubectl 进程挂起现象,然后在 get 时候发现删了一半,而另外的删除不了 [root@k8s-master ~]# kubectl get -f fluentd-elasticsearch/ NAME DESIRED CURRENT READY AGE rc/elasticsearch-logging-v1 0 2 2 15h NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/kibana-logging 0 1 1 1 15h Error from server (NotFound): services "elasticsearch-logging" not found Error from server (NotFound): daemonsets.extensions "fluentd-es-v1.22" not found Error from server (NotFound): services "kibana-logging" not found 删除这些 deployment,service 或者 rc 命令如下: kubectl delete deployment kibana-logging -n kube

接着上面的博客继续写 　　pwd -> /etc/kubernetes/ssl 　　cp /etc/etcd/ssl/etcd-1-71.* . 　　cat apiserver　　 ### # kubernetes system config # # The following values are used to configure the kube - apiserver # # The address on the local server to listen to. KUBE_API_ADDRESS = " --bind-address=0.0.0.0 --insecure-bind-address=0.0.0.0 " # The port on the local server to listen on. KUBE_API_PORT = " --secure-port=6443 --insecure-port=8080 " # Port minions listen on # KUBELET_PORT = " --kubelet-port=10250 " # Comma separated list of nodes in the etcd cluster KUBE_ETCD_SERVERS = " --etcd-servers=https://192.168.1.71

API Server kube-apiserver 是 Kubernetes 最重要的核心组件之一，主要提供以下的功能 提供集群管理的 REST API 接口，包括认证授权、数据校验以及集群状态变更等 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 API Server 查询或修改数据，只有 API Server 才直接操作 etcd） 工作原理 kube-apiserver 提供了 Kubernetes 的 REST API，实现了认证、授权、准入控制等安全校验功能，同时也负责集群状态的存储操作（通过 etcd）。 API 访问 有多种方式可以访问 Kubernetes 提供的 REST API： 1、kubectl 命令行工具 2、SDK，支持多种语言 Go Python Javascript Java CSharp 3、其他 OpenAPI 支持的语言，可以通过 gen 工具生成相应的 client kubectl kubectl get --raw /api/v1/namespaces kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods kubectl proxy $ kubectl proxy --port

kubernetes 增强特性(kep)是为了解决社区中的疑难问题而创建的一个项目，每一个增强特性都对 kubernetes 的部分功能有较大的影响，需要 kubernetes 项目下的多个组(SIG)协作开发，对应的特性通常要经过 alpha 、 beta 以及 GA 三个版本，所以每个方案的开发周期比较长，大多需要经过 9~10 个月才能完成，某些特性甚至已经讨论多年至今仍未开发完成，像 crd、dry-run、kubectl diff、pid limit 等已经开发完成的功能都是在 kep 中提出来的。本文会介绍几个比较重要的已经在 kep 中孵化的特性。 1、client-go 中对 resource 的操作支持传递 context 参数 该特性的目标： （1）支持请求超时以及取消请求的调用； （2）支持分布式追踪； 以下是新旧版本中用 client-go list deployment 方式的一个对比： // 老版本中的使用方式 deploymentList, _ := clientset.AppsV1().Deployments(apiv1.NamespaceDefault). List ( metav1.ListOptions{}) // 新版本中的使用方式 deploymentList, err := clientset.AppsV1().Deployments

一、k8s是什么？ Kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务，通过Kubernetes能够进行应用的自动化部署和扩缩容。在Kubernetes中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。 二、基本概念理解： 1、master：管理整个的调度流程。 1.1API Server：是master与node交互的接口，同时此接口也是面向用户的(用户指令)。 1.1.1kubectl：集群管理命令行工具集，kube指令。 1.1.2RestAPI：接口，配置文件。 1.1.3WebUI：可操作的图形化界面。 1.2Controller-Manager：内部管理控制中心，实现集群故障检测和恢复的自动化工作，负责执行各种控制器。 1.3Scheduler：收集和分析当前集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 1.4ETCD：数据库，存数据以及节点的状态 。 备注：Controller-Manager+Scheduler：相互调度，基于ECTD数据库的数据，生成指令，下发给node，再记录到ETCD。 2、node：worker一般会有多个 。 2.1kubelet：master API Server与Nod的通信桥梁，节点上的pod管家。 2.2kube-proxy