博主昵称:跳楼梯企鹅
博主主页面链接:博主主页传送门
博主专栏页面连接:专栏传送门--网路安全技术
创作初心:本博客的初心为与技术朋侪们相互交换,每个人的技术都存在短板,博主也是一样,虚心讨教,希望各位技术友给予指导。
博主座右铭:发现光,追随光,成为光,散发光;
博主研究方向:渗透测试、机器学习 ;
博主寄语:感谢各位技术友的支持,您的支持就是我前进的动力 ;
一、浅谈云计算
1.概念
云计算(cloud computing)是分布式计算的一种,指的是通过网络“云”将巨大的数据计算处置惩罚程序分解成无数个小程序,然后,通过多部服务器构成的系统举行处置惩罚和分析这些小程序得到结果并返回给用户。云计算早期,简单地说,就是简单的分布式计算,办理任务分发,并举行计算结果的合并。因而,云计算又称为网格计算。通过这项技术,可以在很短的时间内(几秒钟)完成对数以万计的数据的处置惩罚,从而达到强大的网络服务。
2.为什么要用云计算
(1)云计算进步了速率和敏捷性
如果今天的贸易情况有一个基本的事实,那就是它正在以不停加快的速率发展。
每个企业都面临着压力,必须对不停变革的贸易情况作出更快的反应。不幸的是,传统的IT流程与今天的速率并不匹配。配置资源通常需要数周或数月时间,因此减慢了业务的反应速率。有了云计算,资源可以在几分钟内获得,这意味着企业可以更快地对新市场的发展做出反应。
(2)实现可持续创新
然而,在今天的贸易情况中,乐成需要的不但仅是速率。同样重要的是创新——即开发新产品、评估其潜在市场承认度,然后推出乐成产品、淘汰失败产品的能力。
在这方面,云计算也比传统的IT基础设施方法更适当。因为资源的可用性非常快,以是很容易很快地体验新产品。公司可以立即获得用户反馈,而不是等上几个月才让产品进入市场试验。
(3)有助于管理本钱
传统IT基础设施的另一个实际是,它的代价非常昂贵。显然,基础设施需要物理资源:服务器、存储和网络。但除此之外,运营这些资源还需要大量的开支:人员、设施和电力。
而且大多数IT组织在基础设施方面服从不高。采购很少,而且数量很少,因此资源本钱很高。操作过程通常不是主动化的,以是人工本钱也很高。
相比之下,大型云服务提供商则是批量购买。而且因为他们的经营规模非常之大,以是必须投资于过程主动化。而且,他们不可能雇佣或负担得起充足的员工来手动管理他们庞大的服务器群。
(4)支持应用程序弹性
应用程序正常运行时间一直很重要。但如今,可用性比以往任何时间都重要。这是因为越来越多的公司正在成为数字化企业,他们的客户和供应商通过基于IT的机制举行互动和参与。
向数字化的变革使应用程序的弹性变得至关重要。简单地说,应用程序需要保持可用性,即使面临基础设施故障。
大多数内置应用程序表现出较差的弹性。由于装备非常昂贵,大多数应用程序负担不起冗余,因此它们包罗SPOFs(单点故障)。当基础设施出现故障时,应用程序会停止运行,直到举行修复为止。
云计算极大地改变了弹性方程。首先,很容易获得额外的基础设施资源。因此,如果出现故障,在新的资源上重启应用程序是很简单的。
但应用程序的弹性不但仅是快速获得替换包。因为资源是随时可用的,而且组织只为他们使用的东西付费,以是制止SPOF应用程序设计和使用冗余资源是划算的。如果出现故障,应用程序将继续对仍在工作的资源举行操作,从而允许操作将问题作为后台任务处置惩罚。
参考资料链接
3.云计算服务
云部署模型
云情况主要分为三种范例,也称为云部署模型。企业可以选择在公共云、私有云或肴杂云上运行应用程序,具体取决于他们的要求。
公共云
公共云情况由外包云提供商所有,很多企业可以通过互联网以按使用付费的模式访问。这种部署模型为希望节省 IT 运营本钱的企业提供服务和基础设施,但负责创建和维护资源的是云提供商。
私有云
这种云部署模型是由单个企业拥有的定制基础架构。它提供了一个更加可控的情况,在该情况中,对 IT 资源的访问更加会集在企业内部。该模型可以在外部托管,也可以在内部举行管理。尽管私有云托管可能很昂贵,但对于大型企业来说,它可以提供更高级别的安全性和更多自主权来定制存储、网络和计算组件以满意其 IT 需求。
肴杂云
对于寻求私有云和公共云部署模型的好处的企业来说,肴杂云情况是一个不错的选择。通过联合这两种模型,肴杂云模型提供了更量身定制的 IT 办理方案,可以满意特定的业务需求。
二、云计算基础服务
云计算的三种主要服务模式——基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。
(1)基础设施即服务(IaaS)
这是最常见的云计算服务模型,因为它提供了捏造服务器、网络、操作系统和数据存储驱动器的基础架构。它实现了很多企业通过云寻求的灵活性、可靠性和可扩展性,并消除了办公室对硬件的需求。这使其成为寻求经济高效的 IT 办理方案以支持业务增长的中小型组织的理想选择。IaaS 是一项完全外包的按使用付费服务,可作为公共、私有或肴杂基础设施使用。
(2)平台即服务(PaaS)
这是云计算提供商部署基础设施和软件框架的地方,但企业可以开发和运行自己的应用程序。可以通过 PaaS 快速轻松地创建 Web 应用程序,而且该服务充足灵活和强大以支持它们。PaaS 办理方案具有可扩展性,非常适当多个开发人员在单个项目上工作的业务情况。对于需要利用现有数据源(例如 CRM 工具)的情况,它也很方便。
(3)软件即服务(SaaS)
这种云计算办理方案涉及通过互联网向通过订阅或按使用付费模式付费的各种企业部署软件。对于 CRM 和需要大量 Web 或移动访问的应用程序(例如移动贩卖管理软件)来说,它是一个有代价的工具。SaaS 从一个中央位置举行管理,因此企业不必担心自己维护它,是短期项目的理想选择。
三、云计算分层架构应用
1、应用层
应用层是以友好的用户界面为用户提供所需的各项应用软件和服务,应用层直接面向客户需求,向企业客户提供CRM、ERP、OA等企业应用。
2、中央层
中央层是承上启下的一层,它在基础设施层所提供资源的基础上为用户提供服务,包括了访问控制、资源管理、数据库和中央件等集群,同时可通过集成API为客户提供定制开发接口。
3、基础设施层
基础设施层是为中央层或者用户提供其所需的计算和存储等资源,并通过捏造化等技术奖资源池化,以实现资源的按需分配和快速部署。
四、云原生架构----Docker
1.Docker框架
Docker是客户端-服务器架构的应用,主要由以下部分构成:
- 服务端是一个名为dockerd保卫进程,用来监听REST API请求并管理Docker对象,比如镜像、容器、存储卷及网络等。
- 下令行客户端(CLI),也就是我们平常在控制台输入的docker下令行,通过调用REST API举行控制Docker daemon或者同其举行集成。
- 镜像仓库(Docker Registries),镜像仓库用来存储Docker镜像。
2.Docker对象
镜像一般是通过指令创建的只读文件,用来生成容器。一般一个镜像是基于别的一个镜像并添加一些额外的指令创建的,可以通过一个名为Dockerfile的文件来生成一个镜像,在Dockerfile中的每一行指令会生成一层(layer)。当Dockerfile有改动需要重新生成镜像时,只需要重新生成改变的那些层就可以,这样就可以使得镜像文件更加轻量、快速构建。
容器是通过镜像文件生成的运行实例。可以通过REST API或者docker client举行创建、启动、停止、移动或者删除一个容器。
用来管理和扩展多个容器,需要同docker swarm一起工作
3.Docker的安装部署
(1)配置初始化
- # cat /etc/sysconfig/network-scripts/ifcfg-ens33
- TYPE=Ethernet
- BOOTPROTO=static
- NAME=ens33
- DEVICE=ens33
- ONBOOT=yes
- IPADDR=192.168.xxx.xxx
- NETMASK=255.255.255.0
- GATEWAY=192.168.xxx.xxx
复制代码 (2)配置DNS
- [root@localhost yum.repos.d]# vim /etc/resolv.confnameserver 192.168.xxx.xxx
复制代码 (3)配置主机
- # hostnamectl --static set-hostname docker-90
复制代码 (4)挂载
- [root@localhost ~]# mkdir /iso
- [root@localhost ~]# mount /dev/sr0 /iso
- [root@localhost ~]# chmod +x /etc/rc.d/rc.local
- [root@localhost ~]# vi /etc/rc.d/rc.local
- ##挂载
- mount /dev/sr0 /iso
复制代码 (5)镜像源配置
- [root@localhost ~]# cd /etc/yum.repos.d/
- [root@localhost yum.repos.d]# rm -rf *.repo
- [root@localhost yum.repos.d]# vi base.repo
- vi内部内容如下:
- [root@localhost yum.repos.d]# cat base.repo
- [base]
- name=base
- baseurl=file:///iso
- enabled=1
- gpgcheck=0
- 继续输入命令
- [root@localhost yum.repos.d]# yum clean all
- [root@localhost yum.repos.d]# yum makecache
复制代码 (6)设置情况
- [root@localhost yum.repos.d]# iptables -F
- [root@localhost yum.repos.d]# iptables -t nat -F
- [root@localhost yum.repos.d]# systemctl stop firewalld
- [root@localhost yum.repos.d]# systemctl disable firewalld
- [root@localhost yum.repos.d]# systemctl stop NetworkManager
- [root@localhost yum.repos.d]# systemctl disable NetworkManager
- [root@localhost yum.repos.d]# systemctl stop postfix
- [root@localhost yum.repos.d]# systemctl disable postfix
复制代码 (7)修改内核
- [root@localhost yum.repos.d]# vim /boot/grub2/grub.cfg
- 将 第 100 行的
- rhgb quiet 去掉,改为 vga=817
- 修改目录路径
- [root@localhost yum.repos.d]# vim /etc/bashrc
- #第41行,修改
- ...... && PS1="[\u@\h \w]\\$ ,将 \W 改为 \w
复制代码 (8)导入key
- [root@docker ~]#rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
复制代码 (9)安装yum源
- [root@docker ~]#rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
- [root@docker ~]#yum clean all
- [root@docker ~]#yum makecache fast
复制代码 (10)部署docker-ce
- 清理环境
- [root@Docker1 ~]#systemctl stop docker
- [root@Docker1 ~]#yum remove docker-ce docker-ce-cli docker-selinux
- 配置网络
- root@Docker1 ~]#cd /etc/yum.repos.d/
- [root@Docker1 /etc/yum.repos.d]#mv elrepo.repo elrepo.repo.bak
- [root@Docker1 /etc/yum.repos.d]#vim aliyun.repo
- ###输入以下内容
- [base]
- name=base
- baseurl=https://mirrors.aliyun.com/centos/7/os/x86_64/
- enabled=1
- gpgcheck=0
- [extras]
- name=extras
- baseurl=https://mirrors.aliyun.com/centos/7/extras/x86_64/
- enabled=1
- gpgcheck=0
- [aliyun-os]
- name=aliyun-os
- baseurl=https://mirrors.aliyun.com/centos/7/os/x86_64/
- enabled=1
- gpgcheck=0
- [aliyun-epel]
- name=aliyun-epel
- baseurl=https://mirrors.aliyun.com/epel/7/x86_64/
- enabled=1
- gpgcheck=0
- [aliyun-extra]
- name=aliyun-extra
- baseurl=https://mirrors.aliyun.com/centos/7/extras/x86_64/
- enabled=1
- gpgcheck=0
- 安装最新版本docker-ce
- [root@Docker1 /etc/yum.repos.d]# yum install docker-ce docker-ce-cli containerd.io
复制代码 (11)测试docker 工具
- [root@Docker1 /etc/yum.repos.d]# docker -v
- Docker version 20.10.6, build 370c289
- 查看docker详情
- #docker info
复制代码 (12)配置加快器
- https://cr.console.aliyun.com/cn-guangzhou/instances/mirrors
- [root@Docker1 /etc/docker]# vim /etc/docker/daemon.json
- ## 输入以下内容
- {
- "registry-mirrors": ["https://xxxxxxxx.mirror.aliyuncs.com"] ##这里修改为自己的阿里云加速器地址
- }
- [root@Docker1 /etc/docker]# systemctl daemon-reload
- [root@Docker1 /etc/docker]# systemctl restart docker
复制代码 (13)启动
- [root@Docker1 /etc/yum.repos.d]# systemctl start docker
- docker开机自启动:# systemctl enable docker
- [root@Docker1 /etc/yum.repos.d]# systemctl status docker
复制代码 五、云原生架构----Kubernetes
1.Kubernetes系统架构解析
- K8S是谷歌开源的容器集群管理系统;他构建在容器之上,为容器化的应用提供资源调理,部署运行,服务发现,扩容缩容等一整套功能。
- 将容器宿主机构成集群,统一举行资源调理,主动管理容器生命周期,提供跨节点服务发现和负载平衡;更好的支持服务概念、分别、细分服务之间的界限,比如label,pod等概念的引入
- 轻量,迁徙方便,部署快捷,插件化,可扩展
2.controller控制器原明白析
Controller Manager主要提供了一个分发事件的能力,而不同的Controller只需要注册对应的Handler来等候接受和处置惩罚事件。
在Controller Manager的资助下, Controller的逻辑可以做的非常纯粹,只需要实现相应的EventHandler即可,以Deployment controller为例。
- List是短连接实现,用于获取该资源的所有Object
- Watch是长连接实现,用于监听在List中获取的资源的变换
- api-server检测到资源产生变更时,会主动关照到Controller manager(利用分块传输编码
3.list-watch机制解析
Kubernetes 是通过 List-Watch 的机制举行每个组件的协作,保持数据同步的,每个组件之间的设计实现了解耦。
用户是通过 kubectl 根据配置文件,向 APIServer 发送下令,在 Node 节点上面创建 Pod 和 Container。
APIServer 经过 API 调用,权限控制,调用资源和存储资源的过程,实际上还没有真正开始部署应用。这里需要 Controller Manager、Scheduler 和 kubelet 的帮助才能完成整个部署过程。
在 Kubernetes 中,所有部署的信息都会写到 etcd 中生存。实际上 etcd 在存储部署信息的时间,会发送 Create 事件给 APIServer,而 APIServer 会通过监听(Watch)etcd 发过来的事件。其他组件也会监听(Watch)APIServer 发出来的事件。
六、无服务应用架构设计
1.长处
无服务器架构的长处之一是企业机构不用管理运行应用的后端基础设施。例如开发人员不必担心容量规划问题,因为有人会为他们办理。云服务提供商提供主动化的无服务器架构,这种架构可以在须要时提供更多的资源或缩小规模,这就又为开发人员淘汰了一项待办任务。开发人员不必负责维护后端基础设施,包括配置和扩展等,可以将更多的时间用于其他更故意义的项目。
这种弹性为企业机构办理了容量规划等掌管服务器时所需要担心的问题。而且企业不负责后端基础设施,因此也不需要在服务器瓦解或堕落时举行修复。云服务提供商所提供的主动扩展和调试功能,资助无服务器架构成为一个值得投资的项目。
无服务器架构的另一个长处是本钱,可能是一个物有所值的选择。节省团队的时间就是节省资金,团队花在后端基础设施维护上的时间越少,企业淘汰的本钱就越多。此外,使用无服务器架构的企业不需要一个完备的团队来管理服务器,因此开发人员不必是服务器专家,这使企业机构的招聘条件变得更加宽松。
2.缺点
企业也应该考虑这种架构的一些缺点。
由于无服务器架构的性质,在上面运行的应用无法被监控。服务器不属于自己,企业机构无法完备地看到上面所运行的齐备,也就更加难以衡量一个应用的性能。同时,他们也无法轻易看到性能问题的发展趋势,或主动防备问题。比方说,因为不负责后端,企业机构无法深入研究调查日志。对于企业机构来说,转移这项责任在某些方面可能是件好事,但不好的方面是他们无法看到关键性能分析,也无法了解服务器上的情况毕竟如何。
无服务器架构的另一个潜在缺点是安全问题。由于受攻击面大于企业通常使用的内部服务器,无服务器应用可能碰面临更大的安全风险。同样,这也取决于云服务提供商和第三方服务所接纳的措施与企业安全能力的比力结果。如果企业机构认为自己的服务器安全性不如AWS Lambda,那么与云供应商合作更加明智。
资源限定也可能是无服务器架构的缺点之一。固然无服务器架构具有弹性,可以通过加快和减速来为应用分配资源,但它是有限定的。如果一家企业机构的应用大到凌驾这些限定,那么可能就不适当使用无服务器架构。
某些应用在设计上不适当成为无服务器应用,以是无服务器架构并非适当每一个用例。如果根据应用所使用的资源来订价,有些应用会不停消耗所获得的计算资源,使无服务器架构的本钱激增。此类应用会占用越来越多的资源,而企业机构必须为此买单。
完
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |