Browsed by
标签: k8s

kubectl 命令大全

kubectl 命令大全

閱讀本文約花費: 7 (分鐘)1.kubectl 命令补全 2.kubectl上下文和配置 3.创建对象 4.显示和查找资源 5.更新资源 6.修补资源 7.编辑资源 8.scale资源,设置副本数 9.删除资源 10.与运行中的pod交互 11.与节点和集群交互 12.资源类型 下表列出的是 kubernetes 中所有支持的类型和缩写的别名。 资源类型 缩写别名clusterscomponentstatuses csconfigmaps cmdaemonsets dsdeployments deployendpoints epevent evhorizontalpodautoscalers hpaingresses ingjobslimitranges limitsnamespaces nsnetworkpoliciesnodes nostatefulsetspersistentvolumeclaims pvcpersistentvolumes pvpods popodsecuritypolicies psppodtemplatesreplicasets rsreplicationcontrollers rcresourcequotas quotacronjobsecretsserviceaccount saservices svcstorageclassesthirdpart…

Read More Read More

Kubectl基本操作命令

Kubectl基本操作命令

閱讀本文約花費: 7 (分鐘)创建对象通过yaml文件创建: kubectl create -f xxx.yaml (不建议使用,无法更新,必须先delete) kubectl apply -f xxx.yaml (创建+更新,可以重复使用) 删除对象通过yaml文件删除: kubectl delete -f xxx.yaml 查看kube-system namespace下面的pod/svc/deployment 等等(-o wide 选项可以查看存在哪个对应的节点) kubectl get pod/svc/deployment -n kube-system 查看所有namespace下面的pod/svc/deployment等等kubectl get pod/svc/deployment –all-namcpaces 重启pod(无法删除对应的应用,因为存在deployment/rc之类的副本控制器,删除pod也会重新拉起来) kubectl get pod -n kube-system 查看pod描述:kubectl describe pod XXX -n kube-system 查看pod 日志 (如果pod有多个容器需要加-c 容器名)kubectl logs xxx -n kube-system 删除应用(先确定是由说明创建的,再删除对应的kind):kub…

Read More Read More

面向 Kubernetes 设计误区

面向 Kubernetes 设计误区

閱讀本文約花費: 23 (分鐘)K8s 设计模式 Kubernetes 是一个具有普遍意义的容器编排工具,它提供了一套基于容器构建分布式系统的基础依赖,其意义等同于 Linux 在操作系统中的地位,可以认为是分布式的操作系统。 自定义资源 K8s 提供了 Pod、Service、Volume 等一系列基础资源定义,为了更好提供扩展性,CRD 功能是在 1.7 版本被引入。用户可以根据自己的需求添加自定义的 Kubernetes 对象资源(CRD)。值得注意的是,这里用户自己添加的 Kubernetes 对象资源都是 native 的都是一等公民,和 Kubernetes 中自带的、原生的那些 Pod、Deployment 是同样的对象资源。在 Kubernetes 的 API Server 看来,它们都是存在于 etcd 中的一等资源。同时,自定义资源和原生内置的资源一样,都可以用 kubectl  来去创建、查看,也享有 RBAC、安全功能。用户可以开发自定义控制器来感知或者操作自定义资源的变化。 Operator 在自定义资源基础上,如何实现自定义资源创建或更新时的逻辑行为,K8s Operator 提供了相应的开发框架。Operator 通过扩展 Kubernetes 定义 Custom Controller,list/watch 对应的自定义资源,在对应资源发生变…

Read More Read More

带你了解负载均衡

带你了解负载均衡

