当运维遇上了...

当运维碰到docker时有什么想法?

  1. 使用Docker,不会再需要为了一个开发项目而准备多个测试和生产环境,从根本上解决了环境配置的难题;
  2. 缓解了使用虚拟机造成的资源占用多,操作冗余步骤多,启动慢的问题,而相对的Docker容器则是资源占用少,一次配置,启动时间短,运行体积小;
  3. 对于多实例多环境的配置,需要多次安装步骤,而使用Docker则是写一次Dockerfile即可一直使用,达到configure as a code
  4. 环境隔离更便捷,比如可以针对某个服务进行CPU,memory限制;
  5. ...更多的优点,我想当你使用上Docker以后,至少能减少一半重复劳动的时间

当运维碰到kubernetes时有什么想法?

  1. 如果某一台服务器突然宕机了,那么上面运行的服务是不是就不可以正常访问了? 如果使用kubernetes的deployment,就能保证我们的服务实例永远运行在我期望的状态;
  2. 不管传统的服务升级还是使用Docker容器发布的服务,在进行服务发布的时候,是不是确实存在某一个时刻服务有短暂的不可访问?503? 如果使用kubernetes的deployment来进行滚动升级,就能实现服务zero-downtime;
  3. 当服务的负载很高的时候,你是如何发现服务的负载大的,发现之后要扩容?还是增加服务实例?到完成扩容完整需要多久的时间? 那么使用kubernetes的HPA在服务负载较高时就可以自动伸缩实例的数量,不需要人为干预;
  4. 当需要服务区域高可用的时候会怎么部署服务呢?使用kubernetes解决了跨地区,跨机器之间的部署难题;
  5. 使用kuberenetes简化了使用不同类型存储介质的安装配置,其本身有广泛的volume支持;
  6. 内置负载均衡服务发现功能的service,减少代理的手动干预;
  7. 包含多种授权认证方式,以及认证插件来加强多节点之间通信的安全;
  8. 如果处在传统运维的公司有500台机器的话,你觉得需要多少运维或者devops人员? 如果处于在传统到容器过度之间的公司有500台机器的话,你觉得需要多少运维或者devops人员?如果公司上了kubernetes集群的话,运维或者devops人员又会是多少?

引入一个新的技术其实是很难的,但是当引入或者学习一个新的技术,一定要知道这个技术能为你带来哪些帮助

  1. 提高了多少工作效率;
  2. 解决了哪些技术难题;
  3. 服务的稳定性提高了多少;
  4. 服务的可用性提高了多少;
  5. 人力成本减少了多少;

我想如果这些自己的心里都有点概念的话,如果你觉得k8s能给你带来较多的好处,那么不要犹豫,直接盘它吧!

kubernetes不可不知的背景

