Browsed by
标签: 容器

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

docker常用命令

docker常用命令

閱讀本文約花費: 18 (分鐘)Docker Engine是一种开源容器化技术,用于构建和容器化您的应用程序。Docker Engine通过以下方式充当客户端-服务器应用程序: 具有长时间运行的守护进程的服务器dockerd。 API,用于指定程序可以用来与Docker守护程序进行对话和指示的接口。 命令行界面(CLI)客户端docker。 CLI使用Docker API通过脚本或直接CLI命令控制或与Docker守护程序进行交互。许多其他Docker应用程序都使用基础API和CLI。守护程序创建和管理Docker对象,例如映像,容器,网络和卷。 docker常用命令 中文版 $ docker –help Usage: docker [OPTIONS] COMMAND A self-sufficient runtime for containers一个可以独立运行的容器 Options:–config string 客户端配置文件的位置 (默认 “/home/mrdede/.docker”)-c, –context string 用于连接守护进程的上下文的名称 (使用“DOCKER上下文使用”覆盖DOCKER主机env变量和默认上下文设置)-D, –debug 启用调试模式-H, –host lis…

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

补习系列-springboot项目基础搭建课

补习系列-springboot项目基础搭建课

閱讀本文約花費: 10 (分鐘)前言 springboot 最近火的不行,目前几乎已经是 spring 家族最耀眼的项目了。抛开微服务、技术社区这些推广因素不说,框架本身的确有非常多的优点。比如 更简化的配置,摒除了许多繁杂的xml配置(事实证明,越简单的东西越容易让人记住); 内置Servlet容器,不再依赖外部环境 大量的starter模块,随手拈来 支持热部署 作为一名老程序员来说,仍然需要保持一个积极学习的态度。哎,简单点说就是少点伤感,认清现实。你曾经引以为傲的某某EE 技术已经被颠覆了,赶紧换车道 ….. 废话不多说,以下内容主要讲的是怎么利用springboot 这个脚手架搭建一个最精简的项目。其中几个模块会非常实用,这包括结构、配置、日志、部署.. 一、基础结构 springboot 项目仍然是使用maven 进行初始化及构建,下面是一个典型的结构: 目录文件 说明 pom.xml 依赖文件 src/main/java 代码目录 src/main/resources 配置目录,包含application.properties、log4j2.xml src/main/build 定义构建文件目录 src/test/java 测试代码 src/test/resources 测试配置 大致看一下就行了,不了解maven的话,点击这里先学习入门,项目的构建工具是…

Read More Read More

Clair助力Docker镜像安全

Clair助力Docker镜像安全

閱讀本文約花費: 5 (分鐘)Clair 是 CoreOS 最近发布的一款开源容器漏洞扫描工具。该工具可以交叉检查Docker 镜像的操作系统以及上面安装的任何包是否与任何已知不安全的包版本相匹配。漏洞是从特定操作系统的通用漏洞披露( CVE )数据库获取。该工具当前支持的操作系统包括 Red Hat 、 Ubuntu 和 Debian 。 通过从镜像文件系统中抽取静态信息以及维护一个组成镜像的不同层之间的差异列表,可以大大减少分析时间,而且不需要实际运行可能存在漏洞的容器。如果镜像所依赖的一个靠下的层存在漏洞,那么该镜像就会被识别为有漏洞,而且,通过使用图存储,可以避免重新分析镜像。 CoreOS使用Clair 分析用户上传到 Quay.io (一个类似 DockerHub 的容器注册中心)的 Docker 镜像。现已发现, Quay 上的大多数镜像都存在漏洞,甚至是像 Heartbleed(80%)或 Ghost(67%)这样的著名漏洞。2015 年初,一份有关 DockerHub 的报告推断,至少有30% 的官方镜像和多达40% 的用户上传镜像包含高级漏洞。期间,在 DockerCon 2015 欧洲大会上,…

Read More Read More

如何Docker化任意一个应用

如何Docker化任意一个应用

