k8s专题[7.harbor从1.7.5升级到1.9.0]

升级步骤

前文:harbor1.9新功能众多,包括tag 保留和配额、可与 CI/CD 工具集成的 Webhook 通知、数据复制、Syslog 集成以及 CVE 例外策略等安全功能。harbor在1.8版本改变较大,因此需要分两步进行升级,升级到v1.8.0,再升级到v1.9.0。

准备工作:
1.下载harbor1.8.0和1.9.0版本的离线安装包

wget https://storage.googleapis.com/harbor-releases/release-1.8.0/harbor-offline-installer-v1.8.0.tgz

wget https://storage.googleapis.com/harbor-releases/release-1.9.0/harbor-offline-installer-v1.9.0.tgz

2.创建文件备份的目录

mkdir /data_backup1

mkdir /data_backup2

3.从docker hub拉取镜像

docker pull goharbor/harbor-migrator:v1.8.0

docker pull goharbor/harbor-migrator:v1.9.0

一、harbor1.7.5升级到1.8.0
1.关闭harbor

cd /usr/local/harbor

docker-compose down

2.数据备份

k8s专题[6.harbor私有仓库部署]

1.私有仓库版本

镜像仓库版本:

2.部署步骤

  • 内网组件资源要事先准备好

2.1.安装docker 服务

yum -y install http://192.168.3.146/docker-ce-cli-18.09.0-3.el7.x86_64.rpm http://192.168.3.146/docker-ce-18.09.3-3.el7.x86_64.rpm http://192.168.3.146/containerd.io-1.2.4-3.1.el7.x86_64.rpm

2.2.安装docker-docker-compose

wget http://192.168.3.146/docker-compose

mv docker-compose /usr/local/bin/docker-compose && chmod 755 /usr/local/bin/docker-compose

2.3.部署harbor

cd /usr/local/src && wget http://192.168.3.146/harbor-offline-installer-v1.7.5.tgz && tar -zxvf harbor-offline-installer-v1.7.5.tgz && mv harbor /usr/local/

修改harbor 配置文件 /usr/local/harbor/harbor.cfg,一般修改hostname为harbor的访问域名,ui_url_protocol为访问协议,设置成http,harbor_admin_password 设置harbor的admin账号默认密码,其他邮箱,认证模式可以部署完系统之后在系统配置页面修改。

执行安装命令:cd /usr/local/harbor && sh install.sh –with-clair

harbor启动命令:docker-compose -f docker-compose.clair.yml -f docker-compose.yml start

2.4.配置复制管理(记得做主从复制harbor的机器仓库的域名都要指向主harbor那一台,要不做镜像复制同步就有问题)

3.总结

  • 记得做主从复制harbor的机器仓库的域名都要指向主harbor那一台,要不做镜像复制同步就有问题

k8s专题[5.k8s高可用集群部署]

1.高可用集群概述

部署k8s的高可用集群,要做到无单电,主要是依靠负载均衡和k8s集群自身的高可用性。对于k8s的api,它本身是无状态的,自身不具备高可用,但是如果要它提供高可用的服务,做到其他节点和组件能无时无刻都可以访问它,需要在k8s api前面加一层tcp负载均衡器。一般k8s集群至少三个master节点,所以tcp转发层需要对这三台k8s api节点做负载均衡。这里有人可能问了,为什么需要tcp负载均衡,不做http负载均衡?原因就是k8s api的通信是https加密的,负载均衡器做https解析会比较麻烦,而且做tcp负载均衡效率也会高一些,也会比较方便,高版本的nginx就直接支持tcp转发。还有就是这三台master节点的服务器怎么放呢?这个要看个人的资源环境,比如你只是单机房的,那只能把master节点部署在一个机房里面了,然后三台服务器之间加个vip,使用keepalived做vip漂移,达到k8s api的高可用,如果你是同城三机房的,可以在每个机房部署一个master节点,然后每个机房部署一个高可用的负载均衡器,负载均衡器把请求转发到三个机房的k8s api上面去。然后对于etcd数据库,他本身自带高可用功能,部署三个以上节点的节点就好了,对于kube-scheduler组件,它们内部会自动选择一个leader节点,默认kubeadm安装情况下–leader-elect参数已经设置为true,保证master集群中只有一个kube-scheduler处于活跃状态,对于kube-controller-manager和kube-scheduler也是类似,默认kubeadm安装情况下–leader-elect参数已经设置为true,保证master集群中只有一个kube-controller-manager处于活跃状态。对于k8s核心组件的功能,下面再说明一下:

kube-apiserver:集群核心,集群API接口、集群各个组件通信的中枢;集群安全控制。

etcd:集群的数据中心,用于存放集群的配置以及状态信息,非常重要,如果数据丢失那么集群将无法恢复;因此高可用集群部署首先就是etcd是高可用集群;

kube-scheduler:集群Pod的调度中心;默认kubeadm安装情况下–leader-elect参数已经设置为true,保证master集群中只有一个kube-scheduler处于活跃状态;

kube-controller-manager:集群状态管理器,当集群状态与期望不同时,kcm会努力让集群恢复期望状态,比如:当一个pod死掉,kcm会努力新建一个pod来恢复对应replicas set期望的状态;默认kubeadm安装情况下–leader-elect参数已经设置为true,保证master集群中只有一个kube-controller-manager处于活跃状态;

kubelet:kubernetes node agent,负责与node上的docker engine打交道;

kube-proxy:每个node上一个,负责service vip到endpoint pod的流量转发,当前主要通过设置iptables规则实现。

2.k8s高可用架构图

这里单机房和多机房的区别就在于单机房整个机房就一个vip,多机房就是每个机房都有一个vip,每个机房都有一个api访问入口。
Kubernetes 高可用架构图

k8s专题[4.k8s资源对象]

一、API对象资源

API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能,引入一项新技术,一定会新引入对应的API对象,支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。

每个API对象都有3大类属性:元数据metadata、规范spec和状态status。元数据是用来标识API对象的,每个对象都至少有3个元数据:namespace,name和uid;除此以外还有各种各样的标签labels用来标识和匹配不同的对象,例如用户可以用标签env来标识区分不同的服务部署环境,分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态(Desired State),例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3;status描述了系统实际当前达到的状态(Status),例如系统当前实际的Pod副本数为2;那么复本控制器当前的程序逻辑就是自动启动新的Pod,争取达到副本数为3。

K8s中所有的配置都是通过API对象的spec去设置的,也就是用户通过配置系统的理想状态来改变系统,这是k8s重要设计理念之一,即所有的操作都是声明式(Declarative)的而不是命令式(Imperative)的。声明式操作在分布式系统中的好处是稳定,不怕丢操作或运行多次,例如设置副本数为3的操作运行多次也还是一个结果,而给副本数加1的操作就不是声明式的,运行多次结果就错了。

1.Pod

K8s有很多技术概念,同时对应很多API对象,最重要的也是最基础的是微服务Pod。Pod是在K8s集群中运行部署应用或服务的最小单元,它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库,一个Nginx容器用来发布软件,另一个容器专门用来从源仓库做同步,这两个容器的镜像不太可能是一个团队开发的,但是他们一块儿工作才能提供一个微服务;这种情况下,不同的团队各自开发构建自己的容器镜像,在部署的时候组合成一个微服务对外提供服务。

Pod是K8s集群中所有业务类型的基础,可以看作运行在K8s集群中的小机器人,不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型(long-running)、批处理型(batch)、节点后台支撑型(node-daemon)和有状态应用型(stateful application);分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet,本文后面会一一介绍。

2.复制控制器(Replication Controller,RC)

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个;少于指定数目,RC就会启动运行新的Pod副本;多于指定数目,RC就会杀死多余的Pod副本。即使在指定数目为1的情况下,通过RC运行Pod也比直接运行Pod更明智,因为RC也可以发挥它高可用的能力,保证永远有1个Pod在运行。RC是K8s较早期的技术概念,只适用于长期伺服型的业务类型,比如控制小机器人提供高可用的Web服务。

k8s专题[3.k8s基础组件]

1.核心组件

1.1 etcd 保存了整个集群的状态,etcd是Kubernetes提供默认的存储系统,保存所有集群数据,使用时需要为etcd数据提供备份计划

1.2 kube-apiserver 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制

1.3 kube-controller-manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等,kube-controller-manager运行管理控制器,它们是集群中处理常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成单个二进制文件,并在单个进程中运行.这些控制器包括:

  • 节点(Node)控制器
  • 副本(Replication)控制器:负责维护系统中每个副本中的pod
  • 端点(Endpoints)控制器:填充Endpoints对象(即连接Services&Pods)
  • Service Account和Token控制器:为新的Namespace 创建默认帐户访问API Token

1.4 kube-scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上

1.5 kubelet 负责维持容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理

1.6 Container runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI),默认的容器运行时为 Docker.