Google 的 公有云 PaaS 产品 AppEngine 虽有很强的托管性(自动部署、运维),但灵活性较差(只支持固定语言和中间件);而 IaaS 产品 Compute Engine 虽然灵活性高(近似裸机的可配置性),但管理性很低(用户自行进行应用安装、维护、配置),为了解决这些问题,就是通过推出开源的容器编排管理系统 “Project 7”,利用开源社区迅速圈粉、打造生态、“shape people’s mind”,进行市场颠覆。同时,这一开源系统既提供了底层的容器、网络、存储等配置项,又提供了丰富的管理功能,从而打破了上述 PaaS 与 IaaS 产品在灵活性与托管性之间的矛盾。而在问世之后,“Project 7”也很快更名为“Kubernetes”。下面是kubernetes近些年的发展:

  • 2014 年 6 月 6 号,在这一个吉利的日子里,Kubernetes founder 之一 Joe Beta 在 GitHub 上合并了第一个 GitHub commit
  • 2015 年 7 月 21 日,Kubernetes 宣布发布正式 1.0 版本,达到生产可用
  • 2009 年问世的 Apache Mesos 项目也在 Docker 问世后通过与 Docker 的整合焕发了第二春,并定位为基于容器的数据中心操作系统(Data Center Operating System, 即 DCOS),在一定程度上与容器集群管理平台 Kubernetes 发生了定位上的重叠
  • Docker 公司也随后意识到容器自身只是一个轻薄的、底层的运行载体,很难大规模盈利并推动企业在复杂生产环境下使用;因此也开始研发自带的集群管理工具 Docker Swarm
  • Docker 公司推出的 Swarmkit,更是将其进军集群管理领域的雄心壮志昭示于天下
  • 2015 年 5 月,当 Kubernetes 宣布支持除了 Docker 以外的新的容器运行时 AppC 和 rkt
  • 2015 年 4 月 22 日,Kubernetes 官方博客专门报道了 Mesosphere 将 Kubernetes 集成进 DCOS 的消息
  • 2016 年西雅图 KubeCon 的多个主题演讲中直白地宣示着 Kubernetes 的领导者地位、到 Kubernetes 社区放大对 container runtime、network plugin 等抽象接口的投入
  • 2016 年 Q2-Q3: 以 Mirantis 为首的 OpenStack 厂商积极推动与 Kubernetes 的整合,避免站在 Kubernetes 的对立面,成为被 Kubernetes 推翻的“老一代技术”。
  • 2016 年 11 月,CNCF 与 Linux Foundation 联手,正式推出 Kubernetes 认证服务,进一步推动 Kubernetes 的商业化落地和普及。
  • 2016 年 11 月,在西雅图召开的 KubeCon 会议上,包括 Pearson、Box 等数十家 Kubernetes 终端用户向世人展示了 Kubernetes 在其生产环境中的成功应用。
  • 2016 年 12 月,伴随着 Kubernetes 1.5 的发布,Windows Server 和 Windows 容器可以正式支持 Kubernetes,微软生态完美融入。
  • 2017 年 2 月,Kubernetes 官方微博报道了中国京东用 Kubernetes 替代了 OpenStack 中的大量服务和组件,实现全容器化私有云和公有云的建设,中国的 Kubernetes 用户案例首次登上国际舞台。
  • 2017 年 6 月,在北京召开的 LinuxCon 上,中国公司报道了 Kubernetes 在中国金融、电力、互联网行业的成功案例,标志着 Kubernetes 的终端用户群体走向国际化。
  • 2 岁生日之际,Kubernetes 的用户涵盖了诸如金融(摩根斯坦利、高盛)、互联网(eBay、Box、GitHub)、传媒(Pearson、New York Times) 、通信(三星、华为)等行业的龙头企业。
  • 从 2015 年 7 月到 2017 年 7 月两年时间,Kubernetes 的主要代码仓库(github.com/kubernetes/kubernetes)从 1.0 版本时的 10000+ commits 变成了如今的近 50000+ commits,增长近五倍
  • 发展至今,Kubernetes 已经从一个单体的庞大代码库(github.com/kubernetes/kubernetes)向一个生态型多个代码库演进;除了主体代码库之外,还有约 40 个其他的插件代码库和超过 20 的孵化项目
  • 截止今日,Kubernetes 生态社区总共有 2505 个开发者,来自于 789 个参与公司
  • 有意思的是,“大象现象”同样存在于社区贡献者中,前 10 的贡献者贡献了超过 26% 的代码。
  • Kubernetes 的主要代码仓库已经获得了近 25000 个 GitHub Stars,遥遥领先于早期的竞争者(Swarm 和 Mesos 均不到 5000 颗星)。
  • CNCF 在全球召开了超过 200 场线下 meetups,仅在中国就有过十场。
  • Kubernetes 的 GitHub 活跃度已经超过了 99.99% 的项目!
  • ...

在k8s的不断发展中,我们也在不断的学习和进步,k8s功能的健全更需要我们一起实践探索,准备好了吗?玩起来...

原文地址:https://blog.51cto.com/bkmaster/2473623

时间: 2024-10-14 08:25:36

当运维遇上了...的相关文章

三个技巧助你在运维职业上获得成功

使DevOps和传统IT工作者恰如其分地配合工作,通常是费力不讨好的事. 终端用户希望没有中断的完美体验.为了达到这一目的,终端用户不需要知道运维做了什么工作.正如IT运维和DevOps专家所知道的,做正确的事并不难,但最难的是如何一直做正确的事. 不断重新调整工作优先级,同时保持系统正常运行,并不断按需修改生产环境,对运维来说是压力很大的工作. 环境都是不同的,不存在一个普适的答案.一个成功的运维职业生涯要求具有能在十万火急之时做出灵活而优越决策的能力.这当然是非常难以达到的,但有一些方法可以

Ansible自动化运维工具-上

[Ansible特点] 1)Ansible与saltstack均是基于Python语言开发的 2)安装使用简单,基于不同插件和模块实现各种软件,平台,版本的管理以及支持虚拟容器多层级的部署 3)不需要安装客户端,ansible基于SSH远程管理,不需要为配置工作添加额外的支持: PS:很多认为Ansible工具执行效率慢,其原因是SSH服务慢,我们可以选择优化SSH连接速度以及Ansible加速模块 [Ansible自动化管理工具特点] #轻量级,更新时,需要在操作机上进行一次更新即可 #采用S

第十章、日常运维(上)