閱讀本文約花費: 7 (分鐘)相信很多小伙伴的公司都是服务治理,自动化运维了吧,那么我们很多东西都变成我们自己去设置了,比如自己创建一个域名,绑定他的代理机器,它的web负载均衡这些东西。所以今天跟大家一起来看看负载均衡。 你怎么看负载均衡 负载均衡是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。 相信很多小伙伴,一听到负载均衡四个字,第一个想到就是我们所说的Nginx吧,因为这个是离我们开发比较近的一个组件了。 第二个呢?就是我们Springcloud的组件中自带了负载均衡(ribbon),这个也是离我们开发比较近的 第三个?就是其实我们k8s里面的服务也是能做负载均衡的,目前主流容器使用方式 第四个就是我们DNS之后的一个负载均衡了SLB(这个之前运费负责的多点) 为啥要负载均衡呢? 大家看下面的图,当我们访问一个网站的时候,如果突然的流量增加,就会导致我们的服务不可用(单点故障) image.png 一个没有负载均衡的 web 架构类似下面这样: image.png 所以为了解决单点问题我们需要负载均衡(也是我们高可用,高性能,高并发的基石) 有负载均衡的架构 image.png web架构 image.png 聊聊SLB image.png 相信很多公司都有用到吧。 负载均衡的组成 负载均衡实例 (Inst…

Read More Read More

K8S Service类型

K8S Service类型

閱讀本文約花費: 5 (分鐘)K8S Service类型∶ ● K8S 的服务 (Service)用于解决K8S 集群的网络负载分配1.服务通过标签检索出正在运行的Pod,维护着该服务的可用Endpoints集合(kubectl get ep )2.服务以短名字注册到集群DNS,配合namespace和svc后缀就可以进行常规DNS查询,得到该服务的唯一ClusterIP 3.如果是Headless类型的服务,K8S不分配ClusterIP,其DNS响应为一组Pod IP列表,或者一个CNAME指向外部域名4.服务的网络实现在TCP/IP四层,通过DNAT(nodePort)或 DNAT(ClusterIP,port)两条路径之一到Pod的targetPort5.targetPort通常是Pod内工作容器或sidecar(比如envoy代理)容器监听的端口号,需要跟pod定义保持一致 ● ClusterIP类型的服务 -集群内部互访集群内部任一 pod 可以经由 ClusterlP∶port发起访问的K8S服务类型 K8S服务IP即 ClusterIP,仅存在于转发规则里,不配置到任何内核网络接口- 在 ClusterIP类型 Service的定义中∶1.无需显式指定IP,K8S将自动分配一个独占的ClusterIP,定义type为ClusterIP,也可以省略2.需要显式指定一组…

Read More Read More

UCloud优刻得容器Cube入选2020年度十大云原生创新技术方案

UCloud优刻得容器Cube入选2020年度十大云原生创新技术方案

閱讀本文約花費: 4 (分鐘)近日,由极客邦科技、InfoQ主办的首个年度榜单“2020中国技术力量年度榜单评选”结果揭晓,UCloud优刻得 Serverless容器实例Cube成功入选“2020年度十大云原生创新技术方案”。 顶尖专家阵容 优质项目交锋 UCloud云原生实力获得认可 此次极客邦科技、InfoQ主办的“2020中国技术力量年度榜单评选”,历经数月打磨,共有300+参评项目,100+入围项目,10000+开发者公开票选,20+顶尖专家评审,10+主编团打分。“2020 年度十大云原生创新技术方案”作为评选出的四大榜单之一,聚焦IT圈最炙手可热的“云原生”领域及优质技术方案,从研发实力、技术创新性、落地案例、市场潜力几方面综合评估,最终筛选出UCloud优刻得、华为云、腾讯云等10家入选方案。 轻量级Cube 秒级启动、最短1天完成部署 伴随云计算2.0时代的到来,越来越多企业开始拥抱云原生,容器作为云原生最基础的技术,在短时间也实现了快速普及,据权威机构的调查数据显示,2019年已有43.9%的用户采用了容器技术,另外有40.8%的用户计划采用容器技术。 UCloud作为云计算领域的核心玩家,持续关注云原生发展和用户需要,进行了多项技术、产品研发。在Kubernetes作为容器编排的事实标准在企业服务中被大量采用后,UCloud也于2018年推出了基于Kubern…

Read More Read More

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

閱讀本文約花費: 11 (分鐘)简介: 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,并正式揭晓了“开源杰出贡献人物”、“开源新锐项目”和“云原生行业落地典范”三大重量级奖项。在此前的入围赛中,仅“开源新锐项目”单项,阿里云原生就入围了10多个开源项目,在创新能力、社区成就和用户反馈等多项指标中一骑绝尘,占据了参评项目整体近五分之一。而在本次揭晓的“2020中国技术力量年度榜单”决赛结果中,最终阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 在 2020 年,阿里不仅实现了双十一核心系统全面云原生化,一举成为全球规模最大、实力最硬核的云原生实践,并首次实现自研、开源、商业“三位一体…

Read More Read More

如何在Kubernetes中管理有状态应用

如何在Kubernetes中管理有状态应用

閱讀本文約花費: 7 (分鐘)在Kubernetes中,StatefulSet被用来管理有状态应用的API对象。StatefulSets在Kubernetes 1.9版本才稳定。StatefulSet管理Pod部署和扩容,并为这些Pod提供顺序和唯一性的保证。与Deployment相似的地方是,StatefulSet基于spec规格管理Pod;与Deployment不同的地方是,StatefulSet需要维护每一个Pod的唯一身份标识。这些Pod基于同样的spec创建,但互相之间不能替换,每一个Pod都保留自己的持久化标识。 ———- 1、使用StatefulSet的场景 对于下面的应用场景,StatefulSets是有价值的: 稳定、唯一的网络标识 稳定、持久的存储 按照顺序、优雅的部署和扩容 按照顺序、优雅的删除和终止 按照顺序、自动滚动更新 上述的稳定是持久的同义词,如果应用不需要稳定的标识或者顺序的部署、删除、扩容,则应该使用无状态的副本集。Deployment或者ReplicaSet的控制器更加适合无状态业务场景。 2、StatefulSet的限制 在Kubernetes 1.9版本之前是beta版本,在Kubernetes 1.5版本之前是不提供的。 Pod存储由PersistentVolume(storage类或者管理员预先创建)提…

Read More Read More

Kubernetes集群搭建:基于Kubeadm

Kubernetes集群搭建:基于Kubeadm

閱讀本文約花費: 16 (分鐘)一,环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二,Docker环境构建及替换 1,清除原Docker环境,原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2,如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…

Read More Read More

蚂蚁金服 Service Mesh 实践探索

蚂蚁金服 Service Mesh 实践探索

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后,蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中,我们遇到很多问题,面临各种挑战,也有了一些思路和方法。今天我们将这些实践分享出来,并结合我们开源的SOFAMesh项目,和大家一起探讨:如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好,我是来自蚂蚁金服中间件团队的敖小剑,目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人,是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行:蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道,今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么,能做什么,有什么优势。而是结合过去一年中蚂蚁金服的实践经验,结合蚂蚁金服的 SOFAMesh 产品,帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前,我们先来热个身,温习一下去年的内容。去年我是来布道的,而布道的核心内容就是告诉大家:Service Mesh 是什么? 为了帮忙大家回答,我给出一个提示图片,了解 Service M…

Read More Read More

别让自己“墙”了自己

别让自己“墙”了自己

閱讀本文約花費: 19 (分鐘)这一两周与几个朋友聊天,有年轻的90后,也有大叔级的70后,这些人在我看来都是很有能力的人,但是一些喜好过于强烈,让我不经意地回顾了我工作20年来身边的人,有发展得好的,也有发展的不好的,有些人是很可惜的,因为限制他们的不是其它人,也不是环境,而是自己,所以,很想写下这篇文章。(注:这篇文章可能会是一篇说教的文章,所以,可能会让你看着犯困,所以,我会尽量地短一些,而且尽可能多讲故事,少道理,这里的故事,全是真实发生的) 几个故事 2019年年初,我面试了一个很年轻的小伙子(93/94年出生),这个小伙子特别有灵性,也很聪明,计算机专业出身,也很喜欢技术,基础和学习能力也很好。在我这20年来认识的人中,如果他能呆在北京、上海、深圳这样的城市,我保证不出三年,他会成为他们同龄人中非常出色的技术人员,如果有个好的舞台有一个好的团队带他,他的未来会非常成功。然而,这个小伙子有两大喜好:1)只愿(或是说被迫)呆在一个毫无IT的环境的三/四线城市,2)对技术有非常大的偏好,只喜欢Go语言,非常不喜欢其它的语言,比如:Java(离开Java的世界,基本上离开了做架构的世界(相关解释见文末))。 他的这两个喜好,足以让一个未来会很优秀的人毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。 他把自己最宝贵的青春放在了很烂的项目上,就…

Read More Read More

Docker不香吗,为啥还要K8s?

Docker不香吗,为啥还要K8s?

閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开: Docker 的管理痛点 什么是 K8s? 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。 于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。 什么是 K8s ? image K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 …

Read More Read More

Kubernetes Informer 机制源码解析

Kubernetes Informer 机制源码解析

閱讀本文約花費: 14 (分鐘)这篇文章来源于云原生社区组织的 Kubernetes 源码研习社的作业,是个人学习Informer机制、理解Informer各个组件的设计的总结。 背景 为什么Kubernetes需要Informer机制?我们知道Kubernetes各个组件都是通过REST API跟API Server交互通信的,而如果每次每一个组件都直接跟API Server交互去读取/写入到后端的etcd的话,会对API Server以及etcd造成非常大的负担。而Informer机制是为了保证各个组件之间通信的实时性、可靠,并且减缓对API Server和etcd的负担。 Informer 流程 这个流程,建议先看看《From Controller Study Informer》 这里我们以CoreV1. Pod资源为例子: 第一次启动Informer的时候,Reflector 会使用 List从API Server主动获取CoreV1. Pod的所有资源对象信息,通过 resync将资源存放在 Store中 持续使用 Reflector建立长连接,去 Watch API Server发来的资源变更事件 当2 监控到CoreV1.Pod的资源对象有增加删除修改之后,就把资源对象存放在 DeltaFIFO中,…