1.7 kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡.

1.8 docker服务,用于运行容器.

k8s专题[2.k8s设计原则]

1.API设计原则

对于云计算系统,系统API实际上处于系统设计的统领地位。Kubernetes集群系统每支持一项新功能,引入一项新技术,一定会新引入对应的API对象,支持对该功能的管理操作。理解掌握的API,就好比抓住了K8s系统的牛鼻子。Kubernetes系统API的设计有以下几条原则:

  • 所有API应该是声明式的。声明式的操作,相对于命令式操作,对于重复操作的效果是稳定的,这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外,声明式操作更容易被用户使用,可以使系统向用户隐藏实现的细节,同时也保留了系统未来持续优化的可能性。此外,声明式的API还隐含了所有的API对象都是名词性质的,例如Service、Volume这些API都是名词,这些名词描述了用户所期望得到的一个目标对象。
  • API对象是彼此互补而且可组合的。这实际上鼓励API对象尽量实现面向对象设计时的要求,即“高内聚,松耦合”,对业务相关的概念有一个合适的分解,提高分解出来的对象的可重用性。
  • 高层API以操作意图为基础设计。如何能够设计好API,跟如何能用面向对象的方法设计好应用系统有相通的地方,高层设计一定是从业务出发,而不是过早的从技术实现出发。因此,针对Kubernetes的高层API设计,一定是以K8s的业务为基础出发,也就是以系统调度管理容器的操作意图为基础设计。
  • 低层API根据高层API的控制需要设计。设计实现低层API的目的,是为了被高层API使用,考虑减少冗余、提高重用性的目的,低层API的设计也要以需求为基础,要尽量抵抗受技术实现影响的诱惑。
  • 尽量避免简单封装,不要有在外部API无法显式知道的内部隐藏的机制。简单的封装,实际没有提供新的功能,反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式,例如StatefulSet和ReplicaSet,本来就是两种Pod集合,那么Kubernetes就用不同API对象来定义它们,而不会说只用同一个ReplicaSet,内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
  • API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑,要保证整个系统随着系统规模的扩大,性能不会迅速变慢到无法使用,那么最低的限定就是API的操作复杂度不能超过O(N),N是对象的数量,否则系统就不具备水平伸缩性了。
  • API对象状态不能依赖于网络连接状态。由于众所周知,在分布式环境下,网络连接断开是经常发生的事情,因此要保证API对象状态能应对网络的不稳定,API对象的状态就不能依赖于网络连接状态。
    尽量避免让操作机制依赖于全局状态,因为在分布式系统中要保证全局状态的同步是非常困难的。

k8s专题[1.k8s基础概念]

1.概念

Kubernetes是一个容器编排系统,也就是容器集群管理系统,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes 最初源于谷歌内部的 Borg,提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理 / 虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

2.特点

  • 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)

  • 可扩展: 模块化, 插件化, 可挂载, 可组合

  • 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展

3.Kubernetes 架构

k8s集群更新证书

(版权声明:本文转载博客园「aguncn」的文章。原文链接)

1.问题起源

kubeadm 是 kubernetes 提供的一个初始化集群的工具,使用起来非常方便。但是它创建的apiserver、controller-manager等证书默认只有一年的有效期,同时kubelet 证书也只有一年有效期,一年之后 kubernetes 将停止服务。
官方推荐一年之内至少用 kubeadm upgrade 更新一次 kubernetes 系统,更新时也会自动更新证书。不过,在产线环境或者无法连接外网的环境频繁更新 kubernetes 不太现实。我们可以在过期之前或之后,使用kubeadm alpha phase里的certs和kubeconfig命令,同时配合kubelet证书自动轮换机制来解决这个问题。

2.k8s里面的证书详解

  • Kubernetes 集群根证书

/etc/kubernetes/pki/ca.crt

/etc/kubernetes/pki/ca.key

  • 由此根证书签发的证书有:

1.kube-apiserver 组件持有的服务端证书

/etc/kubernetes/pki/apiserver.crt

/etc/kubernetes/pki/apiserver.key

2.kubelet 组件持有的客户端证书,kubelet 上一般不会明确指定服务端证书, 而是只指定 ca 根证书, 让 kubelet 根据本地主机信息自动生成服务端证书并保存到配置的cert-dir文件夹中。

/etc/kubernetes/pki/apiserver-kubelet-client.crt

/etc/kubernetes/pki/apiserver-kubelet-client.key

  • 汇聚层(aggregator)证书

:D 一言句子获取中...