prometheus传统架构安装

全局配置选项 text 1 2 3 4 5 6 7 scrape_interval: 采集生命周期 scrape_timeout: 采集超时时间 evaluation_interval: 告警评估周期 rule_files 监控告警规则 scrape_config: 被监控端 altering 检查配置文件语法 text 1 2 3 $ promtool check config \etc\prometheus.yml Checking \etc\prometheus.yml SUCCESS: 0 rule files found 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) \ node_memory_MemTotal_bytes * 100 计算剩余空间 node_filesystem_free_bytes{mountpoint="",fstype=~“ext4|xfs”} \ node_filesystem_size_bytes{mountpoint="",fstype=~“ext4|xfs”} * 100 查看使用的百分比 100-node_filesystem_free_bytes{mountpoint="",fstype=~“ext4|xfs”} \ node_filesystem_size_bytes{mountpoint="",fstype=~“ext4|xfs”} * 100 prometheus使用influxdb [Prometheus endpoints support in InfluxDB | InfluxData Documentation](https:\docs.influxdata.com\influxdb\v1.7\supported_protocols\prometheus) [Configuration | Prometheus](https:\prometheus.io\docs\prometheus\latest\configuration\configuration) 配置文件参考 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 global: alerting: alertmanagers: - static_configs: - targets: rule_files: scrape_configs: - job_name: 'prometheus1' file_sd_configs: - files: ['\data\sd_config\test....

Go每日一库 - cobra

Cobra功能 简单子命令cli 如 kubectl verion kubectl get 自动识别-h,–help 帮助 更过参考官方手册:https://github.com/spf13/cobra kubectl get pod --all-namespaces get 代表命令(command) pod 代表事务(args) --all-namespaces 代表标识(flag) command 代表动作, Args 代表事务, flags 代表动作的修饰符。 使用Cobra 使用cobra需要main.go或和cmd/cmd.go(非固定,根据官方手册说明操作的),来创建需要添加的命令。 cobra不需要构造函数,只需要创建命令即可 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 rootCmd = &cobra.Command{ Use: "db ", Short: "test1", Long: `this is a test123`, Run: func(cmd *cobra.Command, args []string) { log.Println(cfgFile, port) }, } func Execute() { if err := rootCmd....

Go每日一库 - cronexpr

包获取:go get -u github.com/gorhill/cronexpr 创建一个定时任务 go 1 expr, err = cron.Parse("* * * * *"); 获得任务的下次执行时间 go 1 nextTime = expr.Next(now) 完整代码 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 package main import ( "fmt" "time" cron "github....

使用二进制文件构建k8s集群

Kubernetes集群的构成 Master Node (Control plane) Master 是整个 Kubernetes 集群构成的基础,它负责整个集群的管理,例如处理集群的状态;组件包含 API Server, Controller manager, Scheduller, Etcd API server API 服务器是 Master 的统一前端入口,负责集群内其他组件的 协调 与 通信。该组件用于定义集群的状态。可以通过命令行, HTTP API, 第三方托管平台(dashboard, Rancker, Kuboard等)与 Kubernetes API 进行交互。 Scheduler 调度程序 Scheduler 负责根据可用资源来决定如何去部署容器,部署到哪里?确保所有 Pod(容器组)都分配给某一组节点。 Controller Manager Controller manager,又分为Controller 和 Manager,Controller的组要作用是用于协调各种控制器(Deployment, Daemonset…),这些控制器可确保在节点发生故障时采取适当的措施。而 Manager 则管理的众多Controller;更一般地说,CM 负责随时将集群的当前状态调整到所需状态(Kubernetes设计基石)。 etcd etcd 是控制平面内的一个组件,他提供了 Kubernetes 资源的存储,并为集群内组件提供了 Watch 的功能,这将意味着,etcd 在 kubernetes 集群中作为存储与分布式协调的功能。 Worker nodes 每个集群中至少需要存在一个工作节点,但是通常会有大量的节点;而工作节点包括的组件不限于 Kubelet, Kube-proxy, CNI Plugin。 Kubelet kubelet是工作节点中管理运行时的组件,负责整个Pod (容器组)进程的生命周期 Kube-proxy Kube-proxy 为整个集群内提供了 service 的功能,如果这个组件无法正常工作,那么整个集群内的网络通信将不能正常,因为 service 是作为集群内服务的访问入口,包含 Kubernetes API service。...

Go byte与rune区别

先看代码 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 package main import ( "fmt" ) func main() { var a = "hello world" var b = "中" fmt.Println([]rune(a)) fmt.Println([]rune(b)) fmt.Println([]byte(b)) } go源码中的定义 go 1 2 3 4 5 6 7 8 // byte is an alias for uint8 and is equivalent to uint8 in all ways. It is // used, by convention, to distinguish byte values from 8-bit unsigned // integer values....

Go每日一库 - bufio缓冲区的终端输入

bufio包实现了有缓冲的I/O。它包装一个io.Reader或io.Writer接口对象,os.stdin就是实现了这个接口 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 package main import ( "bufio" "fmt" "os" ) var buff *bufio.Reader func main() { buff = bufio.NewReader(os.Stdin) str, err := buff.ReadString('\n') if err == nil { fmt.Printf("input was :%s", str) } } ReadString(byte) 遇到byte后返回,包含已读到的和byte,如果在读到之前遇到错误,返回读取的信息及该错误 在写文件时。可以写入缓冲区来可以提升磁盘性能

etcd二进制安装与配置

概述 etcd 是兼具一致性和高可用性的键值数据库,为云原生架构中重要的基础组件,由CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册与发现,还可以作为 key-value 存储的中间件。 先决条件 运行的 etcd 集群个数成员为奇数。 etcd 是一个 leader-based 分布式系统。确保主节点定期向所有从节点发送心跳,以保持集群稳定。 保持稳定的 etcd 集群对 Kubernetes 集群的稳定性至关重要。因此,请在专用机器或隔离环境上运行 etcd 集群,以满足所需资源需求]。 确保不发生资源不足。 集群的性能和稳定性对网络和磁盘 IO 非常敏感。任何资源匮乏都会导致心跳超时,从而导致集群的不稳定。不稳定的情况表明没有选出任何主节点。在这种情况下,集群不能对其当前状态进行任何更改,这意味着不能调度新的 pod。 相关术语 Raft:etcd所采用的保证分布式系统强一致性的算法。 Node:节点 ,Raft状态机的一个实例,具有唯一标识。 Member: 成员,一个etcd实例。承载一个Node,且可为客户端请求提供服务。 Cluster:集群,由多个Member构成可以协同工作的etcd集群。 Peer:同伴,Cluster中其他成员。 Proposal :提议,一个需要完成 raft 协议的请求(例如写请求,配置修改请求)。 Client: 向etcd集群发送HTTP请求的客户端。 WAL:预写式日志,etcd用于持久化存储的日志格式。 snapshot:etcd防止WAL文件过多而设置的快照,存储etcd数据状态。 Proxy:etcd的一种模式,为etcd集群提供反向代理服务。 Leader:Raft算法中通过竞选而产生的处理所有数据提交的节点。 Follower:竞选失败的节点作为Raft中的从属节点,为算法提供强一致性保证。 Candidate:当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。 Term:某个节点成为Leader到下一次竞选时间,称为Ubuntu一个Term。 Index:数据项编号。Raft中通过Term和Index来定位数据。 ETCD 部署 源码安装 基于master分支构建etcd bash 1 2 3 git clone https://github.com/etcd-io/etcd.git cd etcd ./build # 如脚本格式为dos的,需要将其格式修改为unix,否则报错。 启动命令 --listen-client-urls 于 --listen-peer-urls 不能为域名...

Logstash使用

1 logstash概述 logstash是基于Jruby语言研发的server/agent结构的日志收集工具,可以在任何一个能产生日志的服务器上部署其agent。agent能同时监控多个产生日志的服务,并把每个服务所产生的日志信息收集并发送给logstash server端。由于收集到的日志信息是分散的,logstash有专门的节点用来将所有的节点收集到的日志信息按时间序列合并在一起形成一个序列,基于这一个序列请求写入并存储在elasticsearch集群中。 kibana是基于node.js开发的elasticsearch的图形用户接口。它可以将用户的搜索语句发送给ES,有ES完成搜索,并且将结果返回。kibana可以将返回的数据,用非常直观的方式(画图)来做趋势展示的。 logstash基于多种数据获取机制,TCP/UDP协议、文件、syslog、windows EventLogs及STDIN等。同时也支持多种数据输出机制。获取到数据后,它支持对数据执行过滤、修改等操作。 logstash基于JRuby语言研发,需要运行在JVM虚拟机之上。工作于agent/server模型。 1.1 logstash工作机制 在每一个产生日志的节点之上部署一个agent,这个agent通常称为shipper。shipper负责收集日志,并且发送给server端。但是在发送给server端时,为了避免server端可能无法应付大量节点同时发来的信息,会在server端和agent端之间放置一个消息队列,通常称之为broker。这个消息队列比较常见的使用redis。各agent将数据发送至broker,logstash服务器会从broker中依次取出日志拿来在本地做过滤、修改等操作。在完修改后将其发送至ES集群。 对于logstash而言,server端也是插件式的工作的模式,与ES的不同在于,ES的插件是可有可无的。logstash的除核心外的所有功能都是基于插件来完成的。 1.2 logstash工作流程 logstash的工作模式类似于管道,从指定位置读入数据,而后过滤数据,最后将其输出到指定位置。事实上logstash的工作流程为:input | filter | output。如无需对数据额外处理,filter可省略。 1.3 logstash插件分类 input plugin:收集数据 codec plugin:编码插件 filter plugin:过滤 output plugin:输出插件 2 logstash安装下载 官网地址:https://www.elastic.co/cn/products../../images/Logstash 3 logstash的配置使用 /etc../../images/Logstash/conf.d/路径下所有以.conf结尾的文件都被当做配置文件使用。对于logstash的配置文件定义,就是定义插件。从哪得到数据。向哪里输出数据。 3.1 logstash的基本配置框架 sh 1 2 3 4 5 6 7 8 9 10 11 input{ .... } filter{ .... } output{ .... } 简单的 sh 1 2 3 4 5 6 7 8 input{ stdin {} } output { stdout{ codec =>rubydebug } } 检查配置文件语法是否正确logstash -f /etc....

jenkins pipeline docker方式

pipline def timestr() { script { return sh(script: 'date +%Y%m%d%H%M%S', returnStdout: true).trim() } } def dockerImage pipeline{ agent any environment { time = timestr() registry = "xxx.com/payapp-test" registryhub = "txhub.xxx.com" appName = "api" } options { timeout(time: 1, unit: 'HOURS') buildDiscarder(logRotator(numToKeepStr: '15')) disableConcurrentBuilds() } stages{ stage("Pull Code"){ steps{ git branch: 'testing', credentialsId: '422fb2c7-4d58-440a-98a4-e242b66f3800', url: 'http://gitlab.fgry45iy.com:90/pay/payGateway.git' } } stage("Maven Package"){ steps{ withEnv(['PATH+EXTRA=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/apache-maven-3.6.2/bin:/usr/local/maven/bin:/root/bin']) { sh "mvn package" } } } // stage('Building Image') { // steps{ // script { // dockerImage = docker....

ELK收集syslog

Logstash通过网络将syslog消息作为事件读取。使用用 UDPSocket, TCPServer 和 LogStash::Filters::Grok 来实现 配置示例 sh 1 2 3 4 5 input { syslog{ port => "514" } } 配置客户端,在修改linux主机/etc/rsyslog.conf sh 1 *.* @@host:port 配置说明 参数 说明 * 类型 * 级别 @ udp @@ tcp host 可为主机名或ip地址 注:收集到的数据,本身就以及是rsyslog格式了,无需再进行grok sh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "message" => "(root) CMD (/bin/echo 1111 >>/root/1.txt)\n", "@version" => "1", "@timestamp" => "2018-10-05T12:13:01.000Z", "host" => "10....

ELK收集java日志

Java日志多由多行行组成,初始行之后的每一行以空格开头,如下例所示:在这种情况下,需要在将事件数据output之前处理多行事件。 text 1 2 3 4 5 [ERROR] - 2018-09-21 04:19:57.685 (SocketTransfer.java:73) - Socket交互遇到错误 Exception in thread "main" java.lang.NullPointerException at com.example.myproject.Book.getTitle(Book.java:16) at com.example.myproject.Author.getBookTitles(Author.java:25) at com.example.myproject.Bootstrap.main(Bootstrap.java:14) 配置multiline参数如下:Multiline codec plugin 参数 说明 pattern 指定正则表达式。与指定正则表达式匹配的行被视为前一行的延续或新多行事件的开始。 what previous或next。该previous值指定与pattern选项中的值匹配的行是上一行的一部分。该next值指定与pattern选项中的值匹配的行是以下行的一部分 negate true或false(默认为false)。如果true,与pattern模式不匹配的消息将构成多行过滤器的匹配what并将应用。 sh 1 2 3 4 5 6 7 8 9 10 11 12 input { file { path => "/root/apache-tomcat-8.5.34/logs/catalina.out" type => "sk" start_position => "beginning" codec => multiline { pattern => "^\[" negate => "true" what => "previous" } } } 如上列日志格式为...

elasticsearch安装

1 elasticsearch介绍 ES是一个基于Lucene实现的开源、分布式、基于Restful风格的全文本搜索引擎;此外,它还是一个分布式实时文档存储,其中每个文档的每个field均是被索引的数据,且可被搜索:也是一个带实时分析功能的分布式搜索引擎,能够扩展至数以百计的节点实时处理PB级的数据。 1.1 elasticsearch基本组件 索引(index):文档容器,换句话说,索引是具有类似属性的文档的集合。类似于表。索引名必须使用小写字母: 类型(type):类型是索引内部的逻辑分区,其意义完全取决于用户需求。一个索引内部可定义一个或多个类型。一般来说,类型就是拥有相同的域的文档的预定义。 文档(document):文档是Lucene索引和搜索的原子单位,它包含了一个或多个域。是域的容器:基于J50N格式表示。每个域的组成部分:一个名字,一个或多个值;拥有多个值的域,通常称为多值域: 映射(mapping):原始内容存储为文档之前需要事先进行分析,例如切词、过滤掉某些词等:映射用于定义此分析机制该如何实现;除此之外,ES还为映射提供了诸如将域中的内容排序等功能。 1.2 es的集群组件 cluster: es的集群标识为集群名称:默认“elasticsearch”。节点就是靠此名字来决定加入到哪个集群中。一个节点只能属性于一个集群。 Node:运行了单个es实例的主机即为节点。用于存储数据、参与集群索引及搜索操作。节点的标识靠节点名。 Shard:将索引切割成为的物理存储组件:但每一个shard都是一个独立且完整的索引;创建索引时,ES默认将其分割为5个shard,用户也可以按需自定义,创建完成之后不可修改。 shard有两种类型:primary shard和replica。replica用于数据冗余及查询时的负载均衡。每个主shard的副本数量可自定义,且可动态修改。 1.3 es的工作过程 es节点启动时默认通过多播方式或单播方式在TCP协议的9300端口查找同一集群中的其他节点,并与之建立通讯。判断是否为同一集群的标准为集群名称,集群中的所有节点会选举出一个主节点负责管理整个集群状态,以及在集群范围内决定各shared的分布方式。站在用户使用中角度而言,每个节点都可以接收并相应各类请求,无需区分哪个为主节点。 当集群中某一节点为down状态时,主节点会读取集群状态信息,并启动修复过程。此过程中主节点会检查所有可用shared的主shared,并确定主shared是否存在。各种shared及对应副本shared是否对数。此时集群状态会转换为yellow。 es集群有三种状态:green、red(不可用)、yellow(修复状态)。 当某状态为down的节点上存在主shared,此时需要从各副本shared中找一个提升为主shared。在yellow状态时,各副本shared均处于未分配模式。此时各个副本都不可用,只能使用主shared。集群虽可基于各组shared进行查询,但此时吞吐能力有限。yellows属于残破不全状态。 接下来的过程中,主节点将会查找所有的冗余shard,并将其配置为主shared。如果某shared的副本数量少于配置参数的数量,会自动启动复制过程,并为其建立副本shared。直至所有条件都满足从yellow转换至green。 es工作过程中主节点会周期性检查各节点是否处于可用状态,任意节点不可用时,修复模式都会启动,此时集群将会进入重新均衡过程。 2 安装elasticsearch 下载地址:http://www.elastic.co/cn/downloads/elasticsearch 官方文档中写明对es每个版本对jdk的要求。 https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html 2.1 常用es配置文件说明 修改配置文件:/etc/elasticsearch/elasticsearch.yml sh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 cluster....

Go数组排序算法

冒泡排序 图 https://www.cnblogs.com/onepixel/articles/7674659.html go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 package main import ( "fmt" ) func bubbleSort(slice []int) []int { for n := 0; n <= len(slice); n++ { for i := 1; i < len(slice)-n; i++ { if slice[i] < slice[i-1] { slice[i], slice[i-1] = slice[i-1], slice[i] } } } return slice } func main() { var arr = [....

Jenkins在windows平台自动化构建代码

Jenkins服务端:centos6.8 客户端:windows server2012 windows10 工具:cwRsync 注:复制为jenkins工作目录到网站目录,无需服务端。 配置安装slave端 所用的插件:Copy Data To Workspace Plugin 配置windows节点 \1. 主界面->【系统管理】->【管理节点】->【新建节点】,进行节点的添加: \2. 输入节点名称,选择【Permanent Agent】。如果添加过slave的话会出现【复制现有节点】操作 \3. 配置节点的详细信息 此处配置需要注意的有以下几个方面 【# of executors】:建议不要超过CPU核心数,一般不要写特别大。 【远程工作目录】:master将代码库中的代码复制到slave时,存放的临时目录,如slave的daemon服务也会放在此目录。一个job一个文件夹。 【用法】:选择【只允许运行绑定到这台机器的Job】,此模式下,Jenkins只会构建哪些分配到这台机器的Job。这允许一个节点专门保留给某种类型的Job。例如,在Jenkins上连续的执行测试,你可以设置执行者数量为1,那么同一时间就只会有一个构建,一个实行者不会阻止其它构建,其它构建会在另外的节点运行。 【启动方式】:选择【Launch agent via Java Web Start】,以windows服务的方式启动,这个为最好配置的。注意:2.x版本的默认没有这个选项,需要单独开启。 \4. 配置slave端并且添加至windows服务 在点击保存后,在node列表中会存在此列表默认是未连通状态 点击进入详情页面会提示slave端的安装方法,此处讲解下载文件方式。 【Launch】:浏览器下载文件方式 【Run from agent command line】:从远端代理命令运行 注意:这是java服务,每个slave端必须安装jdk后才可运行。 xml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 <jnlp codebase="http://10.0.0.11:8080/jenkins/computer/test/" spec="1.0+"> <information> <title>Agent for test</title> <vendor>Jenkins project</vendor> <homepage href="https://jenkins-ci....

Kubernetes存储卷

在Kubernetes之上,在节点级提供一个存储卷的方式来持久存储数据的逻辑,这种只具备一定程度上的持久性。为了实现更强大的持久性,应该使用脱离节点而存在的共享存储设备。 为此Kubernetes提供了不同类型的存储卷。 大多数和数据存储服务相关的应用,和有状态应用几乎都是需要持久存储数据的。容器本身是有生命周期的,为了使容器终结后可以将其删除,或者编排至其他节点上去运行。意味着数据不能存储在容器本地。一旦Pod故障就会触发重构。如果将数据放置在Pod自有的容器内名称空间中,数据随着Pod终结而结束。为了突破Pod生命周期的限制,需要将数据放置在Pod自有文件系统之外的地方。 存储卷 对Kubernetes来讲,存储卷不属于容器,而属于Pod。因此,在Kubernetes中同一个Pod内的多个容器可共享访问同一组存储卷。 Pod底部有一个基础容器, ==pause==,但是不会启动。pause是基础架构容器。创建Pod时pause时Pod的根,所有Pod,包括网络命名空间等分配都是分配给pause的。在Pod中运行的容器是pause的网络名称空间的。容器在挂载存储卷时,实际上是复制pause的存储卷。 因此为了真的实现持久性,存储卷应为宿主机挂载的外部存储设备的存储卷。如果需要实现跨节点持久,一般而言需要使用脱离节点本地的网络存储设备(ceph、glusterfs、nfs)来实现。节点如果需要使用此种存储的话,需要可以驱动相应存储设备才可以(在节点级可以访问相应网络存储设备)。 k8s之上可使用的存储卷 Kubernetes支持的存储卷类型 empryDir:只在节点本地使用的,用于做临时目录,或当缓存使用。一旦Pod删除,存储卷一并被删除。empryDir背后关联的宿主机目录可以使宿主机的内存。 hostPath:使宿主机目录与容器建立关联关系。 网络存储 传统的SAN(iSCSI,FC)NAS(常见用法协议 NFS,cifs,http)设备所构建的网络存储设备。 分布式存储(分机系统或块级别),glusterfs,ceph(rbd ceph的块接口存储),cephfs等。 云存储:EBS(弹性块存储)亚马逊 ,Azure Disk 微软。此模型只适用于Kubernetes集群托管在其公有云之上的场景。 使用kubectl explain pod.spec.volumes查看Kubernetes所支持的存储类型。 emptyDir 语法 emptyDir medium 媒介类型 empty string (disk 默认) or memory sizeLimit 空间上限 定义完存储卷之后,需要在container当中使用volumeMounts指明挂载哪个或哪些个存储卷 yaml 1 2 3 4 5 - container - mountPath 挂载路径 - name 挂载那个卷 - readOnly 是否只读挂载 - subPath 是否挂载子路径之下 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 apiVersion: v1 kind: Pod metadata: name: my-nginx namespace: default spec: containers: - name: busybox image: busybox imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 command: ["tail"] volumeMounts: # 指明挂载哪一个存储卷 - name: html mountPath: /data/web/html # 指明挂载到容器的哪个路径下 volumes: - name: html emptyDir: {} # 表示空映射,都使用默认值,大小不限制,使用磁盘空间,而不是不定义 在Kubernetes中 $()是变量引用...

kubernetes概念 - serviceaccount

在整个Kubernetes集群来讲 apiserver是访问控制的唯一入口。如通过service或ingress暴露之后,是可以不通过apiserver接入的,只需要通过节点的nodePort或者ingress controller daemonset共享宿主机节点网络名称空间监听的宿主机网络地址(节点地址),直接接入。 当请求到达APIServer时,会经历几个阶段,如图所示 图:Kubernetes API 请求的请求处理步骤图 Source:https://kubevious.io/blog/post/securing-kubernetes-using-pod-security-policy-admission-controller 任何用户(sa与人类用户)在通过任何方式试图操作API资源时,必须要经历下列的操作: Authentication,这个步骤在建立TLS连接后,验证包含,证书、密码,Token;可以指定多种认证,依次尝试每一个,直到其中一个认证成功。如果认证失败,此时客户端收到的是401。 Authorization,此步骤是在完成 Authentication 后确定了来源用户,此时用户的请求动作必须被授权。如bob用户对pod资源有 get , list 权限操作。如果 Admission Control:此步骤为图3,与 Authorization 不同的时,这里只要有任意准入控制器拒绝,则拒绝;多个准入控制器会按顺序执行 Refer to controlling access 认证 Kubernetes是高度模块化设计的,因此其认证授权与准入控制是各自都通过插件的方式,可由用户自定义选择经由什么样的插件来完成何种控制逻辑。如对称秘钥认证方式、令牌认证。由于Kubernetes提供的是resetful方式的接口,其服务都是通过HTTP协议提供的,因此认证信息只能经由HTTP协议的认证首部进行传递,此认证首部通常被称作认证令牌(token)。 ssl认证,对于Kubernetes访问来讲,ssl证书能让客户端去确认服务器的身份,(要求服务端发送服务端证书,确认证书是否为认可的CA签署的。)在Kubernetes通信过程当中,重要的是服务器还需认证客户端的身份,因此==Kubectl也应有一个证书,并且此证书为server端所认可的CA所签署的证书==。并且客户端身份也要与证书当中标识的身份保持一致。双方需互相做双向证书认证。认证之后双方基于SSL会话实现加密通讯。 注:kubernetes认证无需执行串行检查,用户经过任何一个认证插件通过后,即表示认证通过,无需再经由其他插件进行检查。 授权 kubernetes的授权也支持多种授权插件来完成用户的权限检查,kubernetes 1.6之后开始支持基于RBAC的认证。除此只外还有基于节点的认证、webhook基于http回调机制,通过web的rest服务来实现认证的检查机制。最重要的是RBAC的授权检查机制。基于角色的访问控制,通常只有许可授权,没有拒绝授权。默认都是拒绝。 在默认情况下,使用kubeadm部署Kubernetes集群是强制启用了RBAC认证的。 准入控制 一般而言,准入控制本身只是用来定义对应授权检查完成之后的后续其他安全检查操作的。 用户账号 一般而言用户账号大体上应具有以下信息 user 用户,一般而言由username与userid组成。 group 用户组 extra 用来提供额外信息 API资源 k8sapiserver是分组的,向哪个组,哪个版本的哪个api资源对象发出请求必须进行标识,所有的请求资源通过url path进行标识的。如 /apis/apps/v1/,所有名称空间级别的资源在访问时一般都需指名namespaces关键词,并给出namespaces名称来获取 /apis/apps/v1/namespaces/default/ /apis/apps/v1/namespaces/default/nginx 。 一个完整意义上的url 对象引用url格式 ==/apis/<GROUPS>/<VERSION>/namespaces/<NameSpace_name>/<Kind>/[/object_id]== bash 1 2 3 $ kubectl api-versions admissionregistration.k8s.io/v1beta1 ... Kubernetes中,所有的api都取决于一个根 /apis text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 $ curl -k --cert /etc/k8s/pki/apiserver-kubelet-client....

kubernetes概念 - Service

在Kubernetes集群中,Pod是有生命周期的,为了能够给对应的客户端提供一个固定访问端点,因此在客户端与服务端(Pod之间)添加了一个固定中间层,这个中间层被称之为Service。Service的工作严重依赖于在Kubernetes集群之上,部署的附件Kubernetes DNS服务。较新版本使用的coreDNS,1.11之前使用的KubeDNS。 service的名称解析是强依赖于DNS附件的。因此在部署完Kubernetes后,需要部署CoreDNS或KubeDNS。 Kubernetes要想向客户端提供网络功能,依赖于第三方方案,在较新版本中,可通过CNI容器网络插件标准接口,来接入任何遵循插件标准的第三方方案。 Service从一定程度上来说,在每个节点之上都工作有一个组件Kube-proxy,Kube-proxy将始终监视apiserver当中,有关service资源的变动状态。此过程是通过Kubernetes中固有的请求方法watch来实现的。一旦有service资源的内容发生变动,kube-proxy都将其转换为当前节点之上的能够实现service资源调度至特定Pod之上的规则。 service实现方式 在Kubernetes中service的实现方式有三种模型。 userspace 用户空间,可以理解为,用户的请求。 1.1之前包括1.1使用此模型。 用户的请求到达当前节点的内核空间的iptables规则(service规则),由service转发至本地监听的某个套接字上的用户空间的kube-proxy,kube-proxy在处理完再转发给service,最终代理至service相关联的各个Pod,实现调度。 iptables 1.10- 客户端IP请求时,直接请求serviceIP,IP为本地内核空间中的service规则所截取,并直接调度至相关Pod。service工作在内核空间,由iptables直接调度。 ipvs 1.11默认使用,如IPVS没有激活,默认降级为iptables 客户端请求到达内核空间后,直接由ipvs规则直接调度至Pod网络地址范围内的相关Pod资源。 使用清单创建service资源 SVC中的kubernetes service是集群中各Pod需要与Kubernetes集群apiserver联系时需要通过此svc地址联系。这个地址是集群内的apiserver服务地址。 service类型 ClusterIP 默认值,表示分配集群IP地址,仅用于集群内通信。自动分配地址,如需固定,需要指定相应地址,在创建后无法修改。当使用ClusterIP时,只有两个端口有用,port与targetPort NodePort 接入集群外部流量,默认分配的端口是30000~32767 LoadBalancer 表示将Kubernetes部署在虚拟机上,虚拟机是工作在云环境中,云环境支持lbaas(负载均衡及服务的一键调用)。 ExternaName 表示将集群外部服务引用到集群内部中来,在集群内部直接使用。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 spec: ports: # 将哪个端口与后端容器端口建立关联关系。 - port # service对外提供服务的端口 name 指明port的名称 targetPort # 容器的端口 nodePort # 只有类型为NodePort时,才有必要用节点端口,否则此选项是无用的。 protocol 协议,默认TCP seletcor 关联到哪些Pod资源上 app: redis run: redis clusterIP: # clusterIP可以动态分贝可以不配置 type: ClusterIP yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: v1 kind: Service metadata: name: redis namespace: default spec: selector: run: redis clusterIP: 10....

kubernetes概念 - kubernetes调度

Overview kube-scheduler 是kubernetes控制平面的核心组件,其默认行为是将 pod 分配给节点,同时平衡Pod与Node间的资源利用率。通俗来讲就是 kube-scheduler 在运行在控制平面,并将工作负载分配给 Kubernetes 集群。 本文将深入 Kubernetes 调度的使用,包含:”一般调度”,”亲和度“,“污点与容忍的调度驱逐”。最后会分析下 Scheduler Performance Tuning,即微调scheduler的参数来适应集群。 简单的调度 NodeName [1] 最简单的调度可以指定一个 NodeName 字段,使Pod可以运行在对应的节点上。如下列资源清单所示 yaml 1 2 3 4 5 6 7 8 9 apiVersion: v1 kind: Pod metadata: name: netpod spec: containers: - name: netbox image: cylonchau/netbox nodeName: node01 通过上面的资源清单Pod最终会在 node01上运行。这种情况下也会存在很多的弊端,如资源节点不足,未知的nodename都会影响到Pod的正常工作,通常情况下,这种方式是不推荐的。 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 $ kubectl describe pods netpod Name: netpod Namespace: default ....

kubernetes概念 - Kubernetes Pod控制器

Kubernetes资源清单 类别 名称 工作负载型资源(workload) 运行应用程序,对外提供服务:Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、Cronjob (ReplicationController在v1.11版本被废弃) 服务发现及负载均衡 service、Ingress 配置与存储 Volume、CSI(容器存储接口 特殊类型存储卷 ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感数据)、DownwardAPI(把外部环境中的信息输出给容器) 集群级资源 Namespace、Node、Role、ClusterRole、RoleBinding(角色绑定)、ClusterRoleBinding(集群角色绑定) 元数据型资源 HPA、PodTemplate(Pod模板,用于让控制器创建Pod时使用的模板)、LimitRange(用来定义硬件资源限制的) Kubernetes配置清单使用说明 在Kubernetes中创建资源时,除了命令式创建方式,还可以使用yaml格式的文件来创建符合我们预期期望的pod,这样的yaml文件我们一般称为资源清单。资源清单由很多属性或字段所组成。 以yawl格式输出pod的详细信息。 资源清单格式 yaml 1 kubectl get pod clients -o yaml Pod资源清单常用字段讲解 在创建资源时,apiserver仅接收JSON格式的资源定义。在使用kubectl run命令时,自动将给定内容转换成JSON格式。yaml格式提供配置清单,apiserver可自动将其转为JSON格式,(yaml可无损转为json),而后再提交。使用资源配置请清单可带来复用效果。 Pod资源配置清单由五个一级字段组成,通过kubectl create -f yamlfile就可以创建一个Pod apiVersion: 说明对应的对象属于Kubernetes的哪一个API群组名称和版本。给定apiVersion时由两部分组成group/version,group如果省略表示core(核心组)之意。使用kubectl api-versions获得当前系统所支持的apiserver版本。alpha 内测版、beta 公测版、stable 稳定版 kind: 资源类别,用来指明哪种资源用来初始化成资源对象时使用。 metadata: 元数据,内部嵌套很多2级、3级字段。主要提供以下几个字段。 name,在同一类别当中name必须是唯一的。 namespace 对应的对象属于哪个名称空间,name受限于namespace,不同的namespace中name可以重名。 lables key-value数据,对于key名称及value,最多为63个字符,value,可为空。填写时只能使用字母、数字、_、-、.,只能以字母或数字开头及结尾。 annotations 资源注解。与label不同的地方在于,它不能用于挑选资源对象,仅用于为对象提供“元数据”。对键值长度没有要求。在构建大型镜像时通常会用其标记对应的资源对象的元数据 spec: specification,定义接下来创建的资源对象应该满足的规范(期望的状态 disired state)。spec是用户定义的。不同的资源类型,其所需要嵌套的字段各不相同。如果某一字段属性标记为required表示为必选字段,剩余的都为可选字段,系统会赋予其默认值。如果某一字段标记为Cannot be updated,则表示为对象一旦创建后不能改变字段值。可使用kubectl explain pods.spec查看详情。 containers [required]object list name [string] 定义容器名称 image [string] 启动Pod内嵌容器时所使用的镜像。可是顶级、私有、第三方仓库镜像。 imagePulLPolicy [string] 镜像获取的策略,可选参数Always(总是从仓库下载,无论本地有无此镜像)、Never(从不下载,无论本地有无此镜像)、IfNotPresent(本地存在则使用,不存在则从仓库拉去镜像)。如果tag设置为latest,默认值则为Always,非latest标签,默认值都为IfNotPresent。...

kubernetes概念 - Kubenetes Deployment

Deployment当中借助于ReplicaSet进行更新的策略反映在Deployment的对象定义所需字段可使用kubectl explain deploy,Deployment属于extension群组。在1.10版本中它被移至到apps群组。他与ReplicaSet相比增加了几个字段。 stratgy 重要字段,定义更新策略,它支持两种策略 重建式更新 Recreate与滚动更新RollingUpdate,如果type为RollingUpdate,那么RollingUpdate的策略还可以使用RollingUpdate来定义,如果type为Recreate,那么RollingUpdate字段无效。 默认值为RollingUpdate stratgy.RollingUpdate控制RollingUpdate更新力度 maxSurge 对应的更新过程当中,最多能超出目标副本数几个。有两种取值方式,为直接指定数量和百分比。在使用百分比时,在计算数据时如果不足1会补位1个。 maxUnavailable 最多有几个副本不可用。 revisionHistoryLimit 滚动更新后,在历史当中最多保留几个历史版本,默认10。 在使用Deployment创建Pod时,Deployment会自动创建ReplicaSet,而且Deployment名称是使用Pod模板的hash值,此值是固定的。 Deployment在实现更新应用时,可以通过编辑配置文件来实现,使用kubectl apply -f更改每次变化。每次的变化通过吧变化同步至apiserver中,apiserver发现其状态与etcd不同,从而改变etcd值来实现修改其期望状态,来实现现有状态去逼近期望状态。 kubectl explain deploy yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: apps/v1 kind: Deployment metadata: name: app-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: deploy release: canary template: metadata: labels: app: deploy release: canary spec: containers: - name: my-deploy image: node01:5000/busybox:v1 ports: - name: http containerPort: 80 command: ["/bin/sh","-c","/bin/httpd -f -h /tmp"] 使用kubectl apply 声明式更新、创建资源对象。...