Read More Read More

消息疯狂堆积!RocketMQ 出 Bug 了?

消息疯狂堆积!RocketMQ 出 Bug 了?

閱讀本文約花費: 21 (分鐘)前言 用过 MQ 的同学,可能会遇到过消息堆积的问题。而肥壕最近也踩上了这个坑,但是发现结果竟然是这么一个意料之外的原因而导致的。 正文 那一晚月黑风高,肥壕正准备踏上回家的路,突然收到告警短信轰炸!“MQ 消息堆积告警 [TOPIC: XXX] ” 肥壕心里“万只草泥马崩腾~” 第一反应是:“怎么肥事?刚下班就来搞事情???” 于是乎赶回公司赶紧打开电脑,登上 RocketMQ 后台查看(公司自己搭建的开源版RocketMQ) 握草 (キ`゚Д゚´)!!! 竟然堆积了3亿多条消息了??? 要知道出现消息堆积无在乎这个问题: 生产者的生产速度 >> 消费者的处理速度  1. 生产者的生产速度骤增,比如生产者的流量突然骤增 2. 消费速度变慢,比如消费者实例 IO 阻塞严重或者宕机 擦了一下头上的冷汗😓…赶紧登上消费者服务器瞧瞧。 应用运行正常!服务器磁盘IO 正常!网络正常! 再去上去生产者的服务器,咦…流量也很正常! 什么???佛了😨 …生产者和消费者的应用都很正常,但是为什么消息会堆积怎么多呢?看着这堆积的数量越堆越多(要是这是我头发的数量那该多好啊),越发着急。 虽然说 RocketMQ 版能支持 10 亿级别的消息堆积,不会因为消息堆积导致性能明显下降,&#x1…

Read More Read More

上 Kubernetes 到底有什么业务价值?

上 Kubernetes 到底有什么业务价值?

閱讀本文約花費: 13 (分鐘)开篇,我们先思考这样一个问题:“为什么要基于 Kubernetes 去构建一个应用管理平台?” 上图是一个本质的问题,我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题,我们上 Kubernetes 有什么业务价值?这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢?实际上这跟 K8s 的定位是相关的。K8s 这个项目呢,如果去做一个分析的话,我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢?大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API,这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象,而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口,实际上是对集群基础设施:网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD(也就是 Custom Resource)的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身,是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

Scroll Up