错误产生背景：在Kuberentes环境使用Deployment方式去创建Prometheus实例。用到的prometheus-deploy.yaml文件的内容如下：#错误1 apiVersion: apps/v1 kind: Deployment metadata: name: prometheus-core namespace: monitoring labels: app
一、Flannel1.1 简介Flannel由CoreOS研发，使用”虚拟网桥和veth设备”的方式为Pod创建虚拟网络接口，通过可配置的后端(backend)定义Pod间的通信网络。它支持基于VXLAN和UDP的Overlay网络，以及基于三层路由的Underlay网络。 对于每一个容器而言，在加入网络时，在每个节点创建一个虚拟交换机，并为每一
一、简介Helm是一个Kubernetes的包管理工具，就像linux下的包管理器，如yum/apt-get等。它将Kubernetes的资源打包到一个Chart中，并将制作、测试完成的各个Chart保存到仓库进行存储和分发。 Helm接入Kubernetes集群完成管理的逻辑与kubectl相似，都是加载kubeconfig文件。而kubeco
由于之前搭建的Kuberntes集群是单Master的，且存在高可用风险，故在此基础上升级Kubernetes版本的同时搭建Kubernetes高可用集群。同时为了后续管理方便，再额外部署Metrics Server和dashboard。一、高可用集群模型1.1 堆叠etcd这是kubeadm部署Kubernetes集群的默认拓扑(也是此次使用的)。在此架构中，每个Master节点均部署一个etc
一、Ingress和Ingress控制器1.1 为什么需要Ingress资源Kubernetes上的NodePort和LoadBalancer类型的Service资源能够把集群内部服务暴露给集群外部客户端进行访问。但是由于生产环境中业务多为分布式，暗含复杂的调用关系，且业务数量不止一个，由此会带来如下问题：如何管理端口当需要对外暴露的服务量比较多的时候，NodePort/LoadBalancer在
一、Kubernetes的访问控制体系API Server是Kubernetes集群的网关，是能够与etcd通信的唯一入口。因此，确保对API Server的安全访问至关重要。API Server会对每一次的访问请求进行合法性校验，包括用户身份验证、操作权限验证等。确认无误后才能访问或将数据存入到etcd中。 API Server内置了一个三级别的访问控制机
一、DaemonSet1.1 介绍与Deployment相似的是，DaemonSet也是基于标签选择器管控一组Pod副本。但是，DaemonSet用于确保所有或指定的工作节点上都运行有一个Pod副本。换句话说，其Pod数量由节点数量而定，因此无需定义replicas字段(Pod的副本数量)。从集群移除节点时，此类Pod对象也将被自动回收而无需重建。 它通常用
一、Kubernetes控制器介绍Kubernetes 的核心就是控制理论，Kubernetes控制器中实现的控制回路是一种闭环反馈控制系统，该类型的控制系统基于反馈回路将目标系统的当前状态与预定义的期望状态相比较，二者之间的差异作为误差信号产生一个控制输出作为控制器的输入，以减少或消除目标系统当前状态与期望状态的误差，通过实时运行相应的程序代码尝试让对象的真实状态向期望状态逐渐逼近。如下图所示。
一、基于DNS的服务发现ClusterDNS(CoreDNS)是Kubernetes集群的必备附件，负责为Kubernetes提供名称解析和服务发现。每个Service对象在创建时都会生成一个遵循”<service>.<ns>.svc.<zone>”格式的名称，由ClusterDNS为该名称生成资源记录。service、ns、zone分别代表服务的名称、名称空间
一、Service资源基础1.1 介绍在Kubernetes中，Pod资源是应用程序的载体，我们可以通过Pod的ip来访问应用程序，但是Pod的ip地址不是固定的，这就意味着不方便直接采用Pod的ip对服务进行访问。 为了解决这个问题，Kubernetes提供了Service资源，Service会对提供同一个服务的多个Pod进行聚合，并且提供一个统一的入口地
一、Configmap和Secret基础当某个服务需要修改配置文件时，如果涉及多个服务器，或者是多实例，而且不同的实例在不同的环境下配置要求还不一样，这样每台物理机或每个实例都得手动修改。还有一种方法是把配置文件嵌入到镜像中，那也要每修改一次配置文件就得打一次镜像，路径长且效率也不高，这些方式都难以满足线上大批量的配置变更需求。 为此，Kubernetes引
一、存储卷基础1.1 背景Pod本身具有生命周期，其应用容器及生成的数据均无法独立于该生命周期之外持久存在。同一Pod中的容器默认共享PID、network、IPC(进程间通信)、UTS名称空间，但Mount和USER仍各自独立。因此跨容器间的进程彼此间默认无法基于共享的存储空间交换数据。由此看来，借助独立于Pod生命周期的存储设备实现数据持久化成了必然选择。1.2 概述存储卷是定义在Pod资源之
一、Pod设计模式1.1 容器设计模式基于容器的分布式系统中常用的3类设计模式单容器模式：单一容器形式运行的应用。现代应用容器技术用来运行单个进程(包括子进程)单节点多容器模式：即跨容器的设计模式，目的是在单个主机上运行多个具有超亲密关系的容器(进程)，因此容器管理系统需要将其作为一个原子单位进行统一调度。Kubernetes编排系统设计的Pod概念就是该设计模式的实现之一。多节点模式：将分布式应
一、通过环境变量向容器传递参数即在容器中嵌套使用env字段。Name定义环境变量名，值定义在value字段上。apiVersion: v1 kind: Pod metadata: name: pod-using-env namespace: default spec: containers: - name: demo image: ikubernetes/demoapp:v1.0 im
一、对Pod的介绍1.1 什么是Pod它是一个或多个容器的集合，又称为容器集。它是Kubernetes调度、部署、运行应用的最小单元(原子单元，即不可分割的整体)。Pod内封装的内容：可被其内部多个容器共享的存储资源、网络环境等。 Pod内的“基础设施容器”Pause容器事先创建可被各个应用容器共享的基础环境，默认共享network、IPC(进程间通信)、UTS名称空间给各容器。PID名
API对象：也就是K8S的资源对象，是K8S集群中的管理操作单元。K8S集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。一、Kubernetes资源对象查询1.1 查询资源类型#列出当前集群中所有的资源类型 kubectl api-resources 字段说明 NAME：资源名(复数形式) SHORTNAMES
一、Kubernetes简介Kubernetes，又称为 k8s（首字母为 k、首字母与尾字母之间有 8 个字符。尾字母为s，主要用于自动部署、扩缩和管理容器化应用程序。简单的说就是，K8S就是个编排运行容器的集群。从本质上说，Kubernetes是“以应用为中心”的现代应用基础设施。 在Docker技术的基础上，Kubernetes为容器化的应用提供部署运
一、Harbor介绍Docker容器应用的开发和运行离不开可靠的镜像管理，虽然Docker官方也提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署我们私有环境内的Registry也是非常必要的。Harbor是由VMware公司开源的企业级的Docker Registry管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。二、Harbor的结构
一、Docker Compose介绍当在宿主机启动较多的容器时候，如果都是手动操作会觉得比较麻烦而且容易出错，此时推荐使用 docker 单机编排工具 docker-compose。 docker-compose 是 docker 容器的一种单机编排服务，docker-compose 是一个管理多个容器的工具，比如：可以解决容器之间的依赖关系，就像启动一个n
一、Docker默认的网络通信1.1 Docker安装后默认的网络配置Docker服务安装完成之后，默认在每个宿主机会生成一个名称为docker0的网卡其IP地址都是 172.17.0.1/16。1.2 创建容器后的网络配置 每次新建容器后：宿主机就会多了一个虚拟网卡，和容器的网卡组合成一个网卡，比如：27: veth7a2c992@if26，而在容器内的网
Docker镜像由多个只读层叠加而成，启动容器时，Docker会加载只读镜像层并在镜像栈顶部添加一个读写层。如果运行中的容器修改了现有的一个已经存在的文件，那该文件将会从读写层下面的只读层复制到读写层，该文件的只读版本仍然存在，只是已经被读写层中该文件的副本所隐藏，此即”写时复制(COW copy on write)"机制。这个读写层就是容器的工作目录。一、容器的数据管理介绍Docker镜像是分层
一、镜像的制作方式Docker 镜像制作类似于虚拟机的镜像（模版）制作，即按照公司的实际业务需求将需要安装的软件、相关配置等基础环境配置完成，然后将其做成镜像，最后再批量从镜像批量生成容器实例，这样可以极大的简化相同环境下的部署工作。 Docker的镜像制作分为手动制作（基于容器，docker commit）和自动制作(基于DockerFile，再dock
一、Docker介绍1.1 容器与虚拟机的对比传统虚拟机是虚拟出一个主机硬件，并且运行一个完整的操作系统，然后在这个系统上安装和运行软件。而容器内的应用直接运行在宿主机的内核之上，容器没有自己的内核，也不需要虚拟硬件，相当轻量化。多个容器可共享宿主机的操作系统(内核)。每个容器间是互相隔离的，即每个容器内都有一个属于自己的独立文件系统，独立的进程空间，网络空间，用户空间等。所以在同一个宿主机上的多
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