10.1 使用w查看系统负载 10.2 vmstat命令 10.3 top命令 10.4 sar命令 10.5 nload命令 10.6 监控io性能 10.7 free命令 10.8 ps命令 10.9 查看网络状态 10.10 linux下抓包 10.11 Linux网络相关 10.11扩展 10.12课堂笔记 10.1 使用w查看系统负载 监控系统状态 w     #查看系统负载 第一行    当前系统时间    启动多长时间   登录几个用户    系统负载(一分钟系统负载数,五分钟系统

运维经理的翻身经

你能想象一个拥有数千名员工,且大部分都使用IT设备的集团公司,它的IT运维有多复杂吗?让我们来看看小A的故事. 小A是这样一家公司的IT运维经理,负责全公司分散在国内几大重点城市的数千台桌面终端.网络.服务器.机房,以及应用软件等的日常维护和IT资产管理.工作要求定期提供运维报告,保障最终用户的满意度达到SLA,为业务发展提供高效稳定IT支持. 小A的团队共有10名工程师,北京总部5人,上海3人,广州.成都各1人,平均每人负责超过200名员工的IT请求. 这样的人员配备虽不能说过少,但每个人的工

运维小哥之年终总结 [2019]

光阴荏苒,转眼又到了2019的末梢了.从混迹社会开始,经历每一个小阶段后,我都会来次三省五申,就像高中那会儿,每次月考后,总要对自己进行查缺补漏,充备再战,那样才有机会做到尽善尽美.此刻,也是如此,于是乎耗时数日将往昔尘事进行一番贯穿性的总结.将心中"蓄谋已久"的情绪和思想来一次无约束的释放! 职业生涯描述 先按时间节点来回顾下职业生涯. 2017年6月,在结束完学校的一切事物后,我背着个灰黑色的双肩包,拖着个银白色的行李箱,兴冲冲的来到了深圳.在交通途中,映入眼帘的是那川流不息的人群

Linux运维目前形势及未来展望

随着企业服务器数量越来越多,当到达几百台,上千台服务器之后,服务器日常管理也逐渐繁杂,每天如果通过人工去频繁的更新或者部署及管理这些服务器,势必会浪费大量的时间,而且有可能人为的操作也会造成某些疏忽而遗漏.那我们来看一下传统的运维以及今后运维的发展方向. 1.1     传统运维方式简介 传统的IT运维仍然是等到IT故障出现后再由运维人员采取相应的补救措施.这种被动.孤立.半自动式的IT运维管理模式经常让IT部门疲惫不堪,主要表现在以下三个方面: 1)   运维人员被动.效率低 在IT运维过程中

【运维者说】程序员玩跨界,错在运维人员

在很多交流场合,我们或多或少能听到有小伙伴抱怨运维岗位工作没有得到老板或者公司同事的认可,这怪谁呢?私以为只能怪运维岗位的各位同行,为什么这么讲呢?我这个攒了很久的大招,今天终于可以释放出来了. 恰逢看到田逸老师写的博客<程序员,请不要抢系统管理员的饭碗>以及文章下面各位同仁的评论内容,很多小伙伴基本上是从一个系统管理员的角度出发说出了安全问题的原因是程序员不应该这么做而这么做了,那程序员应该怎么做,他们知道吗?从这篇博客中描述的安全问题出发,田逸老师作为系统管理人员排查问题的思路非常清晰,对

最简单也最难:运维监控的最后1公里

谈运维我们不得不提监控,监控是运维的起点,也是难点.随着IT架构逐渐复杂化,从前端到IT底层,中间涉及浏览器.网络.服务器.操作系统.中间件.应用.数据库等,每个环节厂商不尽相同.当出现异常需要定位哪个环节出了问题的时候,排查就耗时耗力,若使用优云监控产品,以上难题不再是问题.优云全栈运维监控覆盖了所有环节的监控,真正做到监控无盲区,运维无隐患. 运维最后一公里是指高度可视化.优云除了提升监控能力还注重可视化,深知可视化是运维的亮点更是本质,为了让每个环节监控的数据更好的展现出来,优云拥有一批在

如何做好日常运维的安全工作

一.主动与被动发现漏洞 这里的主动是指安全工程师主动去做的事情,而被动并不是被动挨打,而是积极去获取信息,积极防御. 因为攻防之间信息不对称,很多攻击.利用方式及漏洞安全工程师不一定能第一时间获取到信息 就导致了服务器被黑,出现被上传webshell无外乎这集中情况: 使用开源程序出现高危漏洞被攻击者上传webshell,服务器配置错误导致攻击者利用运维缺陷上传webshell 程序员编写代码存在诸如sql注入.文件包含,命令执行问题被攻击者发现并利用导致被上传webshel 那是不是说作为防御