閱讀本文約花費: 10 (分鐘)网上有很多关于如何将应用 Docker 化的教程,为什么我还要再写一个呢? 我见过的大部分教程都是限定在某种特定技术(例如 Java 或者 Python),可能无法满足读者的需求。同时,这些教程也没有说清楚关于 Dev 和 Ops 团队之间建立明确约定所涉及到的所有相关方面(这正是容器化的精髓所在)。 我根据最近的经验总结了以下一些步骤。它是一份细节清单,包含了其他指南中忽略的内容。 声明:这不是一份新手指南。我建议读者先掌握一些如何设置和使用 docker 的基础知识,并且创建和运行一些容器之后,再来阅读。 让我们开始吧。 一、选择基础镜像 每种对应技术几乎都有自己的基础镜像,例如: https://hub.docker.com/_/java/ https://hub.docker.com/_/python/ https://hub.docker.com/_/nginx/ 如果不能直接使用这些镜像,我们就需要从基础操作系统镜像开始安装所有的依赖。 外面有很多教程使用的都是 Ubuntu(例如 ubuntu:16.04)作为基础镜像,这不能算有问题,但是我建议优先考虑 Alpine 镜像: https://hub.docker.com/_/alpine/ 它是一个非常小的基础镜像(大约只有 5MB)。 注意:在基于 Alpine 的镜像中无法使用“a…

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 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力?为什么这个社会需要管理?Kubernetes 是如此的成功,它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律(Conway’s Law) 随着信息技术的发展,以及现实的IT公司的成功,如Amazon、Netflix,以及云计算的普及,微服务的实践正在走向很多传统用户,然而,实施微服务的过程中,和DevOps的理念一样,人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是,伴随着微服务的发展,一位很少被人提及的科学家被推到了前端,也是被人忽视而尘封的科学家。 时间要拨回到1967年,Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文,其中被人们广为知道的结论: 设计系统【这里也不仅仅是指信息系统】的组织,其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理:为了能够让软件之间的模块相互作用,软件的撰写者们必须相互频繁的进行沟通,因此,系统的软件界面结构将会反映出打造此系统的组织的社会边界,要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

Read More Read More

Kubernetes 社区是如何运作的系列之一——哲学及治理

Kubernetes 社区是如何运作的系列之一——哲学及治理

閱讀本文約花費: 6 (分鐘)开源社区治理,正在逐渐的成熟,Linux、CNCF、OpenStack、Apache基金会等俨然成为软件业的中流砥柱,本土是不是应该潜心学习这些先进的管理/治理方式?精英制还是完全民主化?是不是应该以实际行动和理性思考来作出正确的判断? Mon Feb 5, 2018 | 1900 Words | 大约需要阅读 4 分钟 | | 引子 在2017年,关于容器的管理和调度平台,战火的硝烟渐渐的平息,Kubernetes 以压倒性的优势占据了这个细分领域的霸主,如下图来自 thenewstack 的调查: 如果仅仅从纯技术的角度而言,Kubernetes 和其它平台是半斤八两,处于伯仲之间,那么在社区的运营和赢得人们信任的方面,Kubernetes绝对是No.1,没有哪家能够相提并论。即使是Docker本身拥有无数拥泵的情况下,是容器的默认事实标准,也无法抵挡透明、开放、协作的Kubernetes社区的魅力。开源之道在Kubernetes 之所以成功的背后神秘力量 进行过专门的表述。 在上个月的中旬,Software Engineering Daily 的Jeff 撰写了一篇非常棒的文章:Kubernetes 的“下沉”,意指Kubernetes已经像Linux在单机操作系统的地位一样,成为分布式系统平台的默认选择。成为了分布式系统事实…

Read More Read More

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

閱讀本文約花費: 16 (分鐘)微服务国内发展背景: 2014年,Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内,2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地,2016-2017年,微服务的概念被越来越多的人认可,带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展,第一代以Spring Cloud为代表的微服务开发框架,该框架在微服务发展的前几年一度独领风骚,甚至在部分人群中成为微服务的代名词,但事实上该微服务框架并不是唯一实现微服务的方式;第二代微服务技术为服务网格(Service Mesh),它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的,又是何以赢得众多开发者的支持呢?笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层,主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,而对应用程序透明。 图1展示了服务网格的拓扑,当微服务数量增多达到几十上…

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

使用Istio治理微服务入门

使用Istio治理微服务入门

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄,服务治理难搞! 一、微服务的“痛点” 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。 微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面: 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(…

Read More Read More

Scroll Up