OpenStack简介OpenStack是一个开源的云计算管理平台项目由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单，可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（Infrastructure as a Service，IaaS）的解决方案，每个服务提供API以进行集成。 下图展示了OpenStack服务之间的关系： 要设计、部署和配置OpenStack、管理员必须了解逻辑体系结构。如上图所示，OpenStack由几个独立的部分组成，成为OpenStack服务。所有服务都是通过身份服务进行身份验证。各个服务通过公共API相互交互，除非需要特权管理员命令。 服务介绍 服务 项目名称 方法描述 Dashboard Horizon 提供了一个基于web的自服务门户，与OpenStack底层服务交互，诸如启动一个实例，分配IP地址以及配置访问控制 Compute Nova 在OpenStack环境中计算实例的生命周期管理。按需响应包括生成、调度、回收虚拟机等操 ...
keepalived介绍 keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点状态,后来又加入了可以实现高可用的VRRP功能.此,keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx,Haproxy,MySQL等)的高可用解决方案软件。 VRRP（Virtual Router Redundancy Protocol）虚拟路由器冗余协议，是一种容错的主备模式的协议，保证当主机的下一跳路由出现故障时，由另一台路由器来代替出现故障的路由器进行工作，通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。 Keepalived软件主要是通过VRRP协议实现高可用功能，在安装keepalived的服务器主机上会在配置文件中设置一个虚拟IP，当该keepalived节点为主节点且正常运行时，设置的虚拟Ip就会在该节点生效且绑定在该主机的网卡上，而其他备用主机设置的虚拟IP就不会生效。当测到主keepalived节点出现故障时，备用keepalived节点检会进行抢占提供服务，抢占成功的keepa ...
Linux运维
未读什么是分支 在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。（分支底层其实也是指针的引用） git分支操作流程 分支的好处同时并行推进多个功能开发，提高开发效率。各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。 Git分支的操作 命令名称 作用 git branch 分支名 创建分支 git branch -v 查看分支 git branch -d name 删除分支 git branch -b name 创建分支并切换到这个分支 git checkout 分支名 切换分支 git merge 分支名 把指定的分支合并到当前分支上 查看当前分支1234[root@boysec.cn ~/git_data]$git branch * master[root@boysec.cn ~/git_data]$ ...
Linux运维
未读Git是什么 Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。 Git是目前世界上最先进的分布式版本控制系统。 工作原理 / 流程： Workspace：工作区Index / Stage：暂存区Repository：仓库区（或本地仓库）Remote：远程仓库 SVN与Git的最主要的区别SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就纳闷了。 Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要 ...
StatefulSetStatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现 有序收缩，有序删除（即从N-1到0） 从上面的应用场景可以发现，StatefulSet由以下几个部分组成： 用于定义网络标志（DNS domain）的Headless Service 用于创建PersistentVolumes的volumeClaimTemplates 定义具体应用的StatefulSet StatefulSet中每个Pod的DNS格式 ...
DaemonSet简介DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。使用 DaemonSet 的一些典型用法： 在每个节点上运行集群守护进程，例如在每个 Node 上运行 glusterd 、 ceph 在每个节点上运行日志收集守护进程，例如 fluentd 、 logstash 在每个节点上运行监控守护进程，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond 一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。 DaemonSet模板查看DaemonSet必要字段 DaemonSet的描述文件和Deployment非常相似，只 ...
HPA简介官方文档 | Kubernetes HPA（Horizontal Pod Autoscaler）的实现是一个控制循环，由controller manager的–horizontal-pod-autoscaler-sync-period参数指定周期（默认值为15秒）。每个周期内，controller manager根据每个HorizontalPodAutoscaler定义中指定的指标查询资源利用率。controller manager可以从resource metrics API（pod 资源指标）和custom metrics API（自定义指标）获取指标。 对于每个pod的资源指标（如CPU），控制器从资源指标API中获取每一个 HorizontalPodAutoscaler指定的pod的指标，然后，如果设置了目标使用率，控制器获取每个pod中的容器资源使用情况，并计算资源使用率。如果使用原始值，将直接使用原始数据（不再计算百分比）。然后，控制器根据平均的资源使用率或原始值计算出缩放的比例，进而计算出目标副本数。需要注意的是，如果pod某些容器不支持资源采集，那么控制器将 ...
Deployment更新机制 Deployment控制器支持两种更新策略：滚动更新（rolling update）和重新创建（recreate），默认为滚动更新。 滚动升级是默认的更新策略，它在删除一部分旧版本Pod资源的同时，补充创建一部分新版本的Pod对象进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形，例如新旧版本兼容同一个数据库方案等。不过，更新操作期间，不同客户端得到的响应内容可能会来自不同版本的应用。 Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时，新控制器的Pod对象数量不断增加，直到旧控制器不再拥有Pod对象，而新控制器的副本数量变得完全符合期望值为止，如图所示。 滚动更新时，应用升级期间还要确保可用的Pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求，变动的方式和Pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和 ...
简介本文介绍了如何通过 Ansible Playbook 的 roles 功能，自动化部署 Kubernetes 集群。本文将重点讲解如何使用离线方式批量安装 Kubernetes 二进制文件及必要的依赖组件，尽可能减少外部网络访问。考虑到 Kubernetes 集群的正常运行，某些插件（如 CoreDNS、Ingress、Dashboard 等）需要从外部镜像仓库拉取相应镜像，因此在完全离线的环境下，可能需要进行额外的处理。此外，本教程还将介绍如何选择适当的 Kubernetes 和 etcd 版本，并为 flannel 网络插件提供了非容器化版本的安装方式。 Kubernetes 版本选择 在本文的部署过程中，支持多个版本的 Kubernetes，用户可以根据需求选择合适的版本。支持的 Kubernetes 版本从 v1.24.x 到 v1.32.x，同时也会兼容不同版本的 etcd。 软件环境准备 操作系统：是基于 CentOS 操作系统编写的。 etcd：https://github.com/etcd-io/etcd/releases 证书签发工具CFSSL：https:/ ...
Deployment介绍官方介绍 一个 Deployment 为 Pods 和 ReplicaSets提供声明式的更新能力 负责描述 Deployment 中的 目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。 而是通过管理ReplicaSet来间接管理pod，即：deployment管理ReplicaSet，ReplicaSet管理pod。所以Deployment比ReplicaSet的功能更强大。 一个Deployment产生三个资源： Deployment资源所有功能 ReplicaSet资源的所有功能 POD资源 Deployment控制RS，RS控制POD副本数 Kubernetes官方强烈建议避免直接使用ReplicaSet，而应该通过Deployment来创建RS和Pod。 Deployment资源清单详解12345678910111213141516 ...
为容器设置一个环境变量创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 env 或者 envFrom 字段来设置环境变量。 本示例中，将创建一个只包含单个容器的 Pod。Pod 的配置文件中设置环境变量的名称为 DEMO_GREETING， 其值为 "Hello from the environment"。下面是 Pod 的配置清单： 123456789101112131415apiVersion: v1kind: Podmetadata: name: envar-demo labels: purpose: demonstrate-envarsspec: # 指定规格信息 containers: # 指定要启动一个什么样的容器 - name: envar-demo-container image: gcr.io/google-samples/node-hello:1.0 env: # 设置环境变量 - name: DEMO_GREETING value: " ...
YAML 基础 它的基本语法规则如下： 大小写敏感 使用缩进表示层级关系 缩进时不允许使用Tab键，只允许使用空格。 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可 # 表示注释，从这个字符一直到行尾，都会被解析器忽略。 Pods基本原理Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 Pod （就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个） 容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器， 这些容器是相对紧密的耦合在一起的。 在非云环境中，在相同的物理机或虚拟机上运行的应用类似于 在同一逻辑主机上运行的云应用。 除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。 你也可以在集群中支持临时性容器 的情况下，为调试的目的注入临时性容器。 Pod 简单模版1234567891011121314151617181920apiVersion: v1 # ...
