K8s

k8s集群StatefulSets的Pod调度查问失落问题?考点之简略介绍下StatefulSets 和 Deployment 之间有什么本质区别？特定场景该如何做出抉择呢？考点之你能辩证的说说看StatefulSets 和 Deployment具体有哪些区别嘛？考点之你理解k8s集群StatefulSets的Pod调度查问失落问题吗？k8s集群中StatefulSet治理的Pod曾经实现调度并启动，为什么还是无奈查问Pod 的 DNS 命名？ 囧么肥事-胡言乱语 简略介绍下StatefulSets 和 Deployment 之间有什么本质区别？首先、StatefulSet 和Deployment 都是用来治理利用的工作负载 API 对象，都治理基于各自雷同容器规约的一组 Pod，同时负责各自治理的Pod 汇合的部署和扩缩、更新回滚等。 但和 Deployment 实质上不同的是，StatefulSets 用来治理有状态利用，而Deployment 负责管理无状态利用。 如果应用程序不须要任何稳固的标识符或有序的部署、删除或伸缩，则应该应用 由一组无状态的正本控制器提供的工作负载来部署应用程序，比方 Deployment或者ReplicaSet。 如果心愿应用存储卷为工作负载提供长久存储，能够应用 StatefulSet 作为解决方案的一部分。 只管 StatefulSet 中的单个 Pod 仍可能呈现故障， 但长久的 Pod 标识符 能够更容易将现有卷与于从新调度的Pod进行绑定。 说道这里，上面简略介绍一下，利用分类： 利用通常能够分为两大类：有状态与无状态 无状态利用 简略了解就是没有非凡状态的服务服务和数据拆散，自身不存储数据各个申请对于服务器来说对立无差别解决申请能够随机发送到任意一台server上申请本身携带了所有服务端所须要的所有参数服务本身不存储跟申请相干的任何数据有状态利用 容器数据须要长久化放弃对于有数据存储性能的服务每个实例都须要有本人独立的长久化存储或者指多线程类型的服务、队列mysql数据库、kafka、zookeeper等如果server是有状态的，客户端须要始终把申请发到同一台server才行， 同时，这里了解StatefulSets 两个关键点：1、稳固的 2、有序的 “稳固的”意味着 Pod 调度或重调度的整个过程是有持久性的“有序的”意味着 Pod 调度或重调度的整个过程是须要放弃程序的对于Deployment 的具体情况，可参考：【跟k8s工作负载Deployments的缘起缘灭】 你能辩证的说说看StatefulSets 和 Deployment具体有哪些区别嘛？Deployment治理的Pod特点 Deployment被设计用来治理无状态服务的pod，每个pod完全一致 无序性：无状态服务的多个Pod正本创立和销毁是无序的，能够并行创立或销毁，相互之间不用期待，除了须要恪守规约中定义的正本个数之外，没有其余制约。随机性：无状态服务的多个Pod正本的名称是随机的，pod被重新启动调度后，它的名称与IP都会发生变化，替换为一个新的正本。共享性：无状态服务的多个Pod正本共享存储卷。Deployment中Pod基于template定义存储卷，所有正本集共用一个存储卷。 StatefulSets治理的Pod特点 StatefulSets 被设计用来治理有状态的利用，StatefulSet 治理的 Pod 具备惟一的标识，该标识包含程序标识、稳固的网络标识和稳固的存储。 并且该标识和 Pod 是绑定，不论它被调度在哪个节点上，最终都会被绑定这个惟一标识。 ...

减速 Kubernetes 镜像拉取Kubernetes pod 启动时会拉取用户指定的镜像，一旦这个过程耗时太久就会导致 pod 长时间处于 pending 的状态，从而无奈疾速提供服务。 镜像拉取的过程参考下图所示： Pod 的 imagePullPolicy 镜像拉取策略有三种： IfNotPresent：只有当镜像在本地不存在时才会拉取。Always：kubelet 会比照镜像的 digest ，如果本地已缓存则间接应用本地缓存，否则从镜像仓库中拉取。Never：只应用本地镜像，如果不存在则间接失败。阐明：每个镜像的 digest 肯定惟一，然而 tag 能够被笼罩。 从镜像拉取的过程来看，咱们能够从以下三个方面来减速镜像拉取： 缩减镜像大小： 应用较小的根底镜像、移除无用的依赖、缩小镜像 layer 、应用多阶段构建等等。 举荐应用 docker-slim放慢镜像仓库与 k8s 节点之间的网络传输速度。被动缓存镜像： Pre-pulled 预拉取镜像，以便后续间接应用本地缓存，比方能够应用 daemonset 定期同步仓库中的镜像到 k8s 节点本地。题外话 1：本地镜像缓存多久？是否会造成磁盘占用问题？ 本地缓存的镜像肯定会占用节点的磁盘空间，也就是说缓存的镜像越多，占用的磁盘空间越大，并且缓存的镜像默认始终存在，并没有 TTL 机制（比如说多长时间当前主动过期删除）。 然而，k8s 的 GC 机制会主动清理掉镜像。当节点的磁盘使用率达到 HighThresholdPercent 高百分比阈值时（默认 85% ）会触发垃圾回收，此时 kubelet 会依据应用状况删除最旧的不再应用的镜像，直到磁盘使用率达到 LowThresholdPercent（默认 80% ）。 题外话 2：镜像 layer 层数真的越少越好吗？ 咱们常常会看到一些文章说在 Dockerfile 里应用更少的 RUN 命令之类的缩小镜像的 layer 层数而后缩减镜像的大小，layer 越少镜像越小这的确没错，然而某些场景下得失相当。首先，如果你的 RUN 命令很大，一旦你批改了其中某一个小的局部，那么这个 layer 在构建的时候就只能从新再来，无奈应用任何缓存；其次，镜像的 layer 在上传和下载的过程中是能够并发的，而独自一个大的层无奈进行并发传输。 ...

net.ipv4.tcp_keepalive_time=600net.ipv4.tcp_keepalive_intvl=30net.ipv4.tcp_keepalive_probes=10net.ipv6.conf.all.disable_ipv6=1net.ipv6.conf.default.disable_ipv6=1net.ipv6.conf.lo.disable_ipv6=1net.ipv4.neigh.default.gc_stale_time=120net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0net.ipv4.conf.default.arp_announce=2net.ipv4.conf.lo.arp_announce=2net.ipv4.conf.all.arp_announce=2net.ipv4.ip_local_port_range= 45001 65000net.ipv4.ip_forward=1net.ipv4.tcp_max_tw_buckets=6000net.ipv4.tcp_syncookies=1net.ipv4.tcp_synack_retries=2net.bridge.bridge-nf-call-ip6tables=1net.bridge.bridge-nf-call-iptables=1net.netfilter.nf_conntrack_max=2310720net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536net.core.netdev_max_backlog=16384net.core.rmem_max = 16777216 net.core.wmem_max = 16777216net.ipv4.tcp_max_syn_backlog = 8096 net.core.somaxconn = 32768 fs.inotify.max_user_instances=8192 fs.inotify.max_user_watches=524288 fs.file-max=52706963fs.nr_open=52706963kernel.pid_max = 4194303net.bridge.bridge-nf-call-arptables=1vm.swappiness=0 vm.overcommit_memory=1 vm.panic_on_oom=0 vm.max_map_count = 262144内核参数解释 net.ipv4.tcp_keepalive_time=600 #此参数示意TCP发送keepalive探测音讯的间隔时间(秒)net.ipv4.tcp_keepalive_intvl=30 #tcp查看间隔时间（keepalive探测包的发送距离）net.ipv4.tcp_keepalive_probes=10 #tcp查看次数（如果对方不予应答，探测包的发送次数）net.ipv6.conf.all.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6net.ipv6.conf.default.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6net.ipv6.conf.lo.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6net.ipv4.neigh.default.gc_stale_time=120 #ARP缓存条目超时net.ipv4.conf.all.rp_filter=0 #默认为1，零碎会严格校验数据包的反向门路，可能导致丢包net.ipv4.conf.default.rp_filter=0 #不开启源地址校验net.ipv4.conf.default.arp_announce=2 #始终应用与目标IP地址对应的最佳本地IP地址作为ARP申请的源IP地址net.ipv4.conf.lo.arp_announce=2 #始终应用与目标IP地址对应的最佳本地IP地址作为ARP申请的源IP地址net.ipv4.conf.all.arp_announce=2 #始终应用与目标IP地址对应的最佳本地IP地址作为ARP申请的源IP地址net.ipv4.ip_local_port_range= 45001 65000 # 定义网络连接可用作其源（本地）端口的最小和最大端口的限度，同时实用于TCP和UDP连贯。net.ipv4.ip_forward=1 # 其值为0,阐明禁止进行IP转发；如果是1,则阐明IP转发性能曾经关上。net.ipv4.tcp_max_tw_buckets=6000 #配置服务器 TIME_WAIT 数量net.ipv4.tcp_syncookies=1 #此参数应该设置为1，避免SYN Floodnet.ipv4.tcp_synack_retries=2 #示意回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包），进行重试的次数（默认为5）net.bridge.bridge-nf-call-ip6tables=1 # 是否在ip6tables链中过滤IPv6包net.bridge.bridge-nf-call-iptables=1 # 二层的网桥在转发包时也会被iptables的FORWARD规定所过滤，这样有时会呈现L3层的iptables rules去过滤L2的帧的问题net.netfilter.nf_conntrack_max=2310720 #连贯跟踪表的大小，倡议依据内存计算该值CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)，并满足nf_conntrack_max=4*nf_conntrack_buckets，默认262144net.ipv6.neigh.default.gc_thresh1=8192net.ipv6.neigh.default.gc_thresh2=32768net.ipv6.neigh.default.gc_thresh3=65536#gc_thresh3 是表大小的相对限度#gc_thresh2 设置为等于零碎的最大预期街坊条目数的值#在这种状况下，gc_thresh3 应该设置为一个比 gc_thresh2 值高的值，例如，比 gc_thresh2 高 25%-50%，将其视为浪涌容量。#gc_thresh1 进步到较大的值；此设置的作用是，如果表蕴含的条目少于 gc_thresh1，内核将永远不会删除（超时）过期的条目。net.core.netdev_max_backlog=16384 # 每CPU网络设备积压队列长度net.core.rmem_max = 16777216 # 所有协定类型读写的缓存区大小net.core.wmem_max = 16777216 # 最大的TCP数据发送窗口大小net.ipv4.tcp_max_syn_backlog = 8096 # 第一个积压队列长度net.core.somaxconn = 32768 # 第二个积压队列长度fs.inotify.max_user_instances=8192 # 示意每一个real user ID可创立的inotify instatnces的数量下限，默认128.fs.inotify.max_user_watches=524288 # 同一用户同时能够增加的watch数目，默认8192。fs.file-max=52706963 # 文件描述符的最大值fs.nr_open=52706963 #设置最大微博号关上数kernel.pid_max = 4194303 #最大过程数net.bridge.bridge-nf-call-arptables=1 #是否在arptables的FORWARD中过滤网桥的ARP包vm.swappiness=0 # 禁止应用 swap 空间，只有当零碎 OOM 时才容许应用它vm.overcommit_memory=1 # 不查看物理内存是否够用vm.panic_on_oom=0 # 开启 OOMvm.max_map_count = 262144 ...

云原生新时代弄潮儿k8s凭什么在容器化方面自成一家？ Kubernetes 能够为做些什么?在学习一种新技能之前，囧囧倡议不要下来先看各种牛叉的实现，咱们须要先搞清楚这个技能是什么？学习了之后能为咱们晋升什么有用的价值。毕竟在当今技术疾速更新迭代的时代，咱们没有足够的精力去学习太多没有用的常识去扩大的无用的广度，只有你明确了你须要学习的货色的价值，你才有能源去继续跟进，去分析，去了解，去爱上它，用它发明价值。 Kubernetes 是什么?Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 官网解读 Kubernetes 是一个可移植的，可扩大的开源平台。用于治理容器化的工作负载和服务，不便了申明式配置和自动化。它领有一个宏大且快速增长的生态系统。Kubernetes 的服务，反对和工具宽泛可用。部署演进 传统部署 各个组织机构在物理服务器上运行应用程序。无奈为物理服务器中的利用程序定义资源边界，更多的抉择是凭借工程师的集体教训去分配资源，也就是无奈正当的去布局资源分配，这会导致资源分配问题。虚拟化部署 虚拟化技术容许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。容许应用程序在 VM 之间隔离，虚拟化技术可能更好地利用物理服务器上的资源，相比于传统部署形式，长处是更好的可伸缩性，升高硬件老本。容器部署 以应用程序为核心的治理资源隔离的粒度更细腻，比VM要更简洁，更容易扩大移植，容器相似于 VM，然而它们具备被放宽的隔离属性，能够在应用程序之间共享操作系统（OS）。为什么须要 Kubernetes，它能做什么? 利用容器化 容器是打包和运行应用程序的好形式。容器化曾经做到应用程序能以简略疾速的形式公布和更新。线上环境咱们应用程序须要继续稳固的运行，不能早上部署好了，下午用户无奈应用。 呈现故障问题的时候，须要有疾速响应的机制去确保不会造成重大影响。 程序是无错的状况下，对应到容器层面，就是咱们须要保障容器是正确的，不能因为容器的意外而影响到火线。 这意味着咱们须要治理运行应用程序的容器，时刻监督着运行状况，并确保容器不会停机。 如果一个容器产生故障，须要疾速采取措施，例如重启容器，或者另外启动一个容器去代替它。 中午凌晨两点钟，你在家里呼呼大睡，线上疯狂报警，你不得不连忙起床解决 咦，想想都惨呀！ 如果交给零碎去解决容器问题，会不会更容易？更不便？不再须要你精力高度集中每天留神可能产生的各种意外状况？ 所以，k8s来了，它来了，它来了，它带着旋风跑来了！ Kubernetes 提供了一个可弹性运行分布式系统的框架。 服务发现和负载平衡 Kubernetes 能够应用 DNS 名称或本人的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 能够负载平衡并调配网络流量，从而使部署稳固。 存储编排 Kubernetes 容许你主动挂载你抉择的存储系统，例如本地存储、公共云提供商等。 主动部署和回滚 你能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态 更改为冀望状态。例如，你能够自动化 Kubernetes 来为你的部署创立新容器， 删除现有容器并将它们的所有资源用于新容器。 主动实现装箱计算 Kubernetes 容许你指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源申请时，Kubernetes 能够做出更好的决策来治理容器的资源。 自我修复 ...

前言记得去年2021上半年的时候自学了k8s并且应用helm装置了rabbitmq和redis，能够在开发、测试和生产环境上用起来，然而下半年之后就没有用，再拾起来的时候发现好多知识点都忘了，这篇文章就是总结应用helm装置rabbmitmq和redis的集体总结分享给大家。 总结1、将服务裸露给内部客户端第一种通过service类型裸露： 这里先理解下service的几种类型： Clusterip：默认类型，主动调配一个仅 Cluster 外部能够拜访的 虚构IP，个别用作集群外部负载平衡。 NodePort（service向外裸露)：在ClusterIP 根底上为 Service 在每台机器上绑定一个映射端口，外网客户端能够通过 NodeIP，Nodeport拜访。 LoadBalancer（service向外裸露)：在 NodePort 根底上，借助 cloud provider 创立一个内部负载均衡器，并将申请转发到 NodeIP 和 NodePort ExternalName：把集群内部的服务引入到集群外部来，在集群外部间接应用。没有任何类型代理被创立，只有1.7之后版本的 kube-dns反对。 所以能够设置service为NodePort或者LoadBalancer来对外裸露服务 第二种通过ingress裸露：此外externalIPs也能够使各类service对外提供服务，然而当集群服务很多的时候，NodePort形式最大的毛病是会占用很多集群机器的端口；LB形式最大的毛病则是每个service一个LB又有点节约和麻烦，并且须要k8s之外的反对； 而ingress则只须要一个NodePort或者一个LB就能够满足所有service对外服务的需要。 2、不同环境下rabbitmq或者redis拜访形式不同例如：开发环境和测试环境下rabbitmq拜访都不同，首先讲测试环境，个别咱们测试环境都会有台测试服务器，咱们只有把rabbitmq和前台及后盾的pod放到同一个集群内，这样咱们能够通过k8s的集群域名形式来拜访，如上面： test-redis-master.redis.svc.cluster.localtest-rabbitmq.rabbitmq.svc.cluster.local这个域名如何失去呢？能够通过装置dnsutils来解析： kubectl run dnsutils --image=tutum/dnsutils --generator=run-pod/v1 --command -- sleep infinitykubectl exec dnsutils -- nslookup test-rabbmit-headless.rabbitmq 130 ↵Server: 172.21.0.10Address: 172.21.0.10#53Name: nacos-headless.default.svc.cluster.localAddress: 172.20.0.119然而，开发环境则不同，因为开发环境的代码在咱们本地机器下面，所以你不能应用下面的集群域名来拜访，那么如何做到本地机器拜访rabbitmq和redis服务呢，答案就在下面的总结外面，咱们能够通过下面的三种形式来裸露rabbitmq和redis，哪三种呢？以及开发环境应该选取哪种？ 1、NodePort2、LoadBalancer3、Ingress这里我只会对开发环境来谈，既然是开发环境，咱们则用最小的代价来实现工作，咱们首选是NodePort，因为rabbitmq和redis咱们应用的是StatefulSet有状态形式来部署，那么显然IP也是固定的，咱们只有通过节点IP+PORT形式来拜访即可，节点IP能够通过观察pod或者service第三方服务商的后盾管理系统即可看到，当然你也能够通过命令查看。 3、Helm删除服务间接在第三方服务商的控制台操作即可，留神连同PVC也一起删除了。 4、什么是无头服务（Headless Services） ？有时不须要或不想要负载平衡，以及独自的 Service IP。 遇到这种状况，能够通过指定 Cluster IP（spec.clusterIP）的值为 "None" 来创立 Headless Service。 留神：1、同Service下的pod能够间接依据PodIP互相通信不同Service下的pod在集群间pod通信要借助于 cluster ipService的IP地址，此为虚构IP地址。内部网络无奈ping通，只有kubernetes集群外部拜访应用。 2、dnsutils指定命名空间的查问： kubectl exec -i -t dnsutils -- nslookup <service-name>.<namespace>3、在开发环境下Service类型设置成NodePort后，要找到正确的对应端口和IP，否则拜访失败，如：拜访rabbitmq ...

成为一名k8s专家须要把握哪些常识在残缺的浏览了k8s源码，梳理了160多篇文档之后我进行如下的总结：当然次要目标是列举一些关键点：具体细节受限篇幅不会贴出来教程地址k8s底层原理和源码解说之进阶篇k8s底层原理和源码解说之精髓篇k8s常识图谱01 容器底层常识01 到底什么是容器：简略说就是受限制的过程，底层相干的两个技术是linux的namespace和cgrop namespace 的分类和sandbox容器的关系，哪些ns是共享的，波及到容器的隔离不彻底问题cgroup v1 和v2 的区别，cpu/mem限度的原理，cpu绑核如何操作02 容器镜像：镜像不是docker的专利 OCI（Open Container Initiative）标准是事实上的容器规范，曾经被大部分容器实现以及容器编排零碎所采纳。任何实现了OCI标准的工具都能够打镜像标准要求镜像内容包含以下 几个 局部： 3个必须的 Image Manifest ：提供了镜像的配置和文件系统层定位信息，能够看作是镜像的目录，文件格式为 json 。Image Layer Filesystem Changeset ：序列化之后的文件系统和文件系统变更，它们可按程序一层层利用为一个容器的 rootfs，因而通常也被称为一个 layer（与下文提到的镜像层同义），文件格式能够是 tar ，gzip 等存档或压缩格局。Image Configuration ：蕴含了镜像在运行时所应用的执行参数以及有序的 rootfs 变更信息，文件类型为 json。1个可选的 image-index : 图像索引是一种更高级别的清单，它指向特定的图像清单，非常适合一个或多个平台03 容器联结文件系统：overlayfs 的了解 容器run起来时对应的3个层： image layer (只读)，镜像的层init layer 容器在启动时写入的一些配置文件，产生在 container layer之前container layer 新增的可写层copy on write技术 益处是缩小镜像体积，晋升启动速度，毛病就是写入的速度慢，所以在 container layer 中不适宜进行大量的文件读写，应该应用Volume04 容器运行时 CRI次要包含两个 gRPC 服务，ImageService 和 RuntimeService grpc服务剖析 ImageService 服务次要是拉取镜像、查看和删除镜像等操作RuntimeService 则是用来治理 Pod 和容器的生命周期，以及与容器交互的调用（exec/attach/port-forward）等操作Exec等交互服务也能够独自进去做一个StreamServicelow/high level容器运行时 如runc、lxc、containerd、docker、libcontainerd 他们有什么区别docker 的组件被拆分成什么样子了，它们都负责干什么02 k8s计算01 内置资源的惯例操作 ...

作者 | 元毅（阿里云容器平台高级开发工程师） 微信搜寻关注 Serverless 公众号，后盾回复 深圳 可获取本文 PPT 导读Kubernetes 作为当今云原生业界规范，具备良好的生态以及跨云厂商能力。Kubernetes 很好的形象了 IaaS 资源交付规范，使得云资源交付变的更简略，与此同时越来越多的用户冀望可能聚焦于业务本身，做到面向利用交付，Serverless 理念也因而而生。 那么如何通过原生 Kubernetes 提供 Serverless 能力？如何借力丰盛的云原生社区生态？本文给大家介绍一下咱们在 Serverless Kubernetes 上的落地实际。本文将从以下 3 个方面开展介绍： 为什么要做Serverless Kubernetes如何实现Serverless KubernetesServerless Kubernetes 落地实际 Serverless Kubernetes 初衷1、 Kubernetes 家喻户晓，Kubernetes 是一款开源容器化编排零碎，用户应用 Kubernetes 能够做到升高运维老本、进步运维效率，并且提供标准化 API，某种意义就是防止被云厂商绑定，进而造成了以 Kubernetes 为外围的云原生生态。能够说 Kubernetes 未然成为了云原生业界事实标准。 2、Serverless 与 Kubernetes那么咱们回到 Serverless 下面来，Serverless 的核心理念在于让开发者更聚焦业务逻辑，缩小对基础设施的关注。那么咱们如何在云原生业界规范之上做 Serverless，Kubernetes 是否也能做到更专一于利用业务逻辑。 3、Kubernetes 做 Serverless 的劣势 在看一下 Kubernetes 做 Serverless 有什么劣势前，咱们先来看一下 Kubernetes 个性包含哪些： 容器化对立 IaaS 资源交付CI/CD 继续集成部署跨云厂商丰盛的生态面向利用治理 ...

kubernetes（k8s） 中装置kuboard面板 01 — 背景及装置 Kuboard 是一款专为 Kubernetes 设计的收费治理界面，兼容 Kubernetes 版本 1.13 及以上。Kuboard 每周公布一个 beta 版本，最长每月公布一个正式版本，通过两年的一直迭代和优化，曾经具备多集群治理、权限治理、监控套件、日志套件等丰盛的性能。 删除之前的版本 docker stop $(docker ps -a | grep "eipwork/kuboard" | awk '{print $1 }')docker rm $(docker ps -a | grep "eipwork/kuboard" | awk '{print $1 }')装置最新版 sudo docker run -d \ --restart=unless-stopped \ --name=kuboard \ -p 80:80/tcp \ -p 10081:10081/udp \ -p 10081:10081/tcp \ -e KUBOARD_ENDPOINT="http://192.168.1.12:80" \ -e KUBOARD_AGENT_SERVER_UDP_PORT="10081" \ -e KUBOARD_AGENT_SERVER_TCP_PORT="10081" \ -v /root/kuboard-data:/data \ eipwork/kuboard:v3.3.0.3在浏览器输出 http://192.168.1.12 即可拜访 Kuboard 的界面，登录形式： ...

上一期内容中，咱们简略为大家介绍了fluentd、docker和日志采集器的架构。当初，咱们开始实操。 【 SpotMax 解决方案充分利用了云原生个性，基于微服务架构，可在保障用户服务稳固的同时充分利用Spot实例，实现云端降本增效。戳链接理解SpotMax】首先来看一下dockerfile，咱们能够去fluentd的官网上（docs.fluentd.org）获取根底镜像：而后咱们能够通过run加上一些命令，对容器做初始化：有了docker file，咱们就能够通过docker build，来创立一个镜像。-t前面是镜像名称，冒号：前面是一个版本：创立完镜像之后，咱们能够通过docker image，获取镜像列表:咱们也能够把镜像推到近程docker hub里。Docker hub是官网的远程管理性能，能够收费注册：咱们通过docker login登录之后，再通过docker push就能够把镜像推送到近程了：当初曾经有了一个镜像，咱们来run一个container。 首先，跑一个长期的容器。--rm代表运行长期容器，--network host代表用一个host的网络连接模式；-v代表把本地的一个目录，挂载到容器上的目录;最初面跟的是一个命令，指的是fluentd的client端的配置，server端同理：咱们来看一下client端的配置写了些什么：source代表起源；@type前面是插件名称（tail)Path前面是咱们要去读的本地日志，以及相应的pos_file、日志tag（这里取名为test）接下来，咱们match tag，就能够利用forward（output插件），通过tcp、udp的形式打到另外一个服务集群。当初，咱们再来看一下fluentd的server端配置：通过forward插件，咱们能够监听24224端口，拿到日志流，再通过match tag (即后面的test），用stdoutput间接输入，咱们也能够把它打到kafka，或者运行本人的插件等。当初来运行一下看看成果：首先咱们跑一下fluentd的server端，能够看到曾经在监听了：再看看fluentd的client端，如图，能够看到它当初曾经在读容器外面的一个日志文件：因为这个容器的目录，曾经绑定在宿主机的一个目录上，咱们能够通过下图中标示出的这条命令（每秒钟打一个just for fun），往日志中打一些音讯：能够看到，server端曾经可能失常接管到音讯（just for fun)：咱们整个演示都是跑在docker容器上的，咱们能够通过docker ps去看容器的列表：如图所示，曾经起了两个容器，咱们能够用 docker kill，去kill一个容器：将来的文章中，咱们将会介绍怎么把日志采集器部署到k8s下面去，请关注“云上说禅”。

11 月 23 日，Erda 与 OSCHINA 社区联手发动了【高手问答第 271 期 -- 聊聊大规模 K8s 集群治理】，目前问答流动已继续一周，由 Erda SRE 团队负责人骆冰利为大家解答，以下是本次流动的局部问题整顿合集，其余问题也将于近期整顿后公布，敬请期待！ Q1：K8s 下面部署不通的利用对于存储有不同的要求，有的要高吞吐，有的是要低响应。大规模 K8s 部署的时候是怎么协调这种存储差别的问题？还是说须要依据不同的场景，运维不同的存储服务？又或者说尽量存储应用解决方案？ A1：存储绝对于 CPU 和内存的确会更简单一些，就是因为它会蕴含更多类型，不同的存储空间，不同的性能要求。所以存储还是得从利用需要登程，来满足不同的存储需要。 Q2：请问下你们保护的最大 K8s 集群规模大小是多少？遇到了哪些性能、稳定性问题？做了哪些优化？ A2：咱们目前保护的单个集群规模不大，总量绝对大些，保护了几百个集群。量上来了就会碰到不拘一格的问题，比方：如何晋升运维效率？如何比用户更早地发现问题？如何优化内存碎片问题？如何优化磁盘驱赶带来的隐患？。咱们也做了很多事件：第一步进行标准化，比方对立操作系统、对立版本、标准化节点规格、零碎数据盘拆散等等。接着开始建设诊断系统，笼罩操作系统、容器、K8s、惯例中间件、平台（利用）等，目前就是先于用户发现问题，能全方位进行巡检笼罩，能够将其了解为运维零碎的眼睛，近期咱们刚好也开源了这个零碎：kubeprober。以后也会有对应的一些优化，比方: 补充 docker k8s 的 log rotate 参数，优化 gc、eviction 参数，避免磁盘被写满；对 Pod PID 进行限度、EmtyDir 存储、容器可写层大小等进行限度；保障 K8s 要害 Pod 的调度；敞开 swap，优化 /proc/sys/vm/min_free_kbytes 等参数，优化内存回收。 问题有些大，波及的工作也会特地多，我也只是列举了局部，每个点上都还能够做更多的事件。 kubeprober 开源地址：https://github.com/erda-proje... Q3：老师目前容器化部署编排企业公有老本远没有云厂商实惠，这会不会造成垄断趋势？还有 Serverless 的倒退是不是对容器技术的冲击呢? A3：会有些现状问题，国内不少企业都有自建 IDC，尤其是一些头部企业。不管思考是进行利旧，还是数据安全性等，客户都会有不同的决策，所以肯定会有共存的状况。 Q4：K8s 对标两地三核心这样的部署架构老师有什么举荐么？是一套 K8s 用 namespace 辨别好，还是各自搭建，优缺点老师能分享一下吗？ A4：一套的益处，治理老本比拟低，部署的业务能够间接基于地区标签进行打散部署。但会有较大的问题，比方两地三核心自身就跨地区的，网络品质的保障是个大问题。自身计划就须要能跨城市级的高可用，那单 K8s 集群的 ETCD 高可用怎么保障？如果真呈现城市级自然灾害，那就会导致你的 etcd 集群异样。自身的容灾计划还没起作用，可能就会呈现该 K8S 集群因为网络等因素导致的不稳固。 ...

前言公司在经验2019-2020年的疾速倒退后，业务的高速成长给运维基建带来了微小挑战，业务个性转变为大流量、高并发（千万级）。为保障业务稳固和平安，运维团队在架构上做了重大调整，从传统架构逐步演化成混合云架构，同时实现业务异地容灾、容器化、跨机房调度等。公司从2020年开始布局容器，到当初已落地150个我的项目，过程中遇到蕴含日志、监控、网络、CI/CD等版块问题，本篇文章将重点围绕日志版块进行具体论述。 一、背景每家公司在成长的过程中或多或少都会存在一些历史遗留问题，如： 业务资源使用率偏低公司每季度服务器资源投入老本微小业务突发资源扩缩容操作工夫过长以后Kvm虚拟化实现自动化整合难度大二、抉择K8S的起因容器化编排有K8S、Swarm、Mesos，近年K8S成为支流趋势，Swarm和Mesos曾经逐步小众化，因而咱们抉择了K8S作为编排。其领有以下长处，如： 弹性伸缩具备应突发、省老本、自动化的业务价值平台侧将各业务零散、闲置资源进行整合，造成一个大规模资源池，通过K8S弹性调度、库存管控技术在公司经营老本和业务体感中寻求较好的均衡api接口丰盛，易于融入自动化运维体系三、挑战难题之日志篇日志宏大，Pod适应于无状态的，而业务重日志是有状态的，如何保障数十T级别的日志平安稳固，运维团队面临着十分艰巨的挑战。日志大体上划分为三类： 业务日志，数十T/日级别归档日志，数十T/日级别入数仓日志，数十T/日级别 四、日志调研日志的采集形式分为被动采集和被动推送两种，在 K8S 中，被动采集个别分为 Sidecar 和 DaemonSet 两种形式，被动推送分为 DockerEngine 推送和业务直写两种形式： DockerEngine自身具备 LogDriver 性能，可通过配置不同的 LogDriver 将容器的 stdout 通过 DockerEngine 写入到远端存储，以此达到日志采集的目标。这种形式的可定制化、灵活性、资源隔离性都很低，个别不倡议在生产环境中应用 DaemonSet形式在每个 node 节点上只运行一个日志 agent，采集这个节点上所有的日志。DaemonSet 绝对资源占用要小很多，但扩展性、租户隔离性受限，比拟实用于性能繁多或业务不是很多的集群业务直写是在利用中集成日志采集的 SDK，通过 SDK 间接将日志发送到服务端。这种形式省去了落盘采集的逻辑，也不须要额定部署 Agent，对于零碎的资源耗费最低，但因为业务和日志 SDK强绑定，整体灵活性很低，个别只有日志量极大的场景中应用Sidecar形式为每个POD独自部署日志 agent，这个 agent 只负责一个业务利用的日志采集。Sidecar 绝对资源占用较多，但灵活性以及多租户隔离性较强，倡议大型的 K8S 集群或作为 PaaS 平台为多个业务方服务的集群应用该形式 总结下来： DockerEngine 直写个别不举荐业务直写举荐在日志量极大的场景中应用DaemonSet 个别在中小型集群中应用Sidecar 举荐在超大型的集群中应用具体的各种采集形式比照如下： 五、解决方案1.业务日志选型：为尽量减少业务开发的革新老本，容器化须要尽快推广，并抉择sidecar形式对业务日志进行采集，链路图如下： 整个架构的数据流承载每秒200万条数据，logstash集群主动按日期切割索引，再通过生命周期治理主动清理过期日志。 装置日志采集agent的yaml配置，采集蕴含容器namespace、pod ip、nodename等，辨别不同容器集群和不同环境。 2.归档日志&数仓日志归档日记和入数仓日志是咱们的外围数据，不仅须要很强的性能要求，而且日志的稳固和平安也很重要，开源的组件无奈满足需要，自研日志网关解决。 历史归档日志几十P甚至数百P时，在浩瀚的归档日志中查找到咱们须要的一小段日志是一件很艰巨的事，设计分布式集群日志网关，解决了诸多痛点：日志网关从多个维度记录了归档日志的索引信息，归档日志规范化，极大得升高了运维和业务对归档日志的时效性归档机存储主动平衡，解放了归档机存贮存满时运维手动迁徙数据时候的繁琐，缩小人力老本通过可视化平台融入自动化体系，对归档日志的查看和下载进行审计，安全性失去保障 六、总结在K8S落地后，公司已上线的业务线资源均匀使用率由历史的10%进步至40%，帮忙公司极大升高了服务器资源老本。但团队在落地和推广的过程中依然存在很多问题还没有解决，如： 容器外部无奈看到调配的内存和cpu核数容器的IOPS和IO Buffer的限度通容器平安隔离防护业务线老本资源和容器集群绑定....将来，运维团队将持续攻克K8S生产环境落地所面临的多重挑战及难题，后续将别离就“监控”、“网络”、“CI/CD”等话题继续分享， 敬请期待。

Indexer 笔记Indexer 是 client-go 自带索引的本地对象存储数据结构 type cache struct { // 并发平安存储 cacheStorage ThreadSafeStore // 依据资源对象计算出 key 值 keyFunc KeyFunc}type KeyFunc func(obj interface{}) (string, error)type threadSafeMap struct { lock sync.RWMutex // 存了 keyFunc => obj 的对应关系 items map[string]interface{} // 自定义的 index 办法 indexers Indexers // 索引器 indices Indices}type Indexers map[string]IndexFunctype Indices map[string]Indextype Index map[string]sets.Stringdemoc := cache.NewIndexer(cache.MetaNamespaceKeyFunc, cache.Indexers{"custom": func(obj interface{}) ([]string, error) { pod := obj.(*corev1.Secret) return []string{pod.Name, "qwer"}, nil}})c.Add(&corev1.Secret{ ObjectMeta: metav1.ObjectMeta{ Name: "secret1", Namespace: "duc", },})c.Add(&corev1.Secret{ ObjectMeta: metav1.ObjectMeta{ Name: "secret2", Namespace: "duc", },})pp.Println(c) ...

网上看了很多对于 informer 的文章以及流程图，感觉不全面，因而本人画了一张 Resync 机制Resync 开启后 event 操作须要幂等解决开启后会定时从本地 cache.store 同步数据，会触发 UpdateFunc，所以如果开启 resync 最好查看每次 ResourceVersion 是否发送变更，防止做不必要的操作。 初始化 informerFactory 的时候传入的 resyncPeriod 会因为每个 informer 的 AddEventHandlerWithResyncPeriod 操作而扭转，如果一开始传入的是 10s 同步一次，但前面退出一个须要 2s 同步一次的 event，informer的同步周期会变成 2s

作者：SRE运维博客 博客地址： https://www.cnsre.cn/ 文章地址：https://www.cnsre.cn/posts/211119132529/ 相干话题：https://www.cnsre.cn/tags/k3s/ 双十一薅了几个云厂商的羊毛，一开始搭建了k3s的单机版，前面就想着能不能搭建一个k3s集群，而后参考了这位大佬的文章，就试着用 WireGuard 来进行组网。它轻量、便捷、高效，而且数据全程加密传输，是依靠公网组建虚构局域网的优良抉择。 环境介绍服务器介绍 云厂商公网IP地址内网IP地址虚构网络IP地址操作系统内核版本腾讯云142.xx.xx.1210.0.16.8192.168.1.1CentOS Linux release 7.9.2009 (Core)5.15.2-1腾讯云2122.xx.xxx.11110.0.0.6192.168.1.2CentOS Linux release 7.9.2009 (Core)5.15.2-1阿里云122.xx.xx.155172.17.0.3192.168.1.3CentOS Linux release 7.9.2009 (Core)5.15.2-1搭建前筹备在搭建跨云的 k3s 集群前，咱们须要把 WireGuard 装置好，WireGuard 对内核是有要求的，所以内核曾经要降级到 5.15.2-1.el7.elrepo.x86_64 在所有节点开启 IP 地址转发： echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.confecho "net.ipv4.conf.all.proxy_arp = 1" >> /etc/sysctl.confsysctl -p /etc/sysctl.conf所有节点开启批改主机名称 # 腾讯云1执行hostnamectl set-hostname k3s-master# 腾讯云2执行hostnamectl set-hostname k3s-node1# 阿里云执行hostnamectl set-hostname k3s-node2降级内核几个服务器默认的内核都是 3.10 的，装置WireGuard 须要吧内核降级到比拟高的版本。 降级内核前先降级软件包（非必要） yum update -y增加 iptables 规定，容许本机的 NAT 转换： iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTiptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTiptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPTiptables -t nat -A POSTROUTING -s 192.168.1.1/24 -o eth0 -j MASQUERADE留神： ...

在MAC零碎中，从GitHub上下载代码，并尝试编译的过程中，呈现了编译谬误，根本都是找不到package这样的，例如： cannot find package "bufio" in any ofnon-static build: k8s.io/kubernetes/./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gentouch: _output/bin/prerelease-lifecycle-gen: No such file or directoryhack/make-rules/helpers/go2make/go2make.go:20:2: cannot find package "bytes" in any of问题剖析和修复go装置有问题老手在开始尝试Go编码研发的时候，还是要先搞清楚GoPATH，GOROOT，以及相干环境变量配置，相干Go的操作命令的区别，否则就会踩到一些搞不懂的坑。 GOROOT，能够了解为是go程序包的装置目录，这外面蕴含了Go的运行时命令，比方bin目录，以及局部零碎类库，比方srcGOPATH, 了解为GO的默认工作空间GO的官方网站上有安装包，然而这些安装包也是有区别的： Source,这种解压下来只有源码，没有bin命令Archive ，这种蕴含源码和BinInstaller，这种最简略，傻瓜式装置，蕴含源码和Bin不想麻烦的话，应用傻瓜式装置最简略。 GOBIN带来的问题GOROOT 和GOPATH 设置好之后，大部分的问题曾经解决了，然而还有一个疑难问题： kubernetes make+++ [1119 09:50:12] Building go targets for darwin/amd64: ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen> non-static build: k8s.io/kubernetes/./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gentouch: _output/bin/prerelease-lifecycle-gen: No such file or directorymake[1]: *** [_output/bin/prerelease-lifecycle-gen] Error 1make: *** [generated_files] Error 2GitHub上有人解答了这个问题。 short answer: go env -w GOBIN=k8s will install binary to GOBIN if it is not empty, but k8s try to find prerelease-lifecycle-gen under _output/bin修复办法就是清空GOBIN，起因是说，如果有GOBIN的话，k8s会向GOBIN的目录下写入二进制文件，然而他会在_output/bin下找 ...

应用 nfs 文件系统 实现kubernetes存储动静挂载 1. 装置服务端和客户端 root@hello:~# apt install nfs-kernel-server nfs-common其中 nfs-kernel-server 为服务端，　nfs-common 为客户端。 2. 配置 nfs 共享目录 root@hello:~# mkdir /nfsroot@hello:~# sudo vim /etc/exports/nfs *(rw,sync,no_root_squash,no_subtree_check)各字段解析如下：/nfs: 要共享的目录：指定能够访问共享目录的用户 ip, * 代表所有用户。192.168.3.　指定网段。192.168.3.29 指定 ip。rw：可读可写。如果想要只读的话，能够指定 ro。sync：文件同步写入到内存与硬盘中。async：文件会先暂存于内存中，而非间接写入硬盘。no_root_squash：登入 nfs 主机应用分享目录的使用者，如果是 root 的话，那么对于这个分享的目录来说，他就具备 root 的权限！这个我的项目『极不平安』，不倡议应用！但如果你须要在客户端对 nfs 目录进行写入操作。你就得配置 no_root_squash。不便与平安不可兼得。root_squash：在登入 nfs 主机应用分享之目录的使用者如果是 root 时，那么这个使用者的权限将被压缩成为匿名使用者，通常他的 UID 与 GID 都会变成 nobody 那个零碎账号的身份。subtree_check：强制 nfs 查看父目录的权限（默认）no_subtree_check：不查看父目录权限配置实现后，执行以下命令导出共享目录，并重启 nfs 服务: root@hello:~# exportfs -a root@hello:~# systemctl restart nfs-kernel-serverroot@hello:~#root@hello:~# systemctl enable nfs-kernel-server客户端挂载 root@hello:~# apt install nfs-commonroot@hello:~# mkdir -p /nfs/root@hello:~# mount -t nfs 192.168.1.66:/nfs/ /nfs/root@hello:~# df -hTFilesystem Type Size Used Avail Use% Mounted onudev devtmpfs 7.8G 0 7.8G 0% /devtmpfs tmpfs 1.6G 2.9M 1.6G 1% /run/dev/mapper/ubuntu--vg-ubuntu--lv ext4 97G 9.9G 83G 11% /tmpfs tmpfs 7.9G 0 7.9G 0% /dev/shmtmpfs tmpfs 5.0M 0 5.0M 0% /run/locktmpfs tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup/dev/loop0 squashfs 56M 56M 0 100% /snap/core18/2128/dev/loop1 squashfs 56M 56M 0 100% /snap/core18/2246/dev/loop3 squashfs 33M 33M 0 100% /snap/snapd/12704/dev/loop2 squashfs 62M 62M 0 100% /snap/core20/1169/dev/loop4 squashfs 33M 33M 0 100% /snap/snapd/13640/dev/loop6 squashfs 68M 68M 0 100% /snap/lxd/21835/dev/loop5 squashfs 71M 71M 0 100% /snap/lxd/21029/dev/sda2 ext4 976M 107M 803M 12% /boottmpfs tmpfs 1.6G 0 1.6G 0% /run/user/0192.168.1.66:/nfs nfs4 97G 6.4G 86G 7% /nfs创立配置默认存储 ...

介绍 大多数状况下，单主节点集群大抵足以供开发和测试环境应用。然而，对于生产环境，您须要思考集群的高可用性。如果要害组件（例如 kube-apiserver、kube-scheduler 和 kube-controller-manager）都在同一个主节点上运行，一旦主节点宕机，Kubernetes 和 KubeSphere 都将不可用。因而，您须要为多个主节点配置负载均衡器，以创立高可用集群。您能够应用任意云负载均衡器或者任意硬件负载均衡器（例如 F5）。此外，也能够应用 Keepalived 和 HAproxy，或者 Nginx 来创立高可用集群。 架构 在您开始操作前，请确保筹备了 6 台 Linux 机器，其中 3 台充当主节点，另外 3 台充当工作节点。下图展现了这些机器的详情，包含它们的公有 IP 地址和角色。 配置负载均衡器 您必须在您的环境中创立一个负载均衡器来监听（在某些云平台也称作监听器）要害端口。倡议监听下表中的端口。 服务  协定  端口 apiserver TCP 6443 ks-console  TCP 30880 http  TCP 80 https TCP 443 配置免密 root@hello:~# ssh-keygenroot@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.10root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.11 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.12 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.13 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.14 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.15 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.16 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.51 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.52 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.53 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.54 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.55 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.56 root@hello:~# ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.57下载 KubeKey ...

疾速搭建Kubeless平台Kubeless简介Kubeless是基于Kubernetes的原生无服务器框架。其容许用户部署大量的代码（函数），而无须放心底层架构。它被部署在Kubernetes集群之上，并充分利用Kubernetes的个性及资源类型，能够克隆AWS Lambda、Azure Functions、Google Cloud Functions上的内容。Kubeless次要特点能够总结为以下几个方面。 反对Python、Node.js、Ruby、PHP、Go、.NET、Ballerina语言编写和自定义运行时。Kubeless CLI合乎AWS Lambda CLI。事件触发器应用Kafka音讯零碎和HTTP触发器。Prometheus默认监督函数的调用和延时。反对Serverless框架插件。因为Kubeless的性能个性是建设在Kubernetes之上的，因而对于相熟Kubernetes的人来说非常容易部署Kubeless。其次要实现是将用户编写的函数在Kubernetes中转变为CRD（Custom Resource Definition，自定义资源），并以容器的形式运行在集群中。 Kubeless部署在已有的Kubernetes集群上进行Kubeless服务的创立： export RELEASE=$(curl -s >https://api.github.com/repos/kubeless/kubeless/releases/ latest | grep tag_name | cut -d '"' -f 4)kubectl create ns kubelesskubectl create -f [https://github.com/kubeless/k...$RELEASE/](https://github.com/kubeless/kubeless/releases/download/$RELEASE/) kubeless-$RELEASE.yaml创立胜利后如图5-27所示。 图5-27　装置和配置Kubeless 查看根本信息： kubectl get pods -n kubeless相干Pod信息如图5-28所示。 图5-28　查看Kubeless相干Pod 查看Deployment信息： kubectl get deployment -n kubeless其相干信息如图5-29所示。图5-29　查看Kubeless Deployment相干信息 查看customresourcedefinition信息： kubectl get customresourcedefinition其相干信息如图5-30所示。图5-30　查看customresourcedefinition信息 下载命令行工具下载Kubeless工具，并解压： export OS=$(uname -s| tr '[:upper:]' '[:lower:]')curl -OL [https://github.com/kubeless/k...$RELEASE/kubeless_](https://github.com/kubeless/kubeless/releases/download/$RELEASE/kubeless_) $OS-amd64.zipunzip kubeless_$OS-amd64.zip 解压之后查看： ./bundles/kubeless_linux-amd64/kubeless具体如图5-31所示。图5-31　应用Kubeless命令行工具 ...

- 作者：SRE运维博客 博客地址： https://www.cnsre.cn/ 文章地址：https://www.cnsre.cn/posts/211109907029/ 相干话题：https://www.cnsre.cn/tags/k3s/ -双十一各大云厂商纷纷撒种子种韭菜（抢用户），良心云 也是判若两人的良心，新用户更是通过某宝 148 就能够买到三年 2C4G8M 的轻量应用服务器。于是我也发售薅了羊毛动手了一台。然而对于各种组件自身就对资源耗费比拟大的 k8s 来说，跑起来还是有点费劲的，于是我打算将这台实例部署一台轻量级的 Kubernetes: k3sk8s VS k3sk3s 是 Rancher 推出的轻量级 k8s。k3s 自身蕴含了 k8s 的源码，而二进制包却只有 60M 然而实质上和 k8s 没有区别。但为了升高资源占用，k3s 和 k8s 还是有一些区别的，次要是： 应用了相比 Docker 更轻量的 containerd 作为容器运行时（Docker 并不是惟一的容器抉择）。去掉了 k8s 的 Legacy, alpha, non-default features。用 sqlite3 作为默认的存储，而不是 etcd。其余的一些优化，最终 k3s 只是一个 binary 文件，十分易于部署。、所以 k3s 实用于边缘计算，IoT 等资源缓和的场景。同时 k3s 也是非常容易部署的，官网上提供了一键部署的脚本。 k3s的长处k3s将装置Kubernetes所需的所有打包进仅有60MB大小的二进制文件中，并且齐全实现了Kubernetes API。为了缩小运行Kubernetes所需的内存，Rancher删除了很多不必要的驱动程序，并用附加组件对其进行替换。k3s是一款齐全通过CNCF认证的Kubernetes发行版，这意味着你能够编写YAML来对完整版的Kubernetes进行操作，并且它们也将实用于k3s集群。因为它只须要极低的资源就能够运行，因而它可能在任何512MB RAM以上的设施上运行集群，换言之，咱们能够让pod在master和节点上运行。k3s的毛病首先，以后k3s的版本（k3s v0.8.1）仅能运行单个master，这意味着如果你的master宕机，那么你就无奈治理你的集群，即使已有集群要持续运行。然而在k3s v0.10的版本中，多主模式曾经是试验性功能，兴许在下一个版本中可能GA。其次，在单个master的k3s中，默认的数据存储是SQLite，这对于小型数据库非常敌对，然而如果蒙受重击，那么SQLite将成为次要痛点。然而，Kubernetes管制立体中产生的更改更多是与频繁更新部署、调度Pod等无关，因而对于小型开发/测试集群而言，数据库不会造成太大负载。论断K8s和k3s各有优劣，应用场景也有所区别，因而不能一概而论。如果你要进行大型的集群部署，那么我倡议你抉择应用K8s； 如果你像我一样只是为了开发或者测试，那么抉择k3s则是性价比更高的抉择。 装置 k3s确保你是一台洁净的 CentOS7 服务器。依照常规先更新,更新前顺便把源换为国内的yum源。 # 改国内yum源curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repocurl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo# 更新yum update -y批改主机名 ...

背景flink服务用作测试的时候，可能两头会因为谬误宕机，此时宕机的机会并不通晓；而后当咱们宕机的时候数据又会失落，所以为了咱们便于排查日志，须要将k8s容器组的数据长久化到集群各个节点的目录下。k8s的存储介绍参考: k8s的存储Volume 内容1.服务配置挂载日志咱们这里设置存储卷类型为:【存储卷申明】-他能够在每一个集群节点之间进行挂载门路创立,当宕机重启之后就会从对应的磁盘从新拉取数据。 2.k8s查看存储卷【集群治理】->【存储】->【存储卷】【查看】 3.宿主机查看咱们进入宿主机,查看对应的磁盘下文件:

Ubuntu下装置命令 root@master1:~# apt install -y bash-completionReading package lists... DoneBuilding dependency tree Reading state information... Donebash-completion is already the newest version (1:2.10-1ubuntu1).0 upgraded, 0 newly installed, 0 to remove and 29 not upgraded.centos下装置命令 [root@dss ~]# yum install bash-completion -yLoaded plugins: fastestmirror, langpacksLoading mirror speeds from cached hostfile * epel: mirrors.tuna.tsinghua.edu.cnPackage 1:bash-completion-2.1-8.el7.noarch already installed and latest versionNothing to do[root@dss ~]#root@master1:~# locate bash_completion/etc/bash_completion/etc/bash_completion.d/etc/bash_completion.d/apport_completion/etc/bash_completion.d/git-prompt/etc/profile.d/bash_completion.sh/snap/core18/2128/etc/bash_completion/snap/core18/2128/usr/share/bash-completion/bash_completion/snap/core18/2128/usr/share/doc/bash/README.md.bash_completion.gz/snap/core18/2128/usr/share/perl5/Debian/Debhelper/Sequence/bash_completion.pm/snap/lxd/21029/etc/bash_completion.d/snap/lxd/21029/etc/bash_completion.d/snap.lxd.lxc/usr/share/bash-completion/bash_completion/usr/share/doc/bash/README.md.bash_completion.gz/usr/share/perl5/Debian/Debhelper/Sequence/bash_completion.pm/var/lib/docker/overlay2/0f27e9d2ca7fbe8a3b764a525f1c58990345512fa6dfe4162aba3e05ccff5b56/diff/etc/bash_completion.d/var/lib/docker/overlay2/5eb1b0cb946881e1081bfa7a608b6fa85dbf2cb7e67f84b038f3b8a85bd13196/diff/usr/local/lib/node_modules/npm/node_modules/dashdash/etc/dashdash.bash_completion.in/var/lib/docker/overlay2/76c41c1d1eb6eaa7b9259bd822a4bffebf180717a24319d2ffec3b4dcae0e66a/merged/etc/bash_completion.d/var/lib/docker/overlay2/78b8ab76c0e0ad7ee873daab9ab3987a366ec32fda68a4bb56a218c7f8806a58/merged/etc/profile.d/bash_completion.sh/var/lib/docker/overlay2/78b8ab76c0e0ad7ee873daab9ab3987a366ec32fda68a4bb56a218c7f8806a58/merged/usr/share/bash-completion/bash_completion/var/lib/docker/overlay2/802133f75f62596a2c173f1b57231efbe210eddd7a43770a62ca94c86ce2ca56/merged/usr/local/lib/node_modules/npm/node_modules/dashdash/etc/dashdash.bash_completion.in/var/lib/docker/overlay2/ee672bdd0bf0fdf590f9234a8a784ca12c262c47a0ac8ab91acc0942dfafc339/diff/etc/profile.d/bash_completion.sh/var/lib/docker/overlay2/ee672bdd0bf0fdf590f9234a8a784ca12c262c47a0ac8ab91acc0942dfafc339/diff/usr/share/bash-completion/bash_completion长期环境变量 root@master1:~# source /usr/share/bash-completion/bash_completionroot@master1:~# source <(kubectl completion bash)root@master1:~#root@master1:~#root@master1:~# kubectlannotate auth config delete exec kustomize plugin run uncordonapi-resources autoscale cordon describe explain label port-forward scale versionapi-versions certificate cp diff expose logs proxy set waitapply cluster-info create drain get options replace taint attach completion debug edit help patch rollout top root@master1:~# kubectl永恒写入环境变量配置文件 ...

景象采集端采集数据之后,输入零碎发现零碎数据查问不到,排查问题之后发现是接入问题跟治理问题:1、接入问题接入的数据如果须要做文件上传的话,须要将其上传到mysql做解决,接入零碎跟mysql之间因为网络问题,不能间接交互。两头应用了一个dataMaster做转发。然而转发时候接入零碎拉取到一批数据之后,比方100条,除了上报拉取数据记录之外。还须要将一条条数据通过dataMaster转发而后保留到mysql。期间呈现局部数据写入失败的状况。2、治理零碎治理零碎数据始终在生产kafka主题数据，然而发现数据存在积压:如下: 而后查看flink治理程序时候,呈现了背压:如下: 阐明算法解决不及时,导致数据处理不过去。 解决方案k8s服务部署日志查问python数据统计统计后果校验

Web 界面 (Dashboard) Dashboard 是基于网页的 Kubernetes 用户界面。你能够应用 Dashboard 将容器利用部署到 Kubernetes 集群中，也能够对容器利用排错，还能治理集群资源。你能够应用 Dashboard 获取运行在集群中的利用的概览信息，也能够创立或者批改 Kubernetes 资源 （如 Deployment，Job，DaemonSet 等等）。例如，你能够对 Deployment 实现弹性伸缩、发动滚动降级、重启 Pod 或者应用向导创立新的利用。 Dashboard 同时展现了 Kubernetes 集群中的资源状态信息和所有报错信息。 kubernetes官网提供的可视化界面 https://github.com/kubernetes... 一键执行 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml先下载后执行 root@master1:~/dashboard# wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yamlroot@master1:~/dashboard# kubectl apply -f recommended.yaml若下载不下来，能够应用vim增加进去后再次执行 root@master1:~/dashboard# vim recommended.yamlroot@master1:~/dashboard# root@master1:~/dashboard# root@master1:~/dashboard# cat recommended.yaml# Copyright 2017 The Kubernetes Authors.## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at## http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.apiVersion: v1kind: Namespacemetadata: name: kubernetes-dashboard---apiVersion: v1kind: ServiceAccountmetadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboard---kind: ServiceapiVersion: v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboardspec: ports: - port: 443 targetPort: 8443 selector: k8s-app: kubernetes-dashboard---apiVersion: v1kind: Secretmetadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard-certs namespace: kubernetes-dashboardtype: Opaque---apiVersion: v1kind: Secretmetadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard-csrf namespace: kubernetes-dashboardtype: Opaquedata: csrf: ""---apiVersion: v1kind: Secretmetadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard-key-holder namespace: kubernetes-dashboardtype: Opaque---kind: ConfigMapapiVersion: v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard-settings namespace: kubernetes-dashboard---kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboardrules: # Allow Dashboard to get, update and delete Dashboard exclusive secrets. - apiGroups: [""] resources: ["secrets"] resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs", "kubernetes-dashboard-csrf"] verbs: ["get", "update", "delete"] # Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map. - apiGroups: [""] resources: ["configmaps"] resourceNames: ["kubernetes-dashboard-settings"] verbs: ["get", "update"] # Allow Dashboard to get metrics. - apiGroups: [""] resources: ["services"] resourceNames: ["heapster", "dashboard-metrics-scraper"] verbs: ["proxy"] - apiGroups: [""] resources: ["services/proxy"] resourceNames: ["heapster", "http:heapster:", "https:heapster:", "dashboard-metrics-scraper", "http:dashboard-metrics-scraper"] verbs: ["get"]---kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboardrules: # Allow Metrics Scraper to get metrics from the Metrics server - apiGroups: ["metrics.k8s.io"] resources: ["pods", "nodes"] verbs: ["get", "list", "watch"]---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kubernetes-dashboardsubjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kubernetes-dashboardsubjects: - kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard---kind: DeploymentapiVersion: apps/v1metadata: labels: k8s-app: kubernetes-dashboard name: kubernetes-dashboard namespace: kubernetes-dashboardspec: replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: k8s-app: kubernetes-dashboard template: metadata: labels: k8s-app: kubernetes-dashboard spec: containers: - name: kubernetes-dashboard image: kubernetesui/dashboard:v2.4.0 imagePullPolicy: Always ports: - containerPort: 8443 protocol: TCP args: - --auto-generate-certificates - --namespace=kubernetes-dashboard # Uncomment the following line to manually specify Kubernetes API server Host # If not specified, Dashboard will attempt to auto discover the API server and connect # to it. Uncomment only if the default does not work. # - --apiserver-host=http://my-address:port volumeMounts: - name: kubernetes-dashboard-certs mountPath: /certs # Create on-disk volume to store exec logs - mountPath: /tmp name: tmp-volume livenessProbe: httpGet: scheme: HTTPS path: / port: 8443 initialDelaySeconds: 30 timeoutSeconds: 30 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsUser: 1001 runAsGroup: 2001 volumes: - name: kubernetes-dashboard-certs secret: secretName: kubernetes-dashboard-certs - name: tmp-volume emptyDir: {} serviceAccountName: kubernetes-dashboard nodeSelector: "kubernetes.io/os": linux # Comment the following tolerations if Dashboard must not be deployed on master tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule---kind: ServiceapiVersion: v1metadata: labels: k8s-app: dashboard-metrics-scraper name: dashboard-metrics-scraper namespace: kubernetes-dashboardspec: ports: - port: 8000 targetPort: 8000 selector: k8s-app: dashboard-metrics-scraper---kind: DeploymentapiVersion: apps/v1metadata: labels: k8s-app: dashboard-metrics-scraper name: dashboard-metrics-scraper namespace: kubernetes-dashboardspec: replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: k8s-app: dashboard-metrics-scraper template: metadata: labels: k8s-app: dashboard-metrics-scraper spec: securityContext: seccompProfile: type: RuntimeDefault containers: - name: dashboard-metrics-scraper image: kubernetesui/metrics-scraper:v1.0.7 ports: - containerPort: 8000 protocol: TCP livenessProbe: httpGet: scheme: HTTP path: / port: 8000 initialDelaySeconds: 30 timeoutSeconds: 30 volumeMounts: - mountPath: /tmp name: tmp-volume securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsUser: 1001 runAsGroup: 2001 serviceAccountName: kubernetes-dashboard nodeSelector: "kubernetes.io/os": linux # Comment the following tolerations if Dashboard must not be deployed on master tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule volumes: - name: tmp-volume emptyDir: {}root@master1:~/dashboard# root@master1:~/dashboard# kubectl apply -f recommended.yaml 查看是否在运行root@master1:~/dashboard# kubectl get pod -n kubernetes-dashboardNAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-c45b7869d-2xhx8 1/1 Running 0 2m40skubernetes-dashboard-576cb95f94-scrxw 1/1 Running 0 2m40sroot@master1:~/dashboard# 批改为nodeIProot@master1:~/dashboard# kubectl edit svc kubernetes-dashboard -n kubernetes-dashboardservice/kubernetes-dashboard edited创立拜访账号 ...

通过如下几步能够将本人的go利用部署到k8s上 首先生成本人的go我的项目 mkdir srccd srcgo mod init servertest编写测试代码main.go内容如下，很简略 package mainimport ( "github.com/gin-gonic/gin" "fmt" "time" "net/http")type getTimeResp struct { CTime string}func getTimeHandler(ctx *gin.Context) { content := fmt.Sprintf("%d", time.Now().Nanosecond()) fmt.Printf("%s\n", content) resp := &getTimeResp{ CTime:content, } ctx.JSON(http.StatusOK, resp)}func main() { r := gin.Default() r.GET("/gettime", getTimeHandler) r.Run(":8000")}编写Dockerfile内容如下 FROM golang:1.17.1-alpine as builderENV GOPROXY=https://goproxy.cnWORKDIR /buildCOPY ./src .RUN mkdir /appRUN go mod tidyRUN go build FROM alpine:latestRUN mkdir -p /cmdWORKDIR /cmdCOPY --from=builder /build/servertest .EXPOSE 8000CMD ["./servertest"]生成镜像，执行命令 ...

这所有的所有仅在这里kube-prometheus和prometheus-operator史诗级教程prometheus-guidebook git仓库地址guidebook仓库地址kube-prometheus解决了哪些问题 一键化部署k8s-prometheus中的所有组件简单的k8s采集主动生成内置了很多alert和record rule，业余的promql，不必咱们本人写了多级嵌套的record计算如apiserver的slo应用 Prometheus Operator 框架及其自定义资源，使指标的接入能够由业务方自行配置，无需监控管理员染指kube-prometheus采集难点 kube-prometheus内置的k8s采集工作都采集了什么 怎么采集到了为什么要采集这些用了哪些优化伎俩kube-prometheus内置的grafana-dashboard看图剖析难点 内置的grafana-dashboard看图都蕴含什么图表 为什么要设置这些图表6层slo预聚合到底怎么做的动静dashboard怎么实现的kube-prometheus内置的告警和预聚合剖析，6层预聚合slo原理 内置的告警蕴含哪些规定怎么配置下来的apiserver6层slo预聚合到底怎么做的我怎么去自定义规定kube-rbac 鉴权是干什么的为什么要加着一层和envoy我的项目什么关系如果代理upstream的流量怎么把我自定义的指标利用到prometheus-operator中 如何用go编写我的项目部署到k8s的pod中prometheus原始的k8s_pod_sd怎么采集自定义指标怎么应用serviceMonitor形式接入如何利用阿里云构建国外的镜像 为何要敞开代码缓存这所有的所有仅在这里kube-prometheus和prometheus-operator史诗级教程

1. 概述进入 K8s 的世界，会发现有很多的 Controller，它们都是为了实现某类资源(如 pod 是通过 DeploymentController, ReplicaSetController 进行治理)的调谐，指标是放弃用户冀望的状态。 K8s 中有几十种类型的资源，如何能让 K8s 外部以及内部用户不便、高效的获取某类资源的变动，就是本文 Informer 要实现的。本文将从 Reflector(反射器)、DeletaFIFO(增量队列)、Indexer(索引器)、Controller(控制器)、SharedInformer(共享资源告诉器)、processorListener(事件监听处理器)、workqueue(事件处理工作队列) 等方面进行解析。 本文及后续相干文章都基于 K8s v1.22 2. 从 Reflector 说起Reflector 的主要职责是从 apiserver 拉取并继续监听(ListAndWatch) 相干资源类型的增删改(Add/Update/Delete)事件，存储在由 DeltaFIFO 实现的本地缓存(local Store) 中。 首先看一下 Reflector 构造体定义： // staging/src/k8s.io/client-go/tools/cache/reflector.gotype Reflector struct { // 通过 file:line 惟一标识的 name name string // 上面三个为了确认类型 expectedTypeName string expectedType reflect.Type expectedGVK *schema.GroupVersionKind // 存储 interface: 具体由 DeltaFIFO 实现存储 store Store // 用来从 apiserver 拉取全量和增量资源 listerWatcher ListerWatcher // 上面两个用来做失败重试 backoffManager wait.BackoffManager initConnBackoffManager wait.BackoffManager // informer 使用者从新同步的周期 resyncPeriod time.Duration // 判断是否满足能够从新同步的条件 ShouldResync func() bool clock clock.Clock // 是否要进行分页 List paginatedResult bool // 最初同步的资源版本号，以此为根据，watch 只会监听大于此值的资源 lastSyncResourceVersion string // 最初同步的资源版本号是否可用 isLastSyncResourceVersionUnavailable bool // 加把锁管制版本号 lastSyncResourceVersionMutex sync.RWMutex // 每页大小 WatchListPageSize int64 // watch 失败回调 handler watchErrorHandler WatchErrorHandler}从构造体定义能够看到，通过指定指标资源类型进行 ListAndWatch，并可进行分页相干设置。 ...

摘要：最近要做一个将K8s中的某组件UI通过反向代理映射到自定义规定的链接地址上，提供给用户拜访的需要。所以顺便钻研了一下Jetty的ProxyServlet。本文分享自华为云社区《Jetty自定义ProxyServlet实现反向代理服务（含源码剖析）》，作者： 小焱 。 一、背景概述最近要做一个将K8s中的某组件UI通过反向代理映射到自定义规定的链接地址上，提供给用户拜访的需要。所以顺便钻研了一下Jetty的ProxyServlet。在这里做一下剖析，如果有了解不到位的还心愿能够补充斧正。 二、Jetty 的根本架构Jetty 是一个Servlet 引擎，它的架构比较简单，也是一个可扩展性和非常灵活的应用服务器，它有一个根本数据模型，这个数据模型就是 Handler，所有能够被扩大的组件都能够作为一个 Handler，增加到 Server 中，Jetty 就是帮你治理这些 Handler。 整个 Jetty 的外围组件由 Server 和 Connector 两个组件形成，整个 Server 组件是基于 Handler 容器工作的，Jetty 中另外一个比不可少的组件是 Connector，它负责承受客户端的连贯申请，并将申请调配给一个解决队列去执行。Jetty 中还有一些可有可无的组件，咱们能够在它上做扩大。如 JMX，咱们能够定义一些 Mbean 把它加到 Server 中，当 Server 启动的时候，这些 Bean 就会一起工作。 整个 Jetty 的外围是围绕着 Server 类来构建，Server 类继承了 Handler，关联了 Connector 和 Container。Container 是治理 Mbean 的容器。Jetty 的 Server 的扩大次要是实现一个个 Handler 并将 Handler 加到 Server 中，Server 中提供了调用这些 Handler 的拜访规定。整个 Jetty 的所有组件的生命周期治理是基于观察者模板设计，实现LifeCycle。 三、Handler 的体系结构Jetty 次要是基于 Handler 来设计的，Handler 的体系结构影响着整个 Jetty 的方方面面。上面总结了一下 Handler 的品种及作用： ...

作者：石义峰 起源：恒生LIGHT云社区 装置部署神器-KubeadmKubeadm 是一个提供了 kubeadm init 和 kubeadm join 的工具， 作为创立 Kubernetes 集群的 “快捷路径” 的最佳实际。 kubeadm 通过执行必要的操作来启动和运行最小可用集群。 依照设计，它只关注启动疏导，而非配置机器。同样的， 装置各种 “精益求精” 的扩大，例如 Kubernetes Dashboard、 监控计划、以及特定云平台的扩大，都不在探讨范畴内。 相同，咱们心愿在 kubeadm 之上构建更高级别以及更加合规的工具， 现实状况下，应用 kubeadm 作为所有部署工作的基准将会更加易于创立一致性集群。 如何装置要装置 kubeadm, 请参照 【零根底入门云原生-k8s，轻松实战】k8s实际——装置配置及运行. kubeadm常用命令kubeadm init 初始搭建管制立体节点 [kubeadm join]() 搭建工作节点并将其退出到集群中 [kubeadm upgrade]() 降级 Kubernetes 集群到新版本 [kubeadm config]() 配置集群命令。如果应用 v1.7.x 或更低版本的 kubeadm ，初始化集群时则应用 kubeadm upgrade 来配置你的集群 [kubeadm token]() 用于治理 kubeadm join 应用的令牌 [kubeadm reset]() 用于复原/回滚通过 kubeadm init 或者 kubeadm join 命令对节点进行的任何变更 ...

在理解virtual-Kubelet之前，咱们先理解下什么是Kubelet。Kubelet 是在每个Node节点上运行的次要 “节点代理”。在Kubernetes集群中每个节点都会启动一个kubelet过程，kubelet基于PodSpec来工作。每个Pod Spec是一个形容Pod的YAML或JSON对象。Kubelet承受通过各种机制（次要是通过Apiserver）提供的一组Pod Spec，并确保这些Pod Spec中形容的容器处于运行状态且运行状况良好。同时Kubelet还通过cAdvisor监控容器和节点资源，定期向上报以后节点的衰弱状态以及资源应用状况，能够把Kubelet了解成[Server-Agent]架构中的Agent。Virtual-Kubelet是基于Kubelet的典型个性实现，向上伪装成Kubelet，从而模拟出Node对象，对接Kubernetes的原生资源对象；向下提供API，可对接其余资源管理平台提供的Provider。不同的平台通过实现Virtual-Kubelet定义的办法，容许节点由其对应的Provider提供(如ACI，AWS Fargate，IoT Edge，Tensile Kube等)反对，实现Serverless，或者将其扩大到如Docker Swarm、Openstack Zun等容器平台中，也能够通过Provider纳管其余Kubernetes集群，甚至是原生的IaaS层平台(VMware、zstack、openstack)。最好的形容是Kubernetes API on top，programmable back。Virtual-Kubelet如何治理虚拟机是本文探讨重点。Virutal-Kubelet的架构Virtual-Kubelet 模仿了Node资源对象，并负责对Pod调度到Virtual-Kubelet假装的虚构节点之后，对Pod进行生命周期治理。以后反对原生Kubernetes个性：创立，删除和更新PodContainer的日志，治理和监控获取单个Pod或多个Pod状态节点地址，节点容量，节点守护程序端点治理操作系统携带公有虚构网络Virtual-Kubelet如何治理虚拟机？虚拟机生命周期治理Virtual-Kubelet在虚拟机调度和操作方面能够复用Kubernetes原生的资源对象，但Pod在Kubelet治理下的生命周期仅存在创立、运行和销毁，理论对于虚拟机的开关机、备份和迁徙等操作无奈实现映射关系，因而对于简单的生命周期治理，须要通过自定义CRD形式反对不同类型的IaaS平台，每一个VM-CR对应一个IaaS层VM实例。对于VM-CR操作次要能够分为两类：对VM运行状态变更创立和销毁：能够对应一个VM-CR的create/deleteVM启停操作对应VM-CR replicas数量的变更:开机0→1关机1→0VM规格变更：批改VM-CR Spec资源定义kubectl logs/exec VM-pod：实现对Pod的拜访对VM进行备份/迁徙VM备份采纳创立对应Backup-Job对象，通过与VM-CR实例pod亲和形式，将Backup-Job调度置VM理论节点所运行的Virtual-Kubelet节点上，备份状态与Job执行状态统一VM迁徙采纳Kubernetes原生的节点调度形式，IaaS平台每一个负载VM的物理机对应一个Kubernetes集群内的Virtual-Kubelet，VM-CR实例Pod的调度由Kubernetes管制面治理虚拟机存储管理因为Virtual-Kubelet中Pod仅作为逻辑概念，IaaS层存储无奈与Kubernetes集群专用，但可形象为Kubernetes原生定义的PV/PVC，PV的access mode能力依赖IaaS层能力，并须要实现对应平台和底层存储的Provider和Provisioner。Virtual-Kubelet如何实现容器与虚拟机交互容器和虚拟机互通Virtual-Kubelet对应的Node会上报节点上Pod的Endpoint，假设Kubernetes集群和IaaS层平台部署在同一个二层网络下，则集群内容器Pod能够拜访VM-Pod，但容器Pod对于VM-Pod不可见；针对上一点能够通过Macvlan等网络插件，将容器-Pod，降维至二层网络上，实现容器-Pod和虚拟机互通，有肯定硬件要求。如何实现一套集群下虚拟机与容器的混合调度与资源隔离Virtual-Kubelet提供的是一个虚构节点用来向Kubernetes上报Node对象和Pod的状态和资源状况，虚拟机资源和集群内节点资源齐全隔离；在引入Virtual-Kubelet的状况下，须要对Virtual-Kubelet节点配置Taint和Tolerations，保障容器-Pod和VM-Pod调度拆散。服务发现Virtual-Kubelet，通过Provider实现的API将IaaS层VM信息形象成对应Pod对象的信息的形式来上报Endpoints，能够通过给CR增加no selector Service，待VM-Pod拉起后补充address至对应的Service。Virutal-Kubelet实用场景实用场景Virtual-Kuberlet适宜在已有IaaS层治理平台和Kubernetes集群环境下进行二者的买通，实现在Kubernetes集群上对立治理容器和非容器平台，同时因为Virtual-Kubelet在Serverless和纳管其余已有容器平台(Openstack Zun，Docker Swarm)方面也具备很高适配性，Virtual-Kubelet能够提供一套对立的API，不便开发者买通全流程。Virtual-Kubelet的优缺点长处一个开源的Kubelet实现，应用Kubernetes源语，使构建、部署更简略提供Kubelet典型个性接口，Provider仅需实现对应服务治理平台资源到Node和Pod对象个性的实现，不须要思考如何拜访Kubernetes灵活性高，Severless实际、对接现有容器平台、对接现有IaaS平台均有肯定前景Virtual-Kubelet设计将virtual-kubelet和Provider高度拆散，Virtual-Kubelet使对于异构服务平台具备很高的兼容性(不同架构如：ARM、S390x，不同CRI如：Kata、PodMan)，不光是能够纳关IaaS平台对于其余Kubernetes集群也能够实现治理毛病将非集群内资源形象成Node和Pod对象对资源应用上有肯定局限性，很难提供超出原有kubelet和IaaS平台能力领域，IaaS深度整合须要自行实现CRD仅能作为转换器，用于容器和虚拟机对立治理时还是须要依靠已有的平台能力，无奈像Kubevirt等计划作为一个独自的Iaas治理平台应用Virtual-Kubelet开发及部署开发自定义的ProviderVirtual-Kubelet我的项目自身并不提供Provider,而是提供一系列定义Kubelet典型操作的接口，开发者须要依据利用场景实现对应的Provider。使Kubernetes能够进行按需和简直即时的Container的计算、调度，而无需治理VM根底构造，同时仍可利用可移植的KubernetesAPI。实现遵循以下三个准则：提供必要的后端管道(back-end plumbing)，以在Kubernetes的Context中反对Pods，Containers和相干资源的的生命周期治理合乎Virtual-Kubelet以后提供的API没有拜访Kubernetes APIServer的权限，通过实现具备定义良好的回调机制来获取Secrets或Configmap之类的数据创立一个新的Provider次要须要通过调用Virtual-Kubelet提供的库实现如下三个接口：PodLifecylceHandler：用于Pod生命周期的治理type PodLifecycleHandler interface { // CreatePod takes a Kubernetes Pod and deploys it within the provider.CreatePod(ctx context.Context, pod *corev1.Pod) error// UpdatePod takes a Kubernetes Pod and updates it within the provider.UpdatePod(ctx context.Context, pod *corev1.Pod) error// DeletePod takes a Kubernetes Pod and deletes it from the provider.DeletePod(ctx context.Context, pod *corev1.Pod) error// GetPod retrieves a pod by name from the provider (can be cached).GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)// GetPodStatus retrieves the status of a pod by name from the provider.GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)// GetPods retrieves a list of all pods running on the provider (can be cached).GetPods(context.Context) ([]*corev1.Pod, error)}PodNotifier：该接口容许Provider提供异步告诉Virtual-Kubelet无关Pod状态更新的信息，如未实现该接口的话，Virtual-Kubelet会定期检查所有Pod的状态，在打算运行大量Pod的场景中强烈推荐实现该接口type PodNotifier interface { ...

作者：石义峰 起源：恒生LIGHT云社区 k8s装置配置运行装置环境倡议k8s零碎由一组可执行程序组成，可在GitHub上k8s我的项目页面下载编译好的二进制安装包，也可间接下载其源码编译后装置。 装置环境可参照k8s官网，倡议如下： 一台兼容的 Linux 主机。Kubernetes 我的项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令每台机器 2 GB 或更多的 RAM （如果少于这个数字将会影响你利用的运行内存)2 CPU 核或更多集群中的所有机器的网络彼此均能相互连接(公网和内网都能够)节点之中不能够有反复的主机名、MAC 地址或 product_uuid。请参见这里理解更多详细信息。开启机器上的某些端口。请参见这里 理解更多详细信息。禁用替换分区。为了保障 kubelet 失常工作，你必须 禁用替换分区。软硬件举荐配置CPU/内存Master：至多2C2GNode：依据具体须要运行的容器数量调整Linux操作系统Redhat 7+Centos 7+K8S1.18+下载地址及阐明：https://github.com/kubernetes...docker1.13+下载地址及阐明：https://www.docker.cometcd3+下载地址及阐明：https://github.com/coreos/etc...版本偏差策略kube-apiserver在HA 集群中， 多个 kube-apiserver 实例小版本号最多差1。 kubeletkubelet 版本号不能高于 kube-apiserver，最多能够比 kube-apiserver 低两个小版本。 阐明： 如果 HA 集群中多个 kube-apiserver 实例版本号不统一，相应的 kubelet 版本号可选范畴也要减小。kube-controller-manager、 kube-scheduler 和 cloud-controller-managerkube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本不能高于 kube-apiserver 版本号。 最好它们的版本号与 kube-apiserver 保持一致，但容许比 kube-apiserver 低一个小版本（为了反对在线降级）。 阐明： 如果在 HA 集群中，多个 kube-apiserver 实例版本号不统一，他们也能够跟 任意一个 kube-apiserver 实例通信（例如，通过 load balancer）， 但 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本可用范畴会相应的减小。kubectlkubectl 能够比 kube-apiserver 高一个小版本，也能够低一个小版本。 ...

1.随记存储： 简略存储：EmptyDir HostPath NFS` 高级存储：pv pvc 配置存储：configMap Secret ------------------emptydir------------------------------apiVersion: v1kind: Podmetadata: name: emptydir-volume namespace: uatspec: containers: - name: emptydir-nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 volumeMounts: - name: logs-volume mountPath: /var/log/nginx - name: emptydir-busybox image: busybox:1.30 imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts: - name: logs-volume mountPath: /logs volumes: - name: logs-volume emptyDir: {} kubectl logs -f emptydir-volume -n uat -c emptydir-busybox查看emptydir-volume pod外面的emptydir-busybox容器的日志------------------emptydir------------------------------------------------hostPath------------------------------apiVersion: v1kind: Podmetadata: name: emptydir-volume namespace: uatspec: containers: - name: emptydir-nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 volumeMounts: - name: logs-volume mountPath: /var/log/nginx - name: emptydir-busybox image: busybox:1.30 imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts: - name: logs-volume mountPath: /logs volumes: - name: logs-volume hostPath: path: /root/logs type: DirectoryOrCreate type： DirectoryOrCreate: 目录存在就应用，不存在就先创立后应用 Directory: 目录必须存在 FileOrCreate: 文件存在就应用，不存在就先创立后应用 File: 文件必须应用 Socket：unix套接字必须存在 CharDevice: 字符设施必须存在 BlockDevice: 块设施必须存在------------------hostPath------------------------------------------------NFS------------------------------yum install nfs-utils -y mkdir /root/data/nfs -pv vim /etc/exports/root/data/nfs 192.168.56.0/24(rw,no_root_squash)systemctl start nfsapiVersion: v1kind: Podmetadata: name: emptydir-volume namespace: uatspec: containers: - name: emptydir-nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 volumeMounts: - name: logs-volume mountPath: /var/log/nginx - name: emptydir-busybox image: busybox:1.30 imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","tail -f /logs/access.log"] volumeMounts: - name: logs-volume mountPath: /logs volumes: - name: logs-volume nfs: server: 192.168.56.108 path: /root/data/nfs------------------NFS------------------------------------------------------------pv---------------------长久卷： 对底层存储的形象，个别由k8s管理员进行治理存储类型：存储能力：拜访模式：ReadWriteOnce(RWO) 读写权限 但只能被单个节点挂载 不同底层反对的模式是不同的 ReadOnlyMany(ROM) 只读权限 能够被多个节点挂载 ReadWriteMany(RWX) 读写权限，能够被多个节点挂载 回收策略：Retain 保留 Recycle 回收 Delete: 删除 存储类别：pv能够通过storageClassname参数指定pv的一个存储类别 具备特定类别的pv只能和申请该类别的pvc进行绑定 未设定类别的pv只能与不申请任何类别的pvc进行绑定 status: 一个pv的生命周期 Available 可用 可用状态，还没有和任何pvc绑定 Bound 已绑定 也和pvc进行绑定 Released 已开释 对应的pvc曾经删除了，然而资源还未被集群从新申明 Failed 失败 该pv曾经被主动回收失败 more /etc/exports/root/data/pv1 192.168.56.0/24(rw,no_root_squash)/root/data/pv2 192.168.56.0/24(rw,no_root_squash)/root/data/pv3 192.168.56.0/24(rw,no_root_squash)---apiVersion: v1kind: PersistentVolumemetadata: name: voluem-pv1spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv1 server: 192.168.56.108---apiVersion: v1kind: PersistentVolumemetadata: name: voluem-pv2spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv2 server: 192.168.56.108---apiVersion: v1kind: PersistentVolumemetadata: name: voluem-pv3spec: capacity: storage: 1Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain nfs: path: /root/data/pv3 server: 192.168.56.108 kubectl get pv -o wide------------------------------pv---------------------------------------------------pvc---------------------长久卷申明：用户向k8s收回的一种资源申请对pv应用的申请apiVersion: v1kind: PersistentVolumeClaimmetadata: name: volume-pvc namespace: uatspec: accessModes: #拜访模式 selector：#采纳标签对pv抉择 storageClassName: #存储类别 resources: #空间 requests: storage: 5Gi ------------configMap----------------------------apiVersion: v1kind: ConfigMapmetadata: name: volume-configMap namespace: uatdata: info: | username: slq password: 123456789------------configMap----------------------------------------secret----------------------------base64编码 一下------------secret----------------------------

download：Docker+Kubernetes(k8s)微服务容器化实际服务器端代码，server_tcp.py !/usr/bin/env python-- coding:utf-8 --执行客户端发送过去的命令，并把执行后果返回给客户端import socket, traceback, subprocess host = ''port = 51888 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((host, port))s.listen(1) while 1: try: client_socket, client_addr = s.accept()except Exception, e: traceback.print_exc() continuetry: print 'From host:', client_socket.getpeername() while 1: command = client_socket.recv(4096) if not len(command): break print client_socket.getpeername()[0] + ':' + str(command) # 执行客户端传递过去的命令 handler = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE) output = handler.stdout.readlines() if output is None: output = [] for one_line in output: client_socket.sendall(one_line) client_socket.sendall("\n") client_socket.sendall("ok")except Exception, e: traceback.print_exc()try: client_socket.close()except Exception, e: traceback.print_exc()2.客户端代码 client_tcp.py ...

1.装置ingress版本信息：k8s：1.20.9ingress: 0.48.1 https://github.com/kubernetes... 下载镜像 docker pull registry.cn-hangzhou.aliyuncs.com/kubernetes-fan/ingress-nginx:v0.48.1 [root@node1 ingress]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEnginx latest 08b152afcfae 13 days ago 133MBregistry.aliyuncs.com/google_containers/kube-proxy v1.20.9 8dbf9a6aa186 2 weeks ago 99.7MBregistry.aliyuncs.com/google_containers/kube-controller-manager v1.20.9 eb07fd4ad3b4 2 weeks ago 116MBregistry.aliyuncs.com/google_containers/kube-apiserver v1.20.9 0d0d57e4f64c 2 weeks ago 122MBregistry.aliyuncs.com/google_containers/kube-scheduler v1.20.9 295014c114b3 2 weeks ago 47.3MBregistry.cn-hangzhou.aliyuncs.com/kubernetes-fan/ingress-nginx v0.48.1 ac0e4fe3e6b0 3 weeks ago 279MBquay.io/coreos/flannel v0.14.0 8522d622299c 2 months ago 67.9MBregistry.aliyuncs.com/google_containers/etcd 3.4.13-0 0369cf4303ff 11 months ago 253MBregistry.aliyuncs.com/google_containers/coredns 1.7.0 bfe3a36ebd25 13 months ago 45.2MBregistry.aliyuncs.com/google_containers/pause 3.2 80d28bedfe5d 17 months ago 683kBbusybox 1.30 64f5d945efcc 2 years ago 1.2MB下载deploy.yaml文件 地址：https://raw.githubusercontent...，如果下载不下来，能够应用上面的 ...

1.问题deploy.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: service-deployment namespace: devspec: replicas: 3 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80service.yaml apiVersion: v1kind: Servicemetadata: name: service-type namespace: devspec: selector: app: nginx-pod clusterIP: 10.1.97.97 type: ClusterIP ports: - port: 80 #service端口 targetPort: 80 #pod端口创立之后信息 [root@node1 ~]# kubectl describe svc -n devName: service-typeNamespace: devLabels: <none>Annotations: <none>Selector: app=nginx-podType: ClusterIPIP Families: <none>IP: 10.1.97.97IPs: 10.1.97.97Port: <unset> 80/TCPTargetPort: 80/TCPEndpoints: 10.244.1.44:80,10.244.1.45:80,10.244.2.46:80Session Affinity: NoneEvents: <none>pod信息 ...

1.pod控制器类别ReplicaSetdeployment 次要 Horizontal Pod Autoscaler (hpa) 高可用 实现削峰填谷 DaemonSet 守护进厂类的工作Job 执行一次工作，执行完之后就完结Cronjob 周期性的执行工作StatefulSet 治理有状态利用2.具体控制器------------------------------------------------pod控制器------------------------------------------------------replicasetapiVersion: apps/v1kind: ReplicaSetmetadata: name: myrs namespace: dev labels: controller: rsspec: replicas: 3 selector: matchLabels: app: nginx-pod matchExpressions: - {key: app,operator: In, Values: [nginx-pod]} template: metadata: labels: app: nginx-pod spec: containers: - name: nginx image: nginx:1.17.1 ports: - containerPort: 80-------------------------------------------- apiVersion: apps/v1kind: ReplicaSetmetadata: name: my-rs namespace: devspec: replicas: 3 selector: matchLabels: app: nginx-pod template: metadata: labels: app: nginx-pod spec: containers: - name: my-nginx image: nginx-------------------------------------------- [root@node1 ~]# kubectl get rs -n dev -o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORmy-rs 3 3 3 3m34s my-nginx nginx app=nginx-pod--------------------------------------------[root@node1 ~]# kubectl get pod -n devNAME READY STATUS RESTARTS AGEmy-rs-6wbdd 1/1 Running 0 5mmy-rs-cs6nr 1/1 Running 0 5mmy-rs-hzncc 1/1 Running 0 5m--------------------------------------------rs 扩缩容kubectl edit rs my-rs -n dev 批改replicas即可kubectl scale rs my-rs --replicas=2 -n dev--------------------------------------------镜像版本升级kubectl edit rs my-rs -n dev 批改imagekubectl set image rs my-rs my-nginx=nginx:1.18.0 -n dev删除rskubectl delete rs my-rs -n dev #首先把正本数设置成0,而后再删除kubectl delete rs my-rs -n dev --cascade=false #只删除控制器，不删除podkubectl delete -f my-rs.yaml ---------------deployment反对replicaset的所有性能反对版本回滚和版本回退apiVersion: apps/v1kind: Deploymentmetadata: name: mynginx namespace: devspec: replicas: 3 selector: matchLabels: run: nginx template: metadata: labels: run: nginx spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCPkubectl apply -f yaml-nginx-deploy.yamlkubectl delete -f yaml-nginx-deploy.yaml查问对应的rs: [root@node1 ~]# kubectl get rs -n dev -o wideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORmynginx-869c47cdd9 3 3 3 3m32s nginx nginx pod-template-hash=869c47cdd9,run=nginx扩缩容： kubectl scale deploy my-nginx --replicas=5 -n dev kubectl edit deploy my-nginx -n dev [root@node1 ~]# kubectl scale deploy mynginx --replicas=5 -n dev deployment.apps/mynginx scaled kubectl edit deploy mynginx -n dev 批改replicas 镜像降级: 重建更新： 滚动更新：(默认滚动更新) 新的起来了之后，旧的才会进行 ----- spec: strategy: type: Recreate ----- spec: strategy: type: RollingUpdate maxUnavailable: 25% maxSurge: 25% kubectl set image deploy mynginx nginx=nginx -n dev kubectl get pod -n dev -w 滚动更新 镜像降级，创立新的rs，原来的rs会进行保留，成为上一个版本 版本回退 kubectl rollout status history pause resume restart undo 查看状态 [root@node1 ~]# kubectl rollout status deploy mynginx -n dev Waiting for deployment "mynginx" rollout to finish: 1 out of 2 new replicas have been updated... Waiting for deployment "mynginx" rollout to finish: 1 out of 2 new replicas have been updated... Waiting for deployment "mynginx" rollout to finish: 1 out of 2 new replicas have been updated... Waiting for deployment "mynginx" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "mynginx" rollout to finish: 1 old replicas are pending termination... deployment "mynginx" successfully rolled out 查看历史 kubectl rollout history deploy mynginx -n dev kubectl apply -f yaml-nginx-deploy.yaml --record 查看历史 [root@node1 ~]# kubectl rollout history deploy mynginx -n dev deployment.apps/mynginx REVISION CHANGE-CAUSE 1 <none> 2 <none> //回退版本to-revision 指定版本 [root@node1 ~]# [root@node1 ~]# [root@node1 ~]# kubectl rollout undo deployment mynginx --to-revision=1 -n dev金丝雀公布 中间状态：灰度公布 kubectl set image deploy mynginx nginx=nginx:1.17.4 -n dev && kubectl rollout pause deploy mynginx -n dev --------------------------------------------------hpa------------------------------------------Horizontal Pod Autoscaler手动调整改为主动调整，须要计算负载量须要装置监控 Metrics-serverkubectl top node 查看资源应用信息apiVersion： autoscaling/v1kind: HorizontalPodAutoscalermetadata: name: my-hpa namespace: devspec: minReplicas: 1 maxReplicase: 10 targetCPUUtilizationPercentage: 3 scaleTargeRef: apiVersion: apps/v1 kind: Deployment name: mynginx--------------------------------------------------hpa------------------------------------------网络局部cni--------------------------------------------------DaemonSet（ds）------------------------------------------保障集群中每个节点运行一个pod每增加一个node,就会主动运行pod其yaml格局同deploy--------------------------------------------------DaemonSet--------------------------------------------------------------------------------------------job------------------------------------------批量解决一次性工作job对应的pod的重启策略为Never,或者OnFailure次要的配置项：manualSelector: truecompletions: 6 #指定运行的pod总数parallelism：3 #并发执行总数--------------------------------------------------Cronjob------------------------------------------job工作创立之后立即执行cronjob以job为治理对象，相似cron表达式 在指定的工夫点执行工作，反复运行schedule: cron表达式，最短时间为分钟concurrencyPolicy: 并发执行工作，前一次工作没有实现，是否执行下一次工作， Allow 容许（默认） Forbid 禁止 Replace 替换，勾销以后的工作，执行新的工作failedJobHistoryLimit: 为失败的工作保留的历史记录数目successfulJobHistoryLimit: 为胜利的工作保留历史记录数目startingDeadlineSeconds: 启动工作谬误的超时工夫jobTemplate:

K8s 作为一个开源我的项目，激励全世界的参与者踊跃贡献力量，包含 kubernetes/kubernetes 主我的项目、kubernetes/website、kubernetes/enhancements 等 K8s 相干我的项目都是如此。本文将介绍给 K8s 提 PR 相干流程、注意事项等。 1. 发现 Bug 先提 Issue首先祝贺你，通过认真仔细浏览 K8s 源码(https://github.com/kubernetes/kubernetes)，或在工作实际中偶尔遇到了一个 K8s bug，第一步应该到官网 issues(https://github.com/kubernetes/kubernetes/issues) 上面查问一下，是否其他人曾经提过相干或雷同的 issue 了，如果没有查到相干 issue，那么就能够点击页面右上角 "New issue" 创立一个新 issue。 而后，抉择对应的 issue 类型，如果是 bug 则抉择第一个 "Bug Report"： 接着，就须要填写具体 bug 的 title, content，能够依据默认模板精确填写如 What happened, How to reproduce it, Environment(kubectl 版本号、OS 类型) 等，尽量清晰、筹备形容，能够间接将 bug 对应的代码文件、行数标记进去，不便 Reviewer 疾速辨认 issue 的真伪。 2. Fork 代码进行 PRPR(Pull Request) 第一步是 fork 一份 K8s master 分支代码到本人的集体仓库(Repo)，在 GitHub 界面上右上角点击 "Fork"，抉择本人的集体 GitHub 账号，稍等几秒就能够看到胜利 fork 到了本人仓库。 ...

查看主节点 kubectl get node 集群信息 kubectl cluster-infopod信息 kubectl get pods -A deployment kubectl get deployment -A基本概念： container pods :最小治理单位 有多个容器 共享网络 127.0.0.1之间能够独特拜访 共享过程 共享主机名service ：裸露服务 负载平衡 k8s内部 nodeport 裸露进来 clusteip ingressdeployment ：控制器 保障pods固定数量 每个节点上运行（proxy flannel daemonset ） k8s coredns：服务注册与发现创立deployment: kubectl create deployment mynginx --image=nginx:1.8 --replicas=3kubectl create deployment mynginx --image=docker.io/library/nginx查看deployment kubectl get deployment -o wide ------>蕴含selector deployment通过selector来找到对应的pod 相似普罗米修斯的label删除deployment kubectl delete deployment mynginx批改pod正本数量 kubectl scale deployment mynginx --replicas=3查看详情信息 kubectl describe deployment/pod mynginx裸露服务 ...

简略demopackage mainimport ( "context" apiv1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/clientcmd" "log")func main(){ kubeconfig := "config/kube.conf" //来自集群中的conf config, err := clientcmd.BuildConfigFromFlags("", kubeconfig) if err != nil { panic(err) } clientset, err := kubernetes.NewForConfig(config) if err != nil { panic(err) } deployments := clientset.AppsV1().Deployments(apiv1.NamespaceDefault) list, err := deployments.List(context.TODO(), metav1.ListOptions{}) if err != nil { panic(err) } for _, d := range list.Items { log.Printf("* %s (%d replicas ) %s \n ",d.Name,*d.Spec.Replicas,d.Namespace) } namespaceList, err := clientset.CoreV1().Namespaces().List(context.TODO(), metav1.ListOptions{}) if err != nil { log.Fatal("namespace error",err) panic(err) } for _,namespace := range namespaceList.Items { log.Println(namespace.Name,namespace.CreationTimestamp) }}官网参考 https://github.com/kubernetes... ...

第一章1.1 前世今生DOCKER？ 阿米巴 nginx MESOSdocker Swarm 轻量级的， 企业级须要k8sGoogle Borg 管理系统？ Borg --Go--》Kubernetes kubernetes 轻量级 Go 再语言级别反对过程治理，对资源占用比拟小开源弹性伸缩负载平衡： IPVS （章文嵩博士）- 1.2 常识图谱!资源，资源清单语法，编写pod， 把握pod的生命周期 ···把握各种控制器的 存储 config mapsecretvolumepv 服务分类: 有状态服务：DBMS 无状态服务：WEB LVS APACHE调度器集群平安HELM HELM 原理运维

作者｜段超起源｜尔达 Erda 公众号 导读：Erda 作为一站式云原生 PaaS 平台，现已面向宽广开发者实现 70w+ 外围代码全副开源！在 Erda 开源的同时，咱们打算编写《基于 K8s 的云原生 PaaS 平台基础架构》系列文章，心愿咱们的一点教训能够帮忙更多企业欠缺 PaaS 平台基础架构的建设。 系列文章举荐： 《系列好文 ｜ Kubernetes 弃用 Docker，咱们该何去何从？》《我能够减肥失败，但我的 Docker 镜像肯定要瘦身胜利！》 Kind （Kubernets in Docker），是一个能够疾速在本地部署一套 K8s 的工具，非常适合本地部署调试或者想要体验最新版本 K8s 的场景。 简略创立brew install kindkind create cluster --name testCreating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.13.4) ✓ Preparing nodes ✓ Creating kubeadm config ✓ Starting control-plane ️ Cluster creation complete. You can now use the cluster with:[root@node-2 ~]# kubectl get nodeNAME STATUS ROLES AGE VERSIONkind-control-plane Ready master 99s v1.13.4 ...

前言最近在学习k8s，并且应用了阿里云ACK的K8S集群，学到存储卷时，发现阿里云有三种解决方案：1、云盘，2、NAS，3、OSS，上面就来解说下云盘和NAS在K8S中应用办法，前面有工夫再出个OSS教程。 筹备阿里云ACK k8s集群k8s存储卷概述存储卷相干技术，官网文档 存储卷PVC：PersistentVolumeClaim存储卷申明PV：PersistentVolume存储卷类SC：StorageClass这里有篇博客写得十分好，大家有工夫能够看看它们之间的区别，本文不是解说这些概念而是应用它们 应用形式 什么是动态创立存储卷？ 所谓动态就是通过yaml文件先创立PV，而后创立PVC，再通过创立的Deployment或者StatefulSet去指定PVC。 什么是动态创建存储卷？ 所谓动静就是通过创立SC，而后创立PVC并且指定了SC，零碎就会主动创立PV，因而理论生产中更多的应用动态创建。 上面咱们也是着重解说如何动态创建存储卷。 阿里云反对的存储卷 1、云盘 如果想要创立动静存储卷必须先要创立StorageClass，上面是阿里云盘提供的以下几种StorageClass： alicloud-disk-efficiency：高效云盘。alicloud-disk-ssd：SSD云盘。alicloud-disk-essd：ESSD云盘。alicloud-disk-available：提供高可用选项，优先创立SSD云盘；如果SSD云盘售尽，则创立高效云盘alicloud-disk-topology: 应用提早绑定的形式创立云盘存储大小限度： 最低20Gi2、NAS 因为NAS跟云盘还不一样，要到阿里云控制台手动开明服务，开明之后能力应用，还有NAS没有自带SC，要本人通过yaml文件创建。 反对协定： 通用型：NFSv3(Linux)/NFSv4(Linux)/SMB2.1+(Windows)极速型：NFSv3(Linux)文件存储 CPFS：POSIX/MPI-IO(Linux)阿里云Kubernetes CSI反对2种类型的NAS动静存储卷挂载：subpath形式和filesystem形式 subpath类型的NAS动静存储卷当您的多个Kubernetes利用或者Pod须要挂载雷同的NAS存储卷共享数据时，或不同的Pod挂载雷同NAS文件系统的不同子目录时， 能够应用subpath类型的NAS动静存储卷形式。filesystem类型的NAS动静存储卷当您的Kubernetes利用须要动态创建和删除NAS文件系统和挂载点时， 能够应用filesystem类型。上面就来解说应用filesystem类型创立NAS存储卷。 存储大小限度： 无限度3、OSS 略 创立NAS StorageClass下面讲到NAS没有自带的SC须要手动通过yaml文件来创立，所以当初咱们来创立一下，依据官网文档来创立 1、创立subpath类型的StorageClass alicloud-nas-subpath.yaml apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alicloud-nas-subpathmountOptions:- nolock,tcp,noresvport- vers=3parameters: volumeAs: subpath server: "xxxxxxx.cn-hangzhou.nas.aliyuncs.com:/k8s/"provisioner: nasplugin.csi.alibabacloud.comreclaimPolicy: Retain执行以下命令创立StorageClass。 kubectl create -f alicloud-nas-subpath.yaml2、创立filesystem类型的StorageClass alicloud-nas-fs.yaml apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: alicloud-nas-fsmountOptions:- nolock,tcp,noresvport- vers=3parameters: volumeAs: filesystem zoneId: "cn-hangzhou-g" vpcId: "vpc-xxxxxxxxxxxx" vSwitchId: "vsw-xxxxxxxxx" deleteVolume: "false"provisioner: nasplugin.csi.alibabacloud.comreclaimPolicy: Retain执行以下命令创立StorageClass。 kubectl create -f alicloud-nas-fs.yaml留神：如果不填写zoneId区域id，会报错创立云盘存储卷创立动态云盘存储卷 ...

@TOC 参考资料|网址K8S和Docker介绍 装置计划参考 k8s拉取镜像解决方案 官网文档 dockerHub 虚拟化 Minikube测试教程 装置攻略前言装置环境是云服务器，Ubuntu18的零碎，无奈采纳虚拟机那种模式。装置目标次要是为了学习，所以抉择了Minikube。 生成环境版，之后兴许也会出一个教程，但临时还不想就义本人服务器的swap分区，所以见谅啦。 MinikubeMiniKube是K8S官网为了凋谢者能在个人电脑上运行K8S提供的一套工具。由Go语言实现，通过调用虚拟化管理程序，创立出一个运行在虚拟机内的单点集群。 装置kubectlK8S集群是典型的C/S架构，有一个官网提供的名为kubectl的CLI工具。尽量保障kubectl版本和K8S集群版本保持一致，或版本相差在一个小版本内。 能够抉择指定版本，也能够间接抉择装置最新的。 这个是指定版本： curl -LO https://dl.k8s.io/release/v1.10.7/bin/linux/amd64/kubectl curl -LO https://dl.k8s.io/v1.10.7/bin/linux/amd64/kubectl.sha256 echo "$(<kubectl.sha256) kubectl" | sha256sum --check -c 可能会遇到如上谬误，按如下解决即可：install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl 装置最新版本官网文档 curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"echo "$(<kubectl.sha256) kubectl" | sha256sum --check装置Minikube先看，不要焦急操作！ wget -O minikube https://github.com/kubernetes...chmod +x minikube 赋予执行权限sudo mv minikube /usr/local/bin/minikube/usr/local/bin/minikube versionminikube version: v0.28.2# 装置最新的:curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64chmod +x minikubesudo cp ./minikube /usr/local/bin/minikube应用 Minikube 创立集群，只有简略的执行 minikube start 即可 ...

简介： 随同着 5G、IoT 等技术的疾速倒退，边缘计算被越来越宽泛地利用于电信、媒体、运输、物流、农业、批发等行业和场景中，成为解决这些畛域数据传输效率的要害形式。与此同时，边缘计算状态、规模、复杂度的日益增长，边缘计算畛域的运维伎俩、运维能力对边缘业务翻新速度的撑持日趋乏力。于是，Kubernetes 迅速成为边缘计算的要害因素，帮忙企业在边缘更好地运行容器，最大化利用资源、缩短研发周期。作者｜何淋波（新胜） 背景随同着 5G、IoT 等技术的疾速倒退，边缘计算被越来越宽泛地利用于电信、媒体、运输、物流、农业、批发等行业和场景中，成为解决这些畛域数据传输效率的要害形式。与此同时，边缘计算状态、规模、复杂度的日益增长，边缘计算畛域的运维伎俩、运维能力对边缘业务翻新速度的撑持日趋乏力。于是，Kubernetes 迅速成为边缘计算的要害因素，帮忙企业在边缘更好地运行容器，最大化利用资源、缩短研发周期。 然而，如果将原生 Kubernetes 间接利用到边缘计算场景下，依然须要解决诸多问题，比方云与边个别位于不同网络立体，同时边缘节点广泛位于防火墙外部，采纳云(核心)边协同架构，将导致原生 K8s 零碎的运维监控能力面临如下挑战： K8s 原生运维能力缺失(如 kubectl logs/exec 等无奈执行)社区支流监控运维组件无奈工作(如 Prometheus/metrics-server )为了帮忙企业解决原生 Kubernetes 在边缘场景下对于利用生命周期治理、云边网络连接、云边端运维协同、异构资源反对等方方面面的挑战，基于 K8s 实现的边缘计算云原生开源平台 OpenYurt 应运而生，其也是 CNCF 在边缘云原生幅员中的重要组成部分。本文将具体介绍，作为 OpenYurt 外围组件之一的 Yurt-Tunnel 如何是扩大原生 K8s 零碎在边缘场景下相干能力的。 Yurt-Tunnel 设计思路因为边缘能够拜访云端，因而能够思考在云边构建能够反向穿透的隧道，从而保障云(核心)能够基于隧道被动拜访边缘。过后咱们也考察了很多开源的隧道计划，从能力以及生态兼容性等方面，最初咱们抉择基于 ANP设计并实现了 Yurt-Tunnel 整体解决方案，具备平安，非侵入、可扩大、传输高效等长处。 实现形式在 K8s 云边一体化架构中构建一个平安、非侵入、可扩大的反向通道解决方案，计划中至多须要包含如下能力。 云边隧道构建隧道两端证书的自治理云端组件申请被无缝倒流到隧道Yurt-tunnel 的架构模块如下图： 3.1 云边隧道构建 当边缘的 yurt-tunnel-agent 启动时，会依据拜访地址与 yurt-tunnel-server 建设连贯并注册，并周期性检测连贯的衰弱状态以及重建连贯等。 # https://github.com/openyurtio/apiserver-network-proxy/blob/master/pkg/agent/client.go#L189# yurt-tunnel-agent的注册信息:"agentID": {nodeName}"agentIdentifiers": ipv4={nodeIP}&host={nodeName}"当 yurt-tunnel-server 收到云端组件的申请时，须要把申请转发给对应的 yurt-tunnel-agent 。因为除了转发初始申请之外，该申请 session 后续还有数据返回或者数据的继续转发(如 kubectl exec )。因而须要双向转发数据。同时须要反对并发转发云端组件的申请，象征须要为每个申请生命周期建设一个独立的标识。所以设计上个别会有两种计划。 计划 1: 初始云边连贯仅告诉转发申请，tunnel-agent 会和云端建设新连贯来解决这个申请。通过新连贯能够很好的解决申请独立标识的问题，同时并发也能够很好的解决。然而为每个申请都须要建设一个连贯，将耗费大量的资源。 ...

10、高可用架构（扩容多Master架构）Kubernetes作为容器集群零碎，通过健康检查+重启策略实现了Pod故障自我修复能力，通过调度算法实现将Pod分布式部署，并放弃预期正本数，依据Node生效状态主动在其余Node拉起Pod，实现了应用层的高可用性。 针对Kubernetes集群，高可用性还应蕴含以下两个层面的思考：Etcd数据库的高可用性和Kubernetes Master组件的高可用性。 而Etcd咱们曾经采纳3个节点组建集群实现高可用，本节将对Master节点高可用进行阐明和施行。 Master节点扮演着总控核心的角色，通过一直与工作节点上的Kubelet和kube-proxy进行通信来保护整个集群的衰弱工作状态。如果Master节点故障，将无奈应用kubectl工具或者API做任何集群治理。 Master节点次要有三个服务kube-apiserver、kube-controller-manager和kube-scheduler，其中kube-controller-manager和kube-scheduler组件本身通过抉择机制曾经实现了高可用，所以Master高可用次要针对kube-apiserver组件，而该组件是以HTTP API提供服务，因而对他高可用与Web服务器相似，减少负载均衡器对其负载平衡即可，并且可程度扩容。 多Master架构图： 10.1、装置Docker10.2、配置主机环境10.3、部署Master2 Node（192.168.219.164）Master2 与已部署的Master1所有操作统一。所以咱们只需将Master1所有K8s文件拷贝过去，再批改下服务器IP和主机名启动即可。 10.3.1、创立etcd证书目录在Master2创立etcd证书目录：mkdir -p /opt/etcd/ssl 10.3.2、拷贝文件（Master1操作）拷贝Master1上所有K8s文件和etcd证书到Master2： scp -r /opt/kubernetes root@192.168.219.165:/optscp -r /opt/cni/ root@192.168.219.165:/optscp -r /opt/etcd/ssl root@192.168.219.165:/opt/etcdscp /usr/lib/systemd/system/kube* root@192.168.219.165:/usr/lib/systemd/systemscp /usr/bin/kubectl root@192.168.219.165:/usr/bin10.3.3、批改配置文件IP和主机名批改apiserver、kubelet和kube-proxy配置文件为本地IP： vi /opt/kubernetes/cfg/kube-apiserver.conf ...--bind-address=192.168.219.165 \--advertise-address=192.168.219.165 \... vi /opt/kubernetes/cfg/kubelet.conf--hostname-override=k8s-master2 vi /opt/kubernetes/cfg/kube-proxy-config.ymlhostnameOverride: k8s-master210.3.4、启动设置开机启动systemctl daemon-reloadsystemctl start kube-apiserversystemctl start kube-controller-managersystemctl start kube-schedulersystemctl start kubeletsystemctl start kube-proxysystemctl enable kube-apiserversystemctl enable kube-controller-managersystemctl enable kube-schedulersystemctl enable kubeletsystemctl enable kube-proxy10.3.5、查看集群状态kubectl get csNAME STATUS MESSAGE ERRORscheduler Healthy ok controller-manager Healthy ok etcd-1 Healthy {"health":"true"} etcd-2 Healthy {"health":"true"} etcd-0 Healthy {"health":"true"}10.3.6、批准kubelet证书申请kubectl get csrNAME AGE SIGNERNAME REQUESTOR CONDITIONnode-csr-JYNknakEa_YpHz797oKaN-ZTk43nD51Zc9CJkBLcASU 85m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending kubectl certificate approve node-csr-JYNknakEa_YpHz797oKaN-ZTk43nD51Zc9CJkBLcASU kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-master1 Ready <none> 34h v1.18.18k8s-master2 Ready <none> 83m v1.18.18k8s-node1 Ready <none> 33h v1.18.18k8s-node2 Ready <none> 33h v1.18.1811、部署Nginx负载均衡器Nginx是一个支流Web服务和反向代理服务器，这里用四层实现对apiserver实现负载平衡。 ...

1、资源筹备零碎：CentOS 7.9.2009主机名ip组件k8s-master1192.168.219.161kube-apiserver，kube-controller-manager，kube-scheduler，etcdk8s-node1192.168.219.162kubelet，kube-proxy，docker，etcdk8s-node2192.168.219.163kubelet，kube-proxy，docker，etcd2、软件信息软件版本docker19.03.11kubernetes1.18.183、docker部署参考：https://segmentfault.com/a/11...须要删除"exec-opts": ["native.cgroupdriver=systemd"], cat > /etc/docker/daemon.json << EOF{ "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "storage-driver": "overlay2", "storage-opts": [ "overlay2.override_kernel_check=true" ], "registry-mirrors": ["https://n0k07cz2.mirror.aliyuncs.com"]}EOF4、系统配置(master、node节点)参考：https://segmentfault.com/a/11... 5、部署Etcd集群Etcd 是一个分布式键值存储系统，Kubernetes应用Etcd进行数据存储，所以先筹备一个Etcd数据库，为解决Etcd单点故障，应采纳集群形式部署，这里应用3台组建集群，可容忍1台机器故障，当然，你也能够应用5台组建集群，可容忍2台机器故障。 节点名称IPetcd-1192.168.219.161etcd-2192.168.219.162etcd-3192.168.219.163注：为了节俭机器，这里与K8s节点机器复用。也能够独立于k8s集群之外部署，只有apiserver能连贯到就行。5.1、筹备cfssl证书生成工具cfssl是一个开源的证书管理工具，应用json文件生成证书，相比openssl更方便使用。找任意一台服务器操作，这里用Master节点。 wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64mv cfssl_linux-amd64 /usr/local/bin/cfsslmv cfssljson_linux-amd64 /usr/local/bin/cfssljsonmv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo5.2、生成Etcd证书5.2.1、创立工作目录mkdir -p ~/TLS/etcdcd ~/TLS/etcd5.2.2、自签证书颁发机构（CA）自签CA： cat > ca-config.json << EOF{ "signing": { "default": { "expiry": "87600h" }, "profiles": { "www": { "expiry": "87600h", "usages": [ "signing", "key encipherment", "server auth", "client auth" ] } } }}EOF cat > ca-csr.json << EOF{ "CN": "etcd CA", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "L": "Beijing", "ST": "Beijing" } ]}EOF生成证书： ...

作者｜段超起源｜尔达 Erda 公众号 背景咱们是一家做商业软件的公司，从一开始咱们就把软件交付流程做的十分规范且简略，所有的软件都是基于咱们的企业数字化平台 Erda（现已开源）来交付，底层基于 Kubernetes，为企业提供 DevOps、微服务治理、多云治理以及快数据管理等云厂商无绑定的 IT 服务。 随着咱们服务的客户数量越来越多，现在咱们治理着相当规模数量的 Kubernetes 集群，集群的稳定性决定了服务质量以及对外口碑，很长一段时间内咱们在这件事件上都显得很被动，常常会呈现 Erda 反对同学或者客户将问题反馈到咱们说：有业务呈现了问题，须要咱们帮助查问一下是不是平台导致的，而后咱们下来一顿操作最初解决问题，回答客户。看似业余且厉害，急用户之所急，实则无章无奈，一地鸡毛。 通常咱们依赖监控零碎来提前发现问题，然而监控数据作为一个正向链路，很难笼罩到所有场景，常常会有因为集群配置的不一致性或者一些更底层资源的异样，导致即便监控数据齐全失常，然而整个零碎仍然会有一些性能不可用。对此，咱们做了一套巡检零碎，针对零碎中一些薄弱点以及一致性做诊断，美中不足的是，这套零碎的扩展性不是很好，对集群跟巡检项的治理也绝对粗犷了一点。 最初，咱们决定做一个更加云原生的诊断工具，应用 operator 来实现集群跟诊断项的治理，形象出集群跟诊断项的资源概念，来解决大规模 Kubernetes 集群的诊断问题，通过在核心下发诊断项到其余集群，并对立收集其余集群的诊断后果，来实现任何时刻都能够从核心获取到其余所有集群的运行状态，做到对大规模 Kubernetes 集群的无效治理以及诊断。 Kubeprober我的项目介绍我的项目地址： https://github.com/erda-project/kubeprober KubeProber 是一个针对大规模 Kubernetes 集群设计的诊断工具，用于在 Kubernetes 集群中执行诊断项以证实集群的各项性能是否失常，KubeProber 有如下特点: 反对大规模集群：反对多集群治理，反对在治理端配置集群跟诊断项的关系以及对立查看所有集群的诊断结。云原生：外围逻辑采纳 operator 来实现，提供残缺的 Kubernetes API 兼容性。可扩大：反对用户自定义巡检项。 其外围架构如下： 区别于监控零碎，kubeProber 从巡检的角度来证实集群的各项性能是否失常，监控作为正向链路，无奈笼罩零碎中的所有场景，零碎中各个环境的监控数据都失常，也不能保证系统是 100% 能够用的，因而须要一个工具从反向来证实零碎的可用性、从根本上做到先于用户发现集群中不可用的点，比方： 集中的所有节点是否均能够被调度，有没有非凡的污点存在等。pod 是否能够失常的创立、销毁，验证从 Kubernetes，Kubelet 到 Docker 的整条链路。创立一个 Service，并测试连通性，验证 kube-proxy 的链路是否失常。解析一个外部或者内部的域名，验证 CoreDNS 是否失常工作。拜访一个 ingress 域名，验证集群中的 ingress 组件是否失常工作。创立并删除一个 namespace，验证相干的 webhook 是否失常工作。对 Etcd 执行 put/get/delete 等操作，用于验证 Etcd 是否失常运行。通过 mysql-client 的操作来验证 MySQL 是否失常运行。模仿用户对业务零碎进行登录、操作，验证业务的主流程是否经常。查看各个环境的证书是否过期。云资源的到期查看。更多... ...

概述Kubernetes(K8s) 作为以后最出名的容器编排工具，称得上是云原生(Cloud Native)时代的“操作系统”，相熟和应用它是研发、运维、产品等的必备技能。本篇文章从倒退历史、装置运行、资源、存储、网络、平安、治理、将来瞻望等方面约 680 个知识点概述了 K8s 的常识图谱，旨在帮忙大家更好的理解 K8s 的相干常识，为业务、运维、翻新打下坚实基础。 完整版链接：https://www.processon.com/view/link/60dfeb3e1e085359888fd3e3 名词简写 PV: Persistent VolumePVC: Persistent Volume ClaimSA: Service AccountHA: High AvailableHPA: Horizontal Pod AutoscalerVPA: Vertical Pod AutoscalerPSP: Pod Security PolicyPDB: Pod Disruption BudgetCRD: Custom Resource DefinitionCSI: Container Storage InterfaceCNI: Container Network InterfaceCRI: Container Runtime InterfaceOCI: Open Container InitiativeCNCF: Cloud Native Computing Foundation1. 倒退历史 History随着 Docker 在容器技术站稳脚跟，并在多个场合挑战了其它玩家的切身利益，比方 Google、RedHat、CoreOS、Microsoft 等。Google 在 docker 我的项目刚衰亡就祭出一剑：把外部生产验证的容器 lmctfy（Let Me Container That For You）开源。但面对 Docker的强势崛起，毫无招架之力。Docker 在容器界具备相对的权威和话语权。Google 于是开出高价给 Docker，Docker 的技术 boss 也是联结创始人 Solomon Hykes 预计也是个理想主义者，对这橄榄枝束之高阁。 ...

前言最近在应用k8s搭建微服务时，发现须要手动批改yaml文件外面的pod name、pod image、svc name、ingress tls等等，十分麻烦，然而有了helm之后状况就不一样了，helm是k8s的包管理器，相似ubuntu的apt-get，centos的yum一样，有了helm安装包就十分不便了，上面就解说通过helm来装置rabbitmq。 筹备工作装置k8s我应用的是阿里云的ACK k8s服务。装置k8s客户端:kubectlkubectl装置地址装置helm客户端装置helm配置helm repo源上面是我增加的三个源：stable、bitnami和ali helm repo add stable https://charts.helm.sh/stablehelm repo add bitnami https://charts.helm.sh/stablehelm repo add ali https://charts.helm.sh/stable查看曾经装置好的repo源 $ helm repo list NAME URLstable https://charts.helm.sh/stablebitnami https://charts.bitnami.com/bitnamiali https://apphub.aliyuncs.com/stable/rabbitmq装置形式装置rabbitmq办法有很多上面列举几个惯例装置办法： centos 7/8装置rabbitmq阿里云ECS CentOS提供装置k8s装置rabbitmq官网文档提供装置helm装置rabbitmq社区大佬提供装置helm装置rabbitmq这里咱们应用helm来装置rabbitmq，首先咱们看看helm外面有没有rabbitmq的chart， $ helm search repo rabbitmqNAME CHART VERSION APP VERSION DESCRIPTIONali/prometheus-rabbitmq-exporter 0.5.5 v0.29.0 Rabbitmq metrics exporter for prometheusali/rabbitmq 6.18.2 3.8.2 DEPRECATED Open source message broker software ...ali/rabbitmq-ha 1.47.0 3.8.7 Highly available RabbitMQ cluster, the open sou...bitnami/rabbitmq 8.16.1 3.8.18 Open source message broker software that implem...stable/prometheus-rabbitmq-exporter 0.5.6 v0.29.0 DEPRECATED Rabbitmq metrics exporter for promet...stable/rabbitmq 6.18.2 3.8.2 DEPRECATED Open source message broker software ...stable/rabbitmq-ha 1.47.1 3.8.7 DEPRECATED - Highly available RabbitMQ cluster,...能够看到不同的repo源提供的rabbitmq的chart的版本也不同，咱们选用的是stable/rabbitmq，chart版本：6.18.2，APP版本：3.8.2。 ...

前言最近在学习如何应用k8s搭建nacos服务以及如何应用，记录下来分享给大家。 筹备工作K8S：我应用的是阿里云ACK(阿里的k8s服务)，Nacos：因为我应用的是阿里云RDS的mysql，所以 用的是nacos-group/nacos-k8s的nacos-no-pvc-ingress.yaml文件 开始搭建首先咱们来查看nacos-no-pvc-ingress.yaml文件 ###应用自建数据库；应用Ingress公布配置后盾###---apiVersion: v1kind: Servicemetadata:name: nacos-headlesslabels: app: nacos-headlessspec:type: ClusterIPclusterIP: Noneports: - port: 8848 name: server targetPort: 8848 - port: 9848 name: client-rpc targetPort: 9848 - port: 9849 name: raft-rpc targetPort: 9849 ## 兼容1.4.x版本的选举端口 - port: 7848 name: old-raft-rpc targetPort: 7848selector: app: nacos---apiVersion: v1kind: ConfigMapmetadata:name: nacos-cmdata:mysql.host: "10.127.1.12"mysql.db.name: "nacos_devtest"mysql.port: "3306"mysql.user: "nacos"mysql.password: "passwd"---apiVersion: apps/v1kind: StatefulSetmetadata:name: nacosspec:serviceName: nacos-headlessreplicas: 3template: metadata: labels: app: nacos annotations: pod.alpha.kubernetes.io/initialized: "true" spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: In values: - nacos topologyKey: "kubernetes.io/hostname" containers: - name: k8snacos imagePullPolicy: Always image: nacos/nacos-server:latest resources: requests: memory: "2Gi" cpu: "500m" ports: - containerPort: 8848 name: client - containerPort: 9848 name: client-rpc - containerPort: 9849 name: raft-rpc - containerPort: 7848 name: old-raft-rpc env: - name: NACOS_REPLICAS value: "3" - name: MYSQL_SERVICE_HOST valueFrom: configMapKeyRef: name: nacos-cm key: mysql.host - name: MYSQL_SERVICE_DB_NAME valueFrom: configMapKeyRef: name: nacos-cm key: mysql.db.name - name: MYSQL_SERVICE_PORT valueFrom: configMapKeyRef: name: nacos-cm key: mysql.port - name: MYSQL_SERVICE_USER valueFrom: configMapKeyRef: name: nacos-cm key: mysql.user - name: MYSQL_SERVICE_PASSWORD valueFrom: configMapKeyRef: name: nacos-cm key: mysql.password - name: MODE value: "cluster" - name: NACOS_SERVER_PORT value: "8848" - name: PREFER_HOST_MODE value: "hostname" - name: NACOS_SERVERS value: "nacos-0.nacos-headless.default.svc.cluster.local:8848 nacos-1.nacos-headless.default.svc.cluster.local:8848 nacos-2.nacos-headless.default.svc.cluster.local:8848"selector: matchLabels: app: nacos---# ------------------- App Ingress ------------------- #apiVersion: extensions/v1beta1kind: Ingressmetadata:name: nacos-headlessnamespace: defaultspec:rules:- host: nacos-web.nacos-demo.com http: paths: - path: / backend: serviceName: nacos-headless servicePort: server接着咱们改改下面的配置文件变成咱们本人的。 ...

咱们晓得对于资源对象的操作都是通过 APIServer 进行的，那么集群是怎么晓得咱们的申请就是非法的申请呢？这个就须要理解 Kubernetes的认证鉴权流程 API 对象在讲认证鉴权之前，咱们还须要再去了解下 Kubernetes 集群中的对象，咱们晓得，在 Kubernetes 集群中，Kubernetes 对象是咱们长久化的实体，就是最终存入 etcd 中的数据。咱们间接编写的 YAML 文件，通过 kubectl 来提交的资源清单文件，而后创立的对应的资源对象，那么它到底是如何将咱们的 YAML 文件转换成集群中的一个 API 对象的呢？ 这个就须要去理解下申明式 API的设计，Kubernetes API 是一个以 JSON 为次要序列化形式的 HTTP 服务，除此之外也反对 Protocol Buffers 序列化形式，次要用于集群外部组件间的通信。Kubernetes API 文档能够参考官网https://kubernetes.io/docs/re... 为了可扩展性，Kubernetes 在不同的 API 门路（比方/api/v1 或者 /apis/batch）上面反对了多个 API 版本，不同的 API 版本意味着不同级别的稳定性和反对： Alpha 级别，例如 v1alpha1 默认状况下是被禁用的，能够随时删除对性能的反对，所以要慎用Beta 级别，例如 v2beta1 默认状况下是启用的，示意代码曾经通过了很好的测试，然而对象的语义可能会在随后的版本中以不兼容的形式更改稳固级别，比方 v1 示意曾经是稳固版本了，也会呈现在后续的很多版本中。在 Kubernetes 集群中，一个 API 对象在 Etcd 里的残缺资源门路，是由：Group（API 组）、Version（API 版本）和 Resource（API 资源类型）三个局部组成的。通过这样的构造，整个 Kubernetes 里的所有 API 对象，实际上就能够用如下的树形构造示意进去： 从上图中咱们也能够看出 Kubernetes 的 API 对象的组织形式，在顶层，咱们能够看到有一个外围组（因为历史起因，是 /api/v1 下的所有内容而不是在 /apis/core/v1 上面）和命名组（门路 /apis/$NAME/$VERSION）和零碎范畴内的实体，比方 /metrics。咱们也能够用上面的命令来查看集群中的 API 组织模式： [root@k8s-master ~]# kubectl get --raw /{ "paths": [ "/api", "/api/v1", "/apis", "/apis/", ... "/version" ]}比方咱们来查看外围组下的资源对象，同样咱们还是能够通过 kubectl 来查问数据，这外面咱们能够看到外围组上面的资源对象和对应操作 ...

背景常识一般来说，应用K8S部署场景如下： 对源代码进行肯定的品质检测，例如单元测试、代码扫描等。将源代码构建成为可交付的制品，也就是容器镜像。对制品进行测试环境验证。应用实现验证的制品进行线上部署。应用基础设施即代码的形式，在代码库中治理与利用相干的所有YAML文件。上述流动须要有不同角色的参加：开发、测试、运维。如何保障不同参与者能够应用对立的交付流程来进行合作，是云效Flow交付流水线要解决的次要问题。 通过云效继续交付流水线和kubernetes很好的联合在一起，为利用的继续交付提供了很好的根底保障。开发者提交代码变更到代码仓库，云效在监听代码库的变动，一旦代码发生变化，将主动触发云效继续部署流水线一次构建工作的运行，包含代码查看、构建、测试部署、测试验证和生产环境部署等过程。 其中，在构建完之后，生成Docker镜像，并主动上传至利用镜像仓库，在部署阶段时，获取以后流水线实例构建进去的镜像版本，通过kubernetes进行容器编排部署。而这所有，都是通过自动化的伎俩进行实现。 导入示例源代码1.返回：云效代码治理Codeup 超链接： https://codeup.aliyun.com?cha... 2.点击【导入代码库】 抉择【URL导入】，源代码库地址填写： https://code.aliyun.com/flow-...创立流水线1.点击左侧九宫格图标，抉择【流水线】，进入云效流水线。单击右上角新建流水线，进入流水线创立向导页面。抉择模板Java·测试、构建镜像，公布到kubernets集群/阿里云容器服务，并单击创立。配置代码库创立流水线之后会自动弹出增加代码源的窗口，抉择Codeup，代码仓库抉择后面咱们导入的spring-boot勾选【开启代码源触发】，过滤条件填写 .*这样后续master分支一旦进行了批改，将会主动触发流水线构建、测试、部署。 创立镜像仓库在配置云效流水线的镜像构建工作前，须要先创立容器镜像仓库，以便存储镜像。 如果您已有阿里云容器镜像仓库，本步骤能够省略。 返回：阿里云容器镜像服务台，抉择【集体实例】抉择【创立个人版】设置阿里云Docker Registry登录明码，而后单击确定。 设置完明码后，开始创立镜像仓库。留神下方图片中的区域能够自由选择，但在下一步配置云效流水线时须要用到。 如下图，此处咱们抉择华东2（上海）填写命名空间、仓库名称，自定义即可抉择本地仓库，点击【创立镜像仓库】，即可实现镜像仓库的创立 配置流水线构建工作已有容器镜像仓库后，咱们持续来配置云效流水线。如上图，单击【Java 构建Docker镜像并推送镜像仓库】流程配置。 单击开展镜像构建并推送至阿里云镜像仓库，而后单击新建服务受权。批准受权之后，云效流水线Flow会被授予后面的阿里云镜像仓库权限。 在弹出的云资源受权页面单击批准受权。接下来实现区域、仓库的配置。标签填入“${DATETIME}”，示意以流水线触发时的工夫戳作为镜像的标签。Dockerfile门路填入 Dockerfile2 获取kubernetes集群配置文件留神：本步骤所有操作均需新建无痕窗口，并应用第一步创立好的阿里云RAM账号 1.关上浏览器的无痕模式窗口，浏览器地址栏输出 www.aliyun.com Goole Chrome浏览器关上无痕模式的快捷键为Ctrl/Cmd+Shift+N。2.应用左侧云产品资源列表中提供的子用户名称和子用户明码登录阿里云抉择【RAM用户登录】，用户名和明码填写左侧云产品资源的子用户名和子用户明码 持续在无痕窗口内操作，浏览器返回阿里云ACK控制台：https://cs.console.aliyun.com能够看到，已胜利为您创立一台ACK资源。如呈现多台集群，参考云产品资源 k8s实例id 单击控制台左侧导航栏的集群，而后在集群列表中单击详情。在集群详情页中，抉择集群信息 > 连贯信息 > 公网拜访，而后单击复制，将集群配置文件内容保留下来，接下来的云效流水线配置部署工作将会用到集群连贯信息。 配置流水线部署工作1.切回原来的云效流水线配置窗口， 单击kubernets公布工作，进入配置，而后单击新建连贯。 集群类型抉择自定义集群，填写集群名称，而后将步骤二中保留的集群配置文件内容粘贴到集群配置文件文本框中，最初单击保留。YAML门路批改为app-configs/manifest-app。单击增加参数，参数类型抉择上游输入，参数名填入IMAGE，参数值抉择镜像构建并推送到阿里云镜像仓库.镜像VPC地址。*这样在运行时，云效Flow会把YAML门路下的所有文件中的${IMAGE}都替换成镜像的地址，而后再进行kubectl公布。示例代码库中的文件https://code.aliyun.com/flow-...再次单击增加参数，参数类型抉择自定义，参数名称填入HOST，参数值填入ACK集群的测试域名。*这样yaml文件中的${HOST}就会被替换成理论的测试地址。示例代码库中的文件https://code.aliyun.com/flow-... 请参考以下步骤查问集群的测试域名： 返回之前关上的无痕窗口，在集群详情页，单击集群信息 > 根本信息，而后单击复制测试域名，如下图所示。阐明：粘贴时请将测试域名的前缀*.去掉，例如cc96863588562483e873ee0c367a579b5.cn-shanghai.alicontainer.com。 增加参数后的配置页面如下所示。持续点击【增加步骤】，抉择【其余】-【云效经营流动验证】上面的集群连贯须要与上一步kubectl的公布保持一致，如下图，咱们和后面保持一致填入test ，点击保留 运行流水线配置实现后，单击配置页面右上角保留并运行，触发流水线。 拜访SpringBoot示例利用1.集群公布胜利后，点击 Kubectl公布 查看集群公布日志，能够看到公布胜利的HOSTS和ADDRESS地址。2.以管理员身份关上本地C:\Windows\System32\drivers\etc\hosts文件，将Host地址和Address退出hosts文件（两头以空格隔开），如下图所示，最初按下Ctrl+S键保留文件。阐明： Linux和Mac零碎请批改/etc/hosts文件。3.在浏览器关上域名，返回页面如下所示，示意SpringBoot示例利用部署胜利。 批改任意代码，触发继续交付因为咱们在后面开启了代码源触发，所以当检测到master分支有代码进行变更，将会主动触发流水线的运行。 6月9-12日，实现工作即可支付【阿里巴巴研发效力峰会限量版T恤】https://developer.aliyun.com/...

筹备当时筹备好k8s集群,打包你的我的项目并上传到docker仓库 yaml文件k8s的yaml文件能够本人手动写（不举荐），也能够通过kubectl create生成，这里不多说了，网上相干的文章多的是。。。上面是我的yaml文件。 test-deployment.yaml ---apiVersion: apps/v1kind: Deploymentmetadata: name: test-k8s namespace: default labels: cloud-service-module: test app: test-k8sspec: replicas: 3 selector: matchLabels: cloud-service-module: test app: test-k8s template: metadata: labels: app: test-k8s cloud-service-module: test spec: restartPolicy: Always containers: - name: test-k8s image: "test-k8s" # 这里填你本人我的项目的镜像地址 imagePullPolicy: "IfNotPresent" envFrom: - configMapRef: name: test-k8s-configmap ports: - name: tomcat containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 test-configmap.yaml ---apiVersion: v1kind: ConfigMapmetadata: name: test-configmapdata: # 我这里写的是我的项目所须要的环境变量 test_ip: 172.20.151.111 test_port: "5555" # 留神这里的value如果是数字须要加上双引号，否则会报错 test-service.yaml ...

前言为什么prometheus是为云原生监控而生的想必你不止一次的地据说了prometheus是为云原生监控而生的，那你有没有想过这句话意味着什么呢？咱们晓得在云原生中应用容器和k8s环境作为根底运行环境一体化架构被拆分成泛滥扩散的微服务，而微服务的变更和扩缩容是特地频繁的，也就导致采集的指标信息变动频繁。这就给时序监控零碎提出了两个要求： 须要采集运行在跨多个宿主机上的海量pod容器同时要及时感知到他们的变动同时要构建残缺的k8s监控生态，能有其实说白了就是在云原生环境中监控变得更难了，更简单了。所以须要一个在设计之初就适宜云原生监控场景的零碎，而prometheus就是这么设计的。prometheus到底做了哪些改良，能配得上k8 ?k8s中应该关注哪些指标我在上面的表格中简略列举了下咱们在k8s须要关注的四大块指标： 指标类型采集源利用举例发现类型grafana截图容器根底资源指标kubelet 内置cadvisor metrics接口查看容器cpu、mem利用率等k8s_sd node级别间接拜访node_ipk8s资源指标kube-stats-metrics (简称ksm)具体能够看从容器监控kube-stats-metrics看k8s泛滥组件 看pod状态如pod waiting状态的起因 数个数如：查看node pod按namespace散布状况通过coredns拜访域名k8s服务组件指标服务组件 metrics接口查看apiserver 、scheduler、etc、coredns申请提早等k8s_sd endpoint级别部署在pod中业务埋点指标pod 的metrics接口根据业务指标场景k8s_sd pod级别，拜访pod ip的metricspath 适配1. sdk+指标自裸露+pull模型：构建k8s监控的整个生态在下面的列举的表格中咱们看到在k8s须要关注的四大块指标其实咱们能够简略地把k8s的使用者分为两种角色： k8s集群管理员和普通用户。每种角色关注的指标不雷同本人采集岂不累死了？既然需要这么多，如果只是由监控零碎本人采集，第一很累，第二构建不出这么残缺的生态奥秘prometheus是pull模型采集的，各个被监控的源只须要将本身指标裸露在本地http端口中，prometheus就能够拜访接口来采集指标prometheus在k8s中也是这样的，组件须要裸露本身指标，如咱们在容器根底资源指标中提到的kubelet 内置cadvisor指标就是裸露在10250端口下的/metrics/cadvisor下。prometheus通过 k8s服务发现这些指标源实现采集适配2. k8s服务发现举例一、endpoint级别的服务发现 ：举例 在采集apiserver、kube-controller-manager等kubernetes_sd_configs: role: endpoints 二、node级别的服务发现 ：举例 在采集cadvisor和kubelet本身指标时 kubernetes_sd_configs: - role: node 三、node级别的服务发现 ：举例 在采集pod自打点指标时 kubernetes_sd_configs: - role: pod follow_redirects: true解读：watch即时更新通过watch即时发现资源变动，就满足了咱们一开始提出的云原生状况下监控的挑战之一，要及时感知到采集源的变动。同时在k8s大二层环境中，prometheus能够拜访到发现进去的的 endpoint 、node、pod适配3. 采集鉴权：token & 证书k8s中很多接口都要鉴权，甚至还须要tls双向认证同时咱们晓得在k8s中很多接口都是带有拜访鉴权的，比方咱们间接拜访k8s node上的kubelet的/metrics/cadvisor接口会返回未受权。如上面所示[root@Kubernetes-node01 logs]# curl -k https://localhost:10250/metrics/cadvisorUnauthorizedprometheus在采集cadvisor指标时同样面临鉴权问题解决办法聪慧的prometheus开发人员通过在采集中反对配置中相干token和证书来解决这个问题，如上面的配置代表有一个token文件，同时还有一个证书文件。bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/tokentls_config:ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crtinsecure_skip_verify: true咱们在应用k8s时晓得，k8s通过 service account,clusterrolebinding来解决token、证书挂载问题prometheus也是利用了这一点，在创立prometheus容器是相干的service account,clusterrolebinding配置的示例如下：apiVersion: rbac.authorization.k8s.io/v1 # api的versionkind: ClusterRole # 类型metadata: name: prometheusrules:- apiGroups: [""] resources: # 资源 - nodes - nodes/proxy - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: - extensions resources: - ingresses verbs: ["get", "list", "watch"]- nonResourceURLs: ["/metrics"] verbs: ["get"]---apiVersion: v1kind: ServiceAccountmetadata: name: prometheus # 自定义名字 namespace: kube-system # 命名空间---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: prometheusroleRef: # 抉择须要绑定的Role apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects: # 对象- kind: ServiceAccount name: prometheus namespace: kube-system咱们在创立相干prometheus 的statsfulset时须要在prometheus yaml中须要配置对应的serviceAccountNameserviceAccountName: prometheus配置好之后Kubernetes会将对应的token和证书文件挂载到pod中。咱们exec进入prometheus的pod中就能够查看到相干文件在/var/run/secrets/kubernetes.io/serviceaccount/，如下图所示：/ # ls /var/run/secrets/kubernetes.io/serviceaccount/ -ltotal 0lrwxrwxrwx 1 root root 13 Jan 7 20:54 ca.crt -> ..data/ca.crtlrwxrwxrwx 1 root root 16 Jan 7 20:54 namespace -> ..data/namespacelrwxrwxrwx 1 root root 12 Jan 7 20:54 token -> ..data/token/ # df -h |grep servicetmpfs 7.8G 12.0K 7.8G 0% /var/run/secrets/kubernetes.io/serviceaccount/ # 在采集etcd时须要配置相干证书的secret ...

在微服务、云计算和无服务架构时代，了解Kubernetes并且晓得如何应用它是非常有用的。然而，官网的Kubernetes文档对于刚开始接触云计算的用户来说有些难以了解。在本文中，咱们将理解在Kubernetes中的重要概念。在之后的系列文章中，咱们还将理解如何写配置文件、应用Helm作为软件包管理器、创立一个云基础架构、应用Kubernetes轻松编排服务并且创立一个CI/CD流水线来自动化整个工作流。有了这些信息，你能够启动任意品种的我的项目，并且创立一个弱小的基础架构。 首先，咱们晓得应用容器有多种益处，从部署速度的晋升到大规模一致性交付等。即使如此，容器也并非所有问题的解决之道，因为应用容器会带来肯定的开销，比方保护一个容器编排层。所以，你须要在我的项目开始的时候剖析老本/效益。 当初，让咱们开启Kubernetes世界之旅吧！ Kubernetes硬件构造节点 节点是Kubernetes中的worker机器，能够是任何具备CPU和RAM的设施。例如，智能手表、智能手机或者笔记本，甚至是树莓派都能够成为一个节点。当咱们应用云时，节点就是一个虚拟机（VM）。所以，简略来说，节点是繁多设施的抽象概念。这种形象的益处是，咱们不须要晓得底层的硬件构造。咱们只应用节点，这样一来，咱们的基础设施就独立于平台。 集群 一个集群是一组节点。当你将程序部署到集群上时，它会主动将工作调配到各个节点。如果须要更多的资源（简略来讲，咱们须要更多钱），那么集群中将会退出新的节点并且将会主动重新分配工作。 咱们在集群上运行咱们的代码，但咱们不须要关怀具体在哪个节点上运行了哪局部的代码。工作的调配是主动的。 长久卷（persistent volumes） 因为咱们的代码能够从一个节点转移到另一个节点（例如，某个节点没有足够的内存，那么工作将会被从新调度到另一个领有短缺内存的节点上），所以在节点上保留数据容易失落。如果咱们想要永恒保留咱们的数据，咱们应该应用长久卷。长久卷有点相似内部的硬盘，你能够将它插入并在下面保留你的数据。 Google开发的Kubernetes是一个无状态应用程序的平台，其持久性数据存储在其余中央。当这一我的项目倒退成熟之后，许多企业想要在有状态应用程序中应用它，所以开发人员须要增加长久卷治理。如同晚期的虚拟化技术，数据库server通常状况下并不是首要迁徙到新架构下来的server。这是因为数据库是许多应用程序的外围，并且可能蕴含很多重要信息，所以本地数据库系统在虚拟机或物理机中通常规模很大。 所以，问题是，咱们应该什么时候开始应用长久卷？要答复这个问题，首先，咱们应该了解数据库利用的不同类型。 咱们将数据管理解决方案分为以下两类： 垂直伸缩——包含传统的RDMS解决方案，例如MySQL、PostgreSQL以及SQL Server程度伸缩——包含“NoSQL”解决方案，例如ElasticSearch或基于Hadoop的解决方案垂直伸缩解决方案（如MySQL、PostgreSQL以及Microsoft SQL）不应该利用在容器内。这些数据库平台要求高I/O、共享磁盘以及block存储等，并且无奈解决集群内的节点失落，但这一状况经常会产生在基于容器的生态系统内。 对于程度伸缩应用程序（如Elastic、Cassanda、Kafka等）能够应用容器。他们可能接受数据库集群内的节点失落以及数据库利用能够自行复原平衡。 通常状况下，你应该容器化分布式数据库，从而利用冗余的存储技术并且可能解决数据库集群内的节点失落（ElasticSearch是一个很好的例子）。 Kubernetes软件组件容器 古代软件开发的指标之一是保障各类应用程序在雷同的主机或集群上能够彼此隔离。虚拟机是解决该问题的一个计划。但虚拟机须要他们本人的操作系统，所以他们的规模通常是千兆字节。 容器则恰恰相反，它能够隔离应用程序的执行环境但共享底层操作系统。所以，容器就像一个盒子，咱们能够在其中保留所有运行应用程序所须要的：代码、运行时、零碎工具、零碎仓库、设置等。它们通常仅须要几兆字节即可运行，远远少于虚拟机所需资源，并且能够立刻启动。 Pods Pod是一组容器。在Kubernetes中，最小的单位是Pod。一个pod能够蕴含多个容器，但通常状况下咱们在每个pod中仅应用一个容器，因为在Kubernetes中最小复制单位是pod。如果咱们想要为每个容器独自扩容，咱们增加一个容器到Pod中即可。 Deployments Deployment的最后性能是为pod和ReplicaSet（雷同Pod在其中会被复制很屡次）提供申明式更新。应用deployment，咱们能够指定有多少雷同pod的正本应该随时运行。Deployment相似于pod的管理器，它能够主动启动所需数量的pod、监控pod并在呈现故障时从新创立Pod。Deployment极其有用，因为你不须要独自创立和治理每个pod。 咱们通常为无状态应用程序应用deployment。然而，你能够通过给他附加一个长久卷来残存deployment的状态并使其变得有状态。 Stateful Sets StatefulSet 是Kubernetes中的一个新概念并且它是用于治理有状态利用的资源。它治理deployment和一组pod的扩大，并且确保这些pod的程序以及独特性。它与deployment相似，惟一的区别是deployment创立一组任意名称的pod，并且pod的程序对它来说并不重要，而StatefulSet创立的pod都有举世无双的名称以及程序。所以，如果你想为名为example的pod创立3个正本，那么StatefulSet将会创立为：example-0、example-1、example-2。因而，这一创立形式最重要的益处就是你能够通过pod的名称就理解大抵的状况。 DaemonSets DaemonSet能够确保pod运行在集群的所有节点上。如果从集群中增加/移除了一个节点，DaemonSet会主动增加/删除该pod。这对于监控以及日志非常重要，因为你能够监控每个节点并且不须要手动监控集群。 Services Deployment负责放弃一组Pod处于运行状态，那么Service负责为一组Pod启动网络拜访。Services能够跨集群提供标准化的个性：负载平衡、利用间的服务发现以及零宕机应用程序deployment。每个服务都有举世无双的IP地址以及DNS主机名称。能够为须要应用服务的应用程序手动配置相应的IP地址或主机名称，而后流量将会被负载平衡到正确的pod。在内部流量的局部，咱们会理解到更多的服务类型以及咱们如何在外部服务和内部世界间进行通信。 ConfigMaps 如果你想部署到多个环境中，如staging、开发环境和生产环境，bake配置到应用程序中并不是一个好的操作，因为环境之间存在差异性。现实情况下，你会心愿每个部署环境对应不同的配置。于是，ConfigMap应运而生。ConfigMaps能够让你从镜像中解耦配置工件以放弃容器化应用程序的便携性。 内部流量既然你曾经理解运行在集群中的服务，那么你如何获取内部流量到你的集群中呢？有三种服务类型能够解决内部流量：ClusterIP、NodePort以及LoadBalancer。还有第4种解决方案：再增加一个形象层，称为Ingress Controller。 ClusterIP ClusterIP是Kubernetes中默认的服务类型，它能够让你在集群外部与其余服务进行通信。尽管ClusterIP不是为内部拜访而设计的，但只有应用代理进行了一些改变，内部流量就能够拜访咱们的服务。不要在生产环境中采纳这一解决方案，但能够用其来进行调试。申明为ClusterIP的服务不应该能够从内部间接可见。 NodePort 正如咱们在本文第一局部中所看到的那样，pod正在节点上运行。节点能够是各种不同的设施，如笔记本电脑或虚拟机（但在云端运行时）。每个节点有一个固定的IP地址。通过将一个服务申明为NodePort，服务将会裸露节点IP地址，以便你能够从内部拜访它。你能够在生产环境中应用NodePort，但对于领有许多服务的大型应用程序来说，手动治理所有不同的IP地址非常麻烦。 LoadBalancer 申明一个LoadBalancer类型的服务，就能够应用云提供商的LoadBalancer向内部公开。内部load balancer如何将流量路由到服务Pod取决于集群提供程序。有了这个解决方案，你不用治理集群中每个节点的所有IP地址，但你将为每个服务装备一个load balancer。毛病是，每个服务都有一个独自的load balancer，你将依照load balancer实例付费。 这一解决方案实用于生产环境，但它有些低廉。接下来，咱们来看看略微便宜一些的解决方案。 Ingress Ingress不是一个服务，而是一个API对象，它能够治理内部对集群服务的拜访。它作为反向代理和繁多入口点（entry point）进入你的集群，将申请路由到不同的服务。我通常应用NGINX Ingress Controller，它承当了反向代理，同时也作为SSL发挥作用。裸露ingress的最佳生产计划是应用一个load balancer。 借助这一解决方案，你能够应用单个load balancer裸露任意数量的服务，所以你能够让费用放弃在最低水平。 总结在本文中，咱们理解了Kubernetes中的基本概念及其硬件架构。咱们还探讨了不同的软件组件，如Pod、Deployment、StatefulSets以及Services，并且理解了服务与内部世界之间如何进行通信。心愿能够帮忙你再次梳理Kubernetes里盘根错节的组件架构。

大家好，我是小菜，一个渴望在互联网行业做到蔡不菜的小菜。可柔可刚，点赞则柔，白嫖则刚！死鬼~看完记得给我来个三连哦！ 本文次要介绍 k8s中的网络设置 如有须要，能够参考 如有帮忙，不忘 点赞 ❥ 微信公众号已开启，小菜良记，没关注的同学们记得关注哦！ k8s 咱们曾经从 NameSpace、Pod、PodController到Volumn都介绍过了，置信看完的小伙伴们也会很有播种的~那么明天咱们持续来到k8s的课堂，这节咱们将要来说下 k8S 搭建完服务后如何拜访！ 首先咱们要分明什么是Service 和 Ingress。简略来说，这两个组件都是用来做流量负载的。那么什么又是流量负载呢？当咱们在就集群外部曾经通过 pod 部署了咱们的应用服务，那么下一步要干啥？那就是让用户拜访到咱们的应用服务，这个才是最重要的，不然你部署完了，用户却拜访不了，那岂不是无用功~ 一、Service在 k8s 中，pod 是应用程序的载体，咱们能够通过 pod的 IP 来拜访咱们的应用程序，然而咱们曾经分明了 pod 是具备生命周期的，一旦 pod 呈现问题，pod控制器将会将pod销毁进行从新创立。那么这个时候 pod 的Ip就会发生变化，因而利用 pod IP 拜访应用程序的形式间接 pass了，那么为了解决这个问题，k8s 引入了 Service 的资源概念，通过这个资源，能够整合多个pod，提供一个对立的入口地址，通过拜访 Service 的入口地址就能拜访到前面的 pod服务！ Service不是凭空出现的，不晓得你是否还记得 Node 节点上的要害组件 kube-proxy！关键点来了哦~咱们看个老图回顾一下： 这张图有看过之前的博文都不会生疏，是的！kube-proxy 在这外面起到了关键性的作用，每个 Node 节点上都运行着一个 kube-proxy 服务过程，当创立 Service 的时候会通过 api-server 向 etc写入创立的 service 的信息，而 kube-proxy 会基于监听的机制发现这种 Service 的变动，而后 它会将最新的Service信息转换成对应的拜访规定 到这里，应该对Service有个大略的概念，起码晓得了它的用途，接下来咱们无妨更加深刻的理解一下~ 1）工作模式kube-proxy 反对 3 种工作模式，如下： ...

部署 kubectl1.1 获取kubectl[root@master01 ~]# cd /opt/k8s/work[root@master01 work]# wget https://storage.googleapis.co...[root@master01 work]# tar -xzvf kubernetes-client-linux-amd64.tar.gz提醒：本步骤操作仅须要在master01节点操作。1.2 散发kubectl[root@master01 ~]# cd /opt/k8s/work[root@master01 work]# source /root/environment.sh[root@master01 work]# for master_ip in ${MASTER_IPS[@]} do echo ">>> ${master_ip}" scp kubernetes/client/bin/kubectl root@${master_ip}:/opt/k8s/bin/ ssh root@${master_ip} "chmod +x /opt/k8s/bin/*" done提醒：本步骤操作仅须要在master01节点操作。 1.3 创立admin证书和密钥[root@master01 ~]# cd /opt/k8s/work[root@master01 work]# source /root/environment.sh[root@master01 work]# cat > admin-csr.json <<EOF{ "CN": "admin", "hosts": [], "key": { "algo": "rsa", "size": 2048}, "names": [ { "C": "CN", "ST": "beijing", "L": "beijing", "O": "system:masters", "OU": "System" }]}EOF #创立admin的CA证书申请文件提醒：本步骤操作仅须要在master01节点操作。 ...

一、摘要信也容器云平台基于Kubernetes和Docker开发，自2018年底上线以来，总共保护了8套k8s集群，生产接入超过850个利用，全环境实例数达到9000。作为一家金融科技公司，服务稳定性必然是逃不开的话题，本次分享就以集群部署、高可用控制器、监控智能化解决三个局部，为大家介绍容器云在稳定性保障方面的一些教训和思考。 二、集群部署以生产环境为例，咱们有两个机房，每个机房部署了两套K8S集群，同一机房的集群节点数相等。实例通过容器云平台公布，首先依据利用类型和重要水平抉择部署的机房，而后均匀分布于机房内的各个集群，同一集群的实例由kube-scheduler平均调度到各个节点。任何一个节点或者集群挂掉，其余节点和集群上的实例仍旧失常运行，不会影响服务的可用性，最大水平的保障了物理上的高可用。部署架构图如下： 因为存在局部利用发复数实例的状况，这些实例不能相对平均分配，长时间运行下来，会呈现同一机房的某个集群实例数略大于另一个集群的景象，如果不加干预，此集群实例数会越来越多，导致集群整体内存应用偏高，升高集群的稳定性，到前面更会因为集群内存不足而无奈调度。 基于以上起因，咱们开发了一个定时工作，通过Prometheus抓取集群的内存应用数据，判断出负载较低的集群，为该集群设置较高优先级。如此，下一轮的调度如果呈现复数的状况，多进去的一个实例将调度到高优先级的集群。这里算法的根本逻辑为，先判断利用已有实例的集群散布状况，待发布的实例优先调度到已有实例数较少的集群，如果存在多个集群已有实例数相等，优先选择高优先级（负载低）的集群，此算法对多于两个集群的状况同样无效。生产实践下来，该措施使得各个集群的实例数和负载处在同一程度，最大化利用了集群资源，无效进步了集群稳定性。 三、高可用控制器为满足不同的业务场景和公布模式，以及平安上的固定IP需要，信也容器云平台抉择了以Pod为粒度进行实例部署，而没有应用常见的Deployment形式。因为K8S对单个Pod没有提供自愈机制，咱们在容器云平台中应用Java自研了一个高可用控制器，容器和物理机宕机后实例会主动复原。 在具体介绍高可用控制器之前，咱们先来回顾一下就绪探针（Readiness Probe）的概念。就绪探针用于判断容器是否启动实现，即Pod的Condition是否为Ready，如果探测后果不胜利，则会将Pod从Endpoint中移除，直至下次判断胜利，再将Pod挂回到Endpoint上。 基于以上原理，咱们在容器里增加了一个衰弱检测接口作为就绪探针，容器云平台监听Service上面的Endpoints事件，一旦发现Pod状态变为Not Ready，就会对Pod做一个删除和重新部署的操作，操作前后实例IP不变。如下图所示： 当高可用控制器检测到Pod状态变为Ready时，则会依据实例宕机前的流量状态做上线或疏忽解决。如下图所示： 控制器对Endpoints采取监听和轮询两种形式，避免监听时出现异常，确保所有实例状态变更后失去解决。示例代码如下： public void startEventTrigger() { Config config = new ConfigBuilder().withMasterUrl(apiServer).build(); KubernetesClient client = new DefaultKubernetesClient(config); client.endpoints().watch(new Watcher<Endpoints>() { @Override public void eventReceived(Action action, Endpoints endpoints) { for (EndpointSubset endpointSubset : endpoints.getSubsets()) { for (EndpointAddress endpointAddress : endpointSubset.getNotReadyAddresses()) { processNotReadyAddress(endpoints.getMetadata().getName(), endpointAddress); } for (EndpointAddress endpointAddress : endpointSubset.getAddresses()) { processReadyAddress(endpoints.getMetadata().getName(), endpointAddress); } } } @Override public void onClose(KubernetesClientException e) { log.error("事件监听时与apiserver产生链接中断, err=" + e.getMessage(), e); } });}public void startEventPolling() { Config config = new ConfigBuilder().withMasterUrl(apiServer).build(); KubernetesClient client = new DefaultKubernetesClient(config); ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(() -> { EndpointsList endpointsList = client.endpoints().list(); for (Endpoints endpoints : endpointsList.getItems()) { for (EndpointSubset endpointSubset : endpoints.getSubsets()) { for (EndpointAddress endpointAddress : endpointSubset.getNotReadyAddresses()) { processNotReadyAddress(endpoints.getMetadata().getName(), endpointAddress); } for (EndpointAddress endpointAddress : endpointSubset.getAddresses()) { processReadyAddress(endpoints.getMetadata().getName(), endpointAddress); } } } }, 120, 120, TimeUnit.SECONDS);}依据下面的代码能够发现，咱们对Not Ready事件的解决放在了processNotReadyAddress办法中，而对Ready事件的解决则放到了processReadyAddress办法里，这两个办法蕴含了较多的疏忽逻辑，如实例有其余工作正在执行，实例处在静默期（用户刚操作完实例），利用未开启高可用，一段时间内的反复事件，等等，具体细节就不在此处开展了。 ...

前言经验了一周的高强度部署，踩了有数的坑后终于搭起了华为云+阿里云的集群，非常感觉@chen645800876大佬的云服务器-异地部署集群服务这篇文章，能力比较顺利的部署，少踩了很多坑。这次记录是基于大佬文章上，缩小了一些我没有应用的步骤，也把我踩的坑记录一下，做一个备份也心愿能帮忙到其他人。正式装置调整内核参数 cat > k8s.conf <<EOF#开启网桥模式net.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1#开启转发net.ipv4.ip_forward = 1##敞开ipv6net.ipv6.conf.all.disable_ipv6=1EOFcp k8s.conf /etc/sysctl.d/k8s.confsysctl -p /etc/sysctl.d/k8s.confipvs前置条件筹备 # step1modprobe br_netfilter# step2cat > /etc/sysconfig/modules/ipvs.modules <<EOF#!/bin/bashmodprobe -- ip_vsmodprobe -- ip_vs_rrmodprobe -- ip_vs_wrrmodprobe -- ip_vs_shmodprobe -- nf_conntrackEOF# step3chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack这个中央须要留神一下的是原文中模块nf_conntrack_ipv4曾经没有应用了，解决办法是上面链接提出的计划，这个中央十分重要，如果抛错的话，前面ipvs转发会有问题https://github.com/easzlab/ku... 敞开swap分区 swapoff -aKubeadm、Kubelet、Kubectl装置 # 增加源cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/#baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64/#如果是处理器不是amd的话就须要用到另外一个版本 华为鲲鹏型的就是aarch64 而阿里的是x86_64#这个还有个老手小坑，就是docker的镜像也跟处理器版本无关。x86_64上打的包，aarch64的docker就不能公布，如果遇到pod公布不胜利有可能是这个问题enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF# 敞开selinuxsetenforce 0# 装置kubelet、kubeadm、kubectlyum install -y kubelet kubeadm kubectl# 设置为开机自启systemctl enable kubelet 建设虚构网卡 ...

一、背景最近在公司迁徙存量零碎到k8s集群，经理解，k8s集群反对对每个利用的资源应用进行限度，以防止某个利用有限应用内存或者过高CPU导致整个集群故障。因而尝试对现有正在运行的高并发的零碎进行资源限度革新，通过实际，最终发现该个性如设置不当，会给利用零碎带来劫难。二、应用环境1、Docker版本rke@k8s-master-dev-1:~$ docker -vDocker version 18.06.0-ce, build 0ffa8252、K8s版本 root@k8s-master-dev-1:~# su - rkerke@k8s-master-dev-1:~$ kubectl versionClient Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:52:00Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.14", GitCommit:"89182bdd065fbcaffefec691908a739d161efc03", GitTreeState:"clean", BuildDate:"2020-12-18T12:02:35Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}rke@k8s-master-dev-1:~$ 三、问题景象1、在k8s进行如下配置图一图二设置的内存初始值为512M，最大值设置为4500M（因为jvm限度了最大内存应用为4096M，这外面预留一部分给操作系统和其余程序）设置的CPU初始值为100mi，最大值设置为500mi2、问题景象(1)、利用卡顿，有时能够关上页面，有时打不开页面经排查是因为CPU限度导致，去掉该配置，利用恢复正常(2)、程序运行每隔20到30分钟会一直重启pod，中断业务应用经排查操作系统日志，发现POD产生OOM，被操作系统（oom-killer）KILLMay 11 15:29:12 k8s-node-prod-3 kernel: [18750.337581] java invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=969May 11 15:29:12 k8s-node-prod-3 kernel: [18750.337621] oom_kill_process.cold.30+0xb/0x1cf四、问题总结1、CPU尽量不要限度大小，应充分发挥其个性2、对JAVA利用应应用-xms和-xmx设置最小和最大内存，最好不须要在k8s下面设置内存限度，否则因为设置的太小或者不到位，对业务产生影响JAVA_OPTS="$JAVA_OPTS -server -Xms4096M -Xmx4096M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true"3、实际出真谛，生产无小事，审慎看待和评估每个配置改变对生产业务的影响。

一、背景 最近在公司实际DevOps(开发、运维一体化)的流程落地，并且将原先的Docker Swarm集群迁徙到K8s集群。碰到原先集群的健康检查与现有集群的健康检查存在不统一的中央，在这里做个总结。二、原理及必要性利用健康检查，顾名思义，是对利用现有状况（包含数据库、缓存、及Socket连贯）进行查看，以让集群调度管理器发现利用的存活状况，从而对利用进行管控（从新调度调配，可重启，调度到其余节点等）,特地针对稳定性要求高（业务不能中断），部署机制灵便（反对滚动公布，在部署过程中不中断利用，从而不影响业务应用）三、实际1、原先DockerSwarm集群健康检查机制是通过在Dockerfile中指定Docker的health check地址，如下：健康检查HEALTHCHECK --interval=120s --timeout=5s CMD curl --fail http://localhost:8080/api/pub... || exit 12、利用/api/public/health/check的逻辑（示例）：（1）控制器如果检测不通过，须要在httpServletResponse返回非200的错误码，以让集群判断http调用异样（2）服务解决2、当初新的K8s集群健康检查配置(1）删除原先的Dockerfile中健康检查的调用代码，此形式在新的k8s集群不失效(2) 如上图配置就绪状态查看策略该策略可用于判断利用是否已启动，并且能失常受理业务，依据利用启动状况进行配置，以秒为单位 (3) 如上图配置存活状态查看策略该策略配置可用于集群判断利用是否存活，并且能失常受理业务，依据利用理论状况进行配置，以秒为单位

简介： 台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。![上传中...]() 作者 | 韩堂、柘远、陶醉起源 | 阿里巴 前言台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江湖”的那种触目惊心以及它那生态系统的繁花似锦，该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的！在 K8s 高可用畛域有一个问题被大家所熟知，那就是 K8s 单集群规模带来的 SLO 问题，如何继续保障？明天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。ASI 单集群规模撑持超过社区的 5000 台，这是个十分有意思且具备极大挑战的事件，对须要进行 K8s 生产化的同学，甚至具备 K8s 生产化教训的同学来说，肯定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的倒退之路，随同着业务的增长和翻新带来的每一次集群规模增长，都在逐渐使咱们的压力和挑战产生量变。 ASI：Alibaba Serverless infrastructure，阿里巴巴针对云原生利用设计的对立基础设施，ASI 是阿里公共云服务 ACK 的阿里团体企业版。 大家晓得 K8s 社区只可能撑持五千个节点，当超过这个规模时，会呈现各种性能瓶颈问题，比方： etcd 呈现大量的读写提早。kube-apiserver 查问 pods/nodes 延时很高，甚至导致 etcd oom。控制器无奈及时感知数据变动，如呈现 watch 数据提早。以电商场景为例，100 节点增长到 4 千节点的时候，咱们提前针对 ASI apiserver 的客户端和服务端做了大量的性能优化，从 apiserver 客户端的角度优先拜访本地 cache，在客户端去做负载平衡；apiserver 服务端次要做了 watch 优化和 cache 索引优化；在 etcd 内核上利用并发读晋升单 etcd 集群读解决能力，基于 hashmap 的 freelist 治理新算法进步 etcd 存储下限，基于 raft learner 技术来进步多备能力等等。从 4 千节点增长到 8 千节点，咱们又做了 qps 限流治理和容量治理优化、etcd 单资源对象存储拆分、组件标准全生命周期落地通过客户端的标准束缚升高对 apiserver 的压力和以及穿透到 etcd 的压力等等。终于迎来 8 千节点增长到上万节点的时刻，咱们开始热火朝天地发展 etcdcompact 算法优化；etcd 单节点多 multiboltdb 的架构优化，apiserver 的服务端数据压缩，通过组件治理升高 etcd 写放大等；同时开始打造常态化的压测服务能力，继续答复 ASI 的 SLO。这些例子在高可用挑战中司空见惯，列出的能力也只是其中一小部分，你兴许很难看到能力之间的关联和底层的演进逻辑。当然，更多的能力建设积淀到了咱们的零碎和机制当中。本篇文章会作为一个开始，以综述的模式分享咱们在建设 ASI 全局高可用体系中的几个要害局部，再往后会有针对性地对进行技术点和演进路线的详解。如果大家有什么问题或者心愿理解的局部，欢送在评论区留言。 ...

Kubernetes中的失常敞开和零停机部署TL; DR： 在本文中，您将学习如何在Pod启动或敞开时避免断开的连贯。您还将学习如何失常敞开长时间运行的工作。 Kubernetes中的失常敞开和零停机部署您能够在此处以PDF格局下载此便捷图表。 在Kubernetes中，创立和删除Pod是最常见的工作之一。 当您执行滚动更新，扩大部署，每个新发行版，每个作业和cron作业等时，都会创立Pod。 然而在驱赶之后，Pods也会被删除并从新创立-例如，当您将节点标记为不可调度时。 如果这些Pod的性质是如此短暂，那么当Pod在响应申请的过程中却被告知敞开时会产生什么呢？ 申请在敞开之前是否已实现？ 接下来的申请呢，那些申请被重定向到其余中央了吗？ 在探讨删除Pod时会产生什么之前，有必要讨论一下创立Pod时会产生什么。 假如您要在集群中创立以下Pod： pod.yaml apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: web image: nginx ports: - name: web containerPort: 80您能够应用以下形式将YAML定义提交给集群： 重击 kubectl apply -f pod.yaml输出命令后，kubectl便将Pod定义提交给Kubernetes API。 这是旅程的终点。 在数据库中保留集群的状态API接管并查看Pod定义，而后将其存储在数据库etcd中。 Pod也将增加到调度程序的队列中。 调度程序： 查看定义收集无关工作负载的详细信息，例如CPU和内存申请，而后确定哪个节点最适宜运行它（通过称为过滤器和谓词的过程）。在过程完结时： 在etcd中将Pod标记为Scheduled。为Pod调配了一个节点。Pod的状态存储在etcd中。然而Pod依然不存在。 调度程序为该Pod调配最佳节点，并且Pod的状态更改为Pending。 Pod仅存在于etcd中。3 /3 以前的调度程序为该Pod调配最佳节点，并且Pod的状态更改为Pending。Pod仅存在于etcd中。 先前的工作产生在管制立体中，并且状态存储在数据库中。 那么谁在您的节点中创立Pod？ Kubelet-Kubernetes代理kubelet的工作是轮询管制立体以获取更新。 您能够设想kubelet一直地向主节点询问：“我关照工作节点1，是否对我有任何新的Pod？”。 当有Pod时，kubelet会创立它。 有点。 kubelet不会自行创立Pod。而是将工作委托给其余三个组件： 容器运行时接口（CRI） -为Pod创立容器的组件。容器网络接口（CNI） -将容器连贯到群集网络并调配IP地址的组件。容器存储接口（CSI） -在容器中装载卷的组件。在大多数状况下，容器运行时接口（CRI）的工作相似于： 重击docker run -d <my-container-image>容器网络接口（CNI）有点乏味，因为它负责： 为Pod生成无效的IP地址。将容器连贯到网络的其余部分。能够设想，有几种办法能够将容器连贯到网络并调配无效的IP地址（您能够在IPv4或IPv6之间进行抉择，也能够调配多个IP地址）。 例如，Docker创立虚构以太网对并将其连贯到网桥，而AWS-CNI将Pods间接连贯到虚构公有云（VPC）的其余部分。 当容器网络接口实现其工作时，该Pod已连贯到网络的其余部分，并调配了无效的IP地址。 只有一个问题。 Kubelet晓得IP地址（因为它调用了容器网络接口），然而管制立体却不晓得。 没有人通知主节点，该Pod已调配了IP地址，并且曾经筹备好接管流量。 就管制立体而言，仍在创立Pod。 kubelet的工作是收集Pod的所有详细信息（例如IP地址）并将其报告回管制立体。 ...

Flink作为大数据和实时数据部门重要的框架和引擎，扮演着重要的角色，Flink的应用也越来越多，集群治理也变得越来越不容易。为了反对Flink上云，容器云团队也对其做了大量的摸索工作，以保障Flink可能更好的且安稳的进行容器化。 一：部署形式抉择目前信也上云的Flink版本是Flink 1.11，Flink 1.11基于kubernetes的部署模式有：Session、Per-job、Application三种模式，上面阐明三种部署模式的比照 这三种模式的区别在于： 集群生命周期和资源隔离保障应用程序的main()办法是在客户端还是在集群上执行 图：1-1 Application模式用户程序的 main 办法将在集群中而不是客户端运行，用户将程序逻辑和依赖打包进一个可执行的 jar 包里，集群的入口程序 (ApplicationClusterEntryPoint) 负责调用其中的 main 办法来生成 JobGraph。Application 模式为每个提交的应用程序创立一个集群，该集群能够看作是在特定应用程序的作业之间共享的会话集群，并在应用程序实现时终止。在这种体系结构中，Application 模式在不同利用之间提供了资源隔离和负载平衡保障。在特定一个应用程序上，JobManager 执行 main() 能够节俭所需的 CPU 周期，还能够节俭本地下载依赖项所需的带宽。 Per-Job 模式per-job模式是为每个提交的作业启动Flink集群，领有本人的jobmanager和taskmanager。所以在启动的时候该作业模式可能提早会比拟高点。作业实现后，集群将销毁，并清理所有的资源。此模式容许更好的资源隔离，因为运行有问题的作业也不会影响到其它作业。 Session模式session模式假设一个曾经在运行的集群，并应用该集群的资源来执行任何提交的应用程序。在同一个（会话）集群中执行的应用程序应用雷同的资源，并因而竞争雷同的资源。你并没有为每一项工作付出全副的开销。然而，如果其中一个作业行为不当或导致TaskManager解体，则该TaskManager上运行的所有作业都将受到该故障的影响。除了对导致失败的作业造成负面影响外，这意味着一个潜在的大规模复原过程，即所有重新启动的作业同时拜访文件系统，并使其对其余服务不可用。另外，让一个集群运行多个作业意味着JobManager的负载更大，JobManager负责记录集群中的所有作业。这种模式非常适合于启动提早十分重要的短作业，例如交互式查问。 目前信也科技在服务的容器化方面的反对曾经很成熟，有一套欠缺的构建公布流程，所以通过比照Flink的几种部署模式的优缺点，最终咱们采纳了Application的部署形式，该形式相比于其它两种模式长处显著，领有更好的隔离性，同时对资源的利用率也高，也更合乎咱们现有的公布流程标准。二：Flink on k8s 图：2-1 创立Flink Kubernetes集群时，Flink客户端将首先连贯到Kubernetes ApiServer提交集群，包含ConfigMap，Job Manager。而后，Kubernetes将创立JobManager，在此期间，Kubelet将拉取镜像，筹备并挂载，而后执行启动命令。启动JobManager命令后，Dispatcher和KubernetesResourceManager可用，并且群集已筹备好承受一个或多个作业。当用户通过Flink客户端提交作业时，客户端将生成 Job graph ，并将其与用户jar一起上传到Dispatcher。JobManager向KubernetesResourceManager申请slots资源。如果没有可用的slots，资源管理器生成TaskManager并在集群中注册。这是Flink 在在kubernetes外部的简要交互方式。 三：构建公布信也采纳的Flink版本为1.11,部署模式是Application。咱们把每个job形象成一个利用。所以每个job的公布流程也就是信也一般利用一样的公布流程: 申请Flink job相干的利用非1.11版本的job降级到1.11版本，并集成maven 镜像构建打包插件通过aladdin打包平台，打包镜像。通过stargate平台抉择相应利用和打包的镜像版本进行job的公布1.构建 图：3-1 2.公布 图：3-2 在程序进行降级的时候，进行job能够采纳savepoint的机制来放弃作业的残缺快照，在下次启动的时候能够利用保留的savepoint来进行作业的复原四：监控告警Flink部署在kubernetes上后，job的监控和运维也须要相应的配套设施才行。 当Flink job在运行过程中挂掉了，咱们怎么能力监控到并产生告警？job在运行过程中可能会呈现不衰弱的运行，比方checkpoint工夫过长、gc频繁、或者产生了重启。这些咱们又如何监控？ 1. 配置探针Flink job在运行过程中由jobmanager进行资源管理、作业调度，所以咱们为每个Flink job中的jobmanager增加探针，检测job是否失常运行，当衰弱检测不通过，咱们通过zmon平台进行告警 readinessProbe: httpGet: path: /jobs/overview port: 8081 scheme: HTTP initialDelaySeconds: 30 timeoutSeconds: 3 periodSeconds: 5 successThreshold: 3 failureThreshold: 122.指标收集目前公司上云的利用都是采纳prometheus进行指标进行收集，所以Flink的指标收集咱们依然采纳prometheus进行收集。利用grafana进行展现（下图进展现局部） ...

根底指令 通过yaml文件创建kubectl create -f xxx.yml **更新时须要先delete**kubectl apply -f xxx.yml **创立和更新可重复使用**通过delete删除kubectl delete -f xxx.yml查看pod形容kubectl describe pod xxx -n kube-system查看pod日志kubectl logs xxx -n kube-system删除利用kubectl delete deployment xxx -n kebe-system删除标签kebectl delete pod -l app=www -n kube-system扩容kubectl scale deployment nginx-deployment --replicas=8配置相干 导出代理配置 kubectl get ds -n kube-system -l k8s-app=kube-proxy -o yaml>kube-proxy-ds.yaml导出kube-dns kubectl get deployment -n kube-system -l k8s-app=kube-dns -o yaml >kube-dns-dp.yaml　kubectl get services -n kube-system -l k8s-app=kube-dns -o yaml >kube-dns-services.yaml导出configmap kubectl get configmap -n kube-system -o wide -o yaml > configmap.yaml 集群相干 ...

简介：埃森哲作为寰球当先的业余服务公司，在数字化、云计算等畛域领有寰球当先的能力，咱们在多年的理论客户我的项目中，找到并积淀出了适宜企业数字化转型的方法论，积攒了丰盛的落地教训。 作者：姚迪、周警伟 随着国家新基建步调的疾速迈进，企业客户正在放慢建设合乎本人业务场景的新型基础设施体系。数字化转型成为企业在以后新基建背景下的一道必考题，但因为因为短少数字化转型的整体规划计划和卓有成效的形式办法和落地教训，很多企业往往找不到数字化转型的要害答案。 埃森哲作为寰球当先的业余服务公司，在数字化、云计算等畛域领有寰球当先的能力，咱们在多年的理论客户我的项目中，找到并积淀出了适宜企业数字化转型的方法论，积攒了丰盛的落地教训。 埃森哲携手阿里云，基于K8s容器云服务，为企业量身定制了数字化转型的解决方案，为业务场景赋能。如果把企业客户比喻成航行在大海里的货轮，埃森哲和阿里云携手打造的这场数字化转型盛宴，就像是大海里的灯塔，为企业客户指明了通往新基建的航线。 上图是某衰弱产品行业客户应用阿里云K8s容器云服务、采纳埃森哲数字化营销解决方案的一个示例，埃森哲通过在数字化营销畛域积攒的多年行业教训，能够为客户提供该畛域的整体解决方案，并领有一套曾经被验证可能领导落地的要害动作。 埃森哲凭借在数字化营销畛域积攒的客户教训和对行业个性的独特了解，联合埃森哲的数字化转型方法论，为客户带来了外围业务的改革，帮忙客户驱动外围业务增长，通过发现和激活新的需要，来扩大新的业务场景，获取新的价值增长点，更好的服务消费者。 同时，该解决方案借助阿里云K8s容器云服务提供的有限弹性计算的能力，在客户利用的部署上，提供更加正当和智能化的计算资源调度，更加细颗粒度的计算资源分配，让客户的利用能够实现随时随地的按需扩缩容。 从节约老本上来看，埃森哲的数字化营销解决方案因采纳了阿里云K8s容器云服务，帮忙客户将基础设施建设的老本升高了30%，运维人员的应用老本升高了50%。 从进步营销能力上来看，该解决方案可能齐全满足客户在业务顶峰时对计算资源的要求，进而帮忙客户在数字化营销中取得更大的收益。 埃森哲数字化营销计划带来的外围业务价值： 价值体现: · 提供丰盛的集体画像性能，360度展现客户信息，让企业更理解客户· 基于标签、行为进行灵便的客户分群，并进行客群剖析、辅助销售· 让营销数字化、自动化，流动施行更高效· 全渠道接入、触达，全场景笼罩与客户的互动· 基于精准人群的精准营销，晋升营销效率和成果· 营销洞察、精准评估营销ROI，为后续流动提供决策反对 如下图所示，阿里云K8s容器云服务作为整体技术解决方案的底座，为客户提供对立的基础架构平台。在此之上，客户依照云原生的理念构建对立的数据集成开发平台、利用开发平台、数字化营销中台，通过体验统一的利用部署模式，更好的反对业务平滑稳固。 阿里云K8s容器云服务为客户提供了三种不同的云原生服务类型，别离是ACK专有版、ACK托管版，和ASK。ACK能够满足客户心愿自行保护和管制Kubernetes集群的需要。而阿里云ACK托管版将由阿里云团队保护和管制Kubernetes集群，客户不用关怀底层运维、降级的工作。ASK（Serverless Kubernetes）则为客户提供了一种在不须要自行创立和保护Kubernetes集群的根底上，仍然能通过Kubernetes集群运行本人应用程序的形式。 在抉择阿里云ACK的专有版或托管版的状况下，客户须要首先为运行的利用布局计算资源，以此来确定须要的ECS服务器数量，特地是还要思考为了有可能呈现的业务顶峰而提前预留一部分ECS服务器资源。这样，当零碎经验流量顶峰的时候，ACK能够有足够的计算资源来弹性的程度扩大利用数量，以此承接更多的流量申请。 也能够采纳ACK对接ECI，也就是弹性容器实例，来部署利用，在不提前为流量顶峰预留ECS服务器的状况下，依然能确保弹性计算的要求。当利用经验流量顶峰的时候，能够弹性的将利用程度扩大到ECI来承接流量。 不仅是ACK，ECI同样反对与自建的Kubernetes集群对接。不论抉择在阿里云的ECS服务器上自建Kubernetes集群，还是在客户本人的数据中心自建Kubernetes集群，都能够通过Virtual Kubelet来对接阿里云ECI，通过ECI承载所有的弹性工作负载，带给客户极致的弹性计算体验。当业务流量降落后，Kubernetes集群能够疾速开释部署在ECI上的利用从而升高您的应用老本。 当客户抉择阿里云ASK(Serverless Kubernetes)来部署利用的时候, 甚至不须要提前布局服务器，只须要通知ASK每个Pod所需的计算资源，ASK就会通过对接ECI来运行利用。 如下图所示，例如托管业务的突发流量，以IoT和视频录播为代表的事件流解决，线上和线下Job、CI/CD的构建和部署，以及大数据和机器学习的工作负载，都能够将这些类型的工作通过ASK或者ACK甚至独自部署在ECS或者IDC上Kubernetes集群与ECI对接，实现工作负载的有限扩容。 咱们发现，过来的20年间IT的技术演变，大抵经验了三个时代。 第一个时代是以Sun+WinTel为行业首领的物理机阶段，这个阶段的利用大多数都是企业软件，它们服务着百万级的企业用户，应用一体式的架构，服务器集中在客户本人的数据中心。服务不好扩大，计算资源没有能力做到细颗粒度的划分。 第二个时代是以VMware和各大云厂商为行业首领的虚拟机阶段，这个阶段因为互联网的疾速倒退和手机利用的呈现，Web利用和SaaS化利用成为了要害的利用状态，他们服务着上亿级的互联网用户，应用的是虚拟化架构，这个阶段的利用散布在数据中心和云上，虚拟化技术能够为利用带来更好的计算资源分配和应用。 第三个时代是眼下正在蓬勃发展的云原生阶段，这个阶段多种技术状态，例如IoT、AI、边缘计算，通过分布式的架构服务着规模超过万亿级的用户。容器技术和Kubernetes成为了云原生畛域的要害代表，为服务带来了灵便的弹性计算能力，和更加细颗粒度的计算资源分配和调度。 2021年将会是云原生减速企业数字化转型的要害年，阿里巴巴通过过来15年云原生实际的积攒，正在帮忙企业充沛享受云原生所带来的价值，为企业数字化转型注入了源源不断的能源。Gartner报告曾指出，到2022年，75%的全球化企业将在生产环境中应用云原生技术来构建本人的利用。 埃森哲作为业余服务畛域的寰球翘楚，凭借多年积淀的行业教训，与阿里云云原生完满联合，正在为企业数字化转型构建原文链接本文为阿里云原创内容，未经容许不得转载。

本文首发于 Nebula Graph 公众号：Nebula Operator 开源啦！一文详解这个云上自动化部署集群管理工具在介绍 Nebula Operator 之前，让咱们先来理解下什么是 Operator。 Operator 是一种封装、部署和治理 Kubernetes 利用的办法，通过扩大 Kubernetes API 的性能，来治理用户创立、配置和治理简单利用的实例。它基于自定义资源 CRD 和控制器概念构建，涵盖了特定畛域或利用的常识，用于实现其所管理软件的整个生命周期的自动化。 在 Kubernetes 中，管制立体的控制器施行管制循环，重复比拟集群的冀望状态和理论状态。如果集群的理论状态与冀望状态不符，控制器将持续协调外部业务逻辑直到利用更新为冀望状态。 Nebula Operator 将 NebulaGraph 的部署治理形象成自定义资源 CRD，通过 StatefulSet、Service、ConfigMap 等多个内置的 API 对象组合在一起，把日常治理保护 Nebula Graph 的流程编写成管制循环，当 CR 实例提交时，Nebula Operator 依照管制流程驱动数据库集群向终态转移。 Nebula Operator 性能介绍CRD 定义上面联合部署 nebula 集群的 CR 文件，来理解下 Nebula Operator 的外围性能。 apiVersion: apps.nebula-graph.io/v1alpha1kind: NebulaClustermetadata: name: nebula namespace: defaultspec: graphd: resources: requests: cpu: "500m" memory: "500Mi" replicas: 1 image: vesoft/nebula-graphd version: v2.0.0 storageClaim: resources: requests: storage: 2Gi storageClassName: gp2 metad: resources: requests: cpu: "500m" memory: "500Mi" replicas: 1 image: vesoft/nebula-metad version: v2.0.0 storageClaim: resources: requests: storage: 2Gi storageClassName: gp2 storaged: resources: requests: cpu: "500m" memory: "500Mi" replicas: 3 image: vesoft/nebula-storaged version: v2.0.0 storageClaim: resources: requests: storage: 2Gi storageClassName: gp2 reference: name: statefulsets.apps version: v1 schedulerName: default-scheduler imagePullPolicy: IfNotPresentspec 里须要重点关注三个形容局部：graphd、metad、storaged，他们别离示意 Graph 服务、Meta 服务、Storage 服务，控制器会在协调循环里顺次查看内置的 API 对象 StatefulSet、Service、ConfigMap 是否就绪，如果某个依赖的 API 对象没有创立胜利或者某个 Nebula Graph 组件服务协调异样，控制器就会完结返回，期待下一次协调，并反复这个过程。 ...

简介： 怎样才能在简单的大规模场景中，做到真正先于用户发现问题呢？上面我会带来咱们在治理大规模 ASI 集群过程中对于疾速发现问题的一些教训和实际，心愿能对大家有所启发。 作者 | 彭南光（光南）起源 | 阿里巴巴云原生公众号 千里之堤，溃于蚁穴。 绪论 不晓得大家是否经验过这样的情景：忽然被用户告知零碎呈现问题，而后一脸懵地惶惶然排查修复；或是等到本人发现零碎呈现故障时，理论曾经对用户造成了重大的恶劣影响。 所谓千里之堤，溃于蚁穴。用户信赖的建设是长期而艰巨的，然而要捣毁这种信赖却很简略。一旦呈现上述问题，不仅极大影响用户应用体验，同时会给用户留下一个这个产品/团队不牢靠的印象，丢失用户对产品/团队长期好不容易积攒下来的信用资本，将来再想建设这样的信赖关系就很难了。 这也是为什么咱们说疾速发现问题的能力如此重要的起因，只有先做到疾速发现问题，能力谈怎么排查问题、如何解决问题。 那么怎样才能在简单的大规模场景中，做到真正先于用户发现问题呢？上面我会带来咱们在治理大规模 ASI 集群过程中对于疾速发现问题的一些教训和实际，心愿能对大家有所启发。 注：ASI 是 Alibaba Serverless infrastructure 的缩写，是阿里巴巴针对云原生利用设计的对立基础设施。有趣味能够浏览：《揭开阿里巴巴简单工作资源混合调度技术面纱》。 背景 1. 简单的场景和曾面临的窘境 咱们所治理的大规模 ASI 集群场景非常复杂，这为咱们的工作带来了极大挑战，任何一个场景解决不慎就有可能导致意料之外的挫伤扩大化。 从组件维度看，咱们目前有几百个组件，每年有几万次的组件变更。频繁的组件变更如何在稳定性和效率之间获得衡量，怎么让变更时更稳固，怎么让灰度更确信，从而升高爆炸半径？ 从集群维度看，目前有上千个集群和海量节点，碰到的集群/节点问题较多，监控链路笼罩比拟简约，怎么让集群运行时更加可信? 从二方用户和业务场景看，咱们反对了大量的团体二方用户，同时业务场景也非常复杂，怎么保障各有特色的业务场景都能失去统一的仔细关照? 2. 问题预判和解决思路 基于长期的集群治理教训，咱们有如下预设： 数据监控作为正向链路，无奈无死角笼罩所有场景。即便链路中各个节点的监控数据失常，也不能 100% 保障链路可用。 集群状态每时每刻都在变动，各个组件也在不停地更新降级，同时链路上的每个零碎也在不停的变更，监控数据的笼罩永远是正向的追赶，只能迫近 100% 全笼罩而无奈齐全达到。 即便整个集群链路中所有组件/节点的监控数据都失常，也不能保障集群链路 100% 可用。就如同业务零碎一样，看上去都是可用的，没有问题裸露。但只有通过全链路压测理论探测过整个链路后，能力失去理论可用的论断。 你要正向证实一个货色可用，须要举证有数的例子。而如果要反向证实不可用，一个反例就够了。数据监控链路只能迫近全笼罩，而无奈保障真正全笼罩。大规模场景下，数据无奈达到 100% 的齐全一致性。 当集群规模足够大时，数据的一致性问题将会更加浮现。比方全局风控组件是否全集群链路笼罩？相干流控配置是否全集群链路推平？pod 主容器时区是否与下层统一？集群客户端节点证书是否有行将过期？等等问题，一旦忽略，将有可能酿成重大的故障。 只有补救上述两类危险点，能力有底气真正做到先于用户发现问题。咱们解决上述两类危险的思路别离是： 黑盒探测 所谓黑盒探测，既模仿狭义上的用户行为，探测链路是否失常。定向巡检 所谓巡检，既查看集群异样指标，找到已有或可能将存在的危险点。基于以上思路，咱们设计并实现了 KubeProbe 探测/巡检核心，用于补救简单零碎的正向监控的有余，帮忙咱们更好、更快地发现零碎危险和线上问题。 设计 黑盒探测和定向巡检 1）黑盒探测 不晓得你是否也经验过一条链路上各个系统监控数据都失常，然而理论链路流程就是跑不通。或者因为零碎变动快，监控笼罩不到 100% 的场景总是会有脱漏，导致影响到了用户却没有报警，对用户没有本质影响却报警频发从而疲于奔命。 如果一个零碎开发者本人都不应用本人的零碎，那么怎么可能先于用户发现零碎问题呢？所以要先于用户发现零碎问题，首先咱们本人就得先成为用户，而且肯定是应用最多，理解最深，无时无刻不在应用和感知零碎情况的用户。 所谓黑盒探测，就是让本人成为本人的用户，模仿狭义"用户"的行为去对集群/组件/链路期待待测对象做探测。留神，这里的"用户"并不仅仅是广义上应用零碎的同学，而是狭义用户。比方，etcd 的"用户"是 APIServer，而 ASI 的"用户"可能是某个通过 APIServer 操作集群的同学，也可能是 Normandy 发动的公布/扩容/缩容操作。 ...

【前言】本文介绍了Kubernetes基于Centos7构建根底环境，作者：姜新灿（同创永益架构总监）。 环境筹备 筹备一台虚拟机，请参照《Kubernetes基于Centos7构建根底环境（一）》 一、 查看是否之前装置过docker，如果有则革除docker环境 二、 装置yum、docker环境依赖 见到Complete!，则装置胜利 三、 配置docker源 四、 装置docker-ce-cli客户端、docker-ce服务端 见到Complete!，则装置胜利 五、 将以后用户增加到docker用户组 vagrant为登录用户名称，依据本人机器登录名称设定 六、 设置docker镜像下载源，指定cgroup驱动 查看/etc/docker下是否有daemon.json文件，如果有手动批改，如果没有则间接执行如下命令 查看daemon.json是否存在，我这里不存在，执行第2步减少docker配置减少docker配置，并查看配置https://1mbc3b4s.mirror.aliyu... 阿里云镜像地址 如果之前启动过docker,批改实现之后须要重启 sudo systemctl daemon-reload && sudo systemctl restart docker 七、 启动docker 八、 查看docker是否装置胜利 这里能够看到docker的版本为19.03.11，减少了docker0网络 九、 设置docker开机启动 十、 装置docker-compose（墙裂倡议） docker-compose装置文档地址：https://docs.docker.com/compo... 下载docker-composesudo curl -L "https://github.com/docker/compose/releases/download/1.26.0/docker-compos e-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose 赋予docker-compose权限sudo chmod +x /usr/local/bin/docker-compose 增加docker-compose软连贯sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose 装置docker-compose（墙裂倡议） 装置bash-completionyum install -y bash-completion 赋予docker-compose权限sudo chmod +x /usr/local/bin/docker-compose 增加docker-compose软连贯sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose ...

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 对应的自定义资源，在对应资源发生变化时，触发自定义的逻辑。 Operator 开发者能够像应用原生 API 进行利用治理一样，通过申明式的形式定义一组业务利用的冀望终态，并且依据业务利用的本身特点进行相应控制器逻辑编写，以此实现对利用运行时刻生命周期的治理并继续保护与冀望终态的一致性。 艰深的了解 CRD是K8s标准化的资源扩大能力，以java为例，int、long、Map、Object是java内置的类，用户能够自定义Class实现类的扩大，CRD就是K8s中的自定义类，CR就是对应类的一个instance。 Operator模式 = 自定义类 + 观察者模式，Operator模式让大家编写K8s的扩大变得非常简单快捷，逐步成为面向K8s设计的规范。 Operator提供了标准化的设计流程： 应用 SDK 创立一个新的 Operator 我的项目通过增加自定义资源（CRD）定义新的资源 API指定应用 SDK API 来 watch 的资源自定义Controller实现K8s协调（reconcile）逻辑有了锤子，看到的只有钉子咱们团队（KubeOne团队）始终在致力于解决简单中间件利用如何部署到K8s，天然也是Operator模式的践行者。经验了近2年的开发，初步解决了中间件在各个环境K8s的部署，以后两头也走了很多弯路，踩了很多坑。 KubeOne内核也经验3个大版本的迭代，前2次开发过程根本都是follow Operator规范开发流程进行开发设计。遵循一个规范的、典型的Operator的设计过程，看上去一切都是这么的完满，然而每次设计都十分苦楚，践行Operator模式之后，最值得反思和借鉴的就是”有了锤子，看到的只有钉子“，简略总结一下就是4个所有： 所有设计皆yaml所有皆合一所有皆终态所有交互皆cr误区1 所有设计皆yamlK8s的API是yaml格局，Operator设计流程也是让大家首先定义crd，所以团队开始设计时间接采纳了yaml格局。 案例 依据标准化流程，团队面向yaml设计流程大体如下： 先依据已知的数据初步整顿一个大而全的yaml，做一下初步的分类，例如利用大略蕴含根底信息，依赖服务，运维逻辑，监控采集等，每个分类做一个子局部开会讨论具体的内容是否能满足要求，后果每次散会都难以造成共识因为总是有新的需要满足不了，在探讨A时，就有人提到B、C、D，一直有新的需要每个局部的属性十分难对立，因为不同的实现属性差别较大了解不统一，雷同名字但应用时每个人的了解也不同因为工期很紧，只能长期斗争，做一个两头态，前面再进一步优化后续优化降级，雷同的流程再来一遍，还是很难造成共识这是第2个版本的设计： apiVersion: apps.mwops.alibaba-inc.com/v1alpha1kind: AppDefinitionmetadata: labels: app: "A"name: A-1.0 //chart-name+chart-version namespace: kubeonespec: appName: A //chart-name version: 1.0 //chart-version type: apps.mwops.alibaba-inc.com/v1alpha1.argo-helm workloadSettings: //注 workloadSettings 标识type应该应用的属性 ...

有时会遇到局部服务在集群内部，比方中间件和存储，想要通过k8s集群间接连贯两种形式，一种就是间接通过IP地址连贯；另外一种就是把内部地址映射到集群外部作为一个service来拜访，这样长处很显著前期如果资源IP地址有变更间接在线更新。看到这，我是想马上间接测试下，创立了一个service和endpoints 如下： ---apiVersion: v1kind: Servicemetadata: name: solr-cloud namespace: yp-testspec: ports: - protocol: TCP name: solr-port port: 9090 targetPort: 9090 type: ClusterIP clusterIP: ---apiVersion: v1kind: Endpointsmetadata: name: solr-cloud namespace: yp-testsubsets: - addresses: - ip: 192.168.11.229 ports: - port: 9090kubectl apply -f solr-endpoint.yaml 执行胜利了而后通过集群外部pod来拜访刚刚创立的service，发现回绝，然而间接申请IP是通的。再kubectl describe svc,ep solr-cloud -n yp-test查看如下： Name: solr-cloudNamespace: yp-testLabels: <none>Annotations: Selector: <none>Type: ClusterIPIP: 10.96.78.185Port: solr-port 9090/TCPTargetPort: 9090/TCPEndpoints: Session Affinity: NoneEvents: <none>Name: solr-cloudNamespace: yp-testLabels: <none>Annotations: Subsets: Addresses: 192.168.11.229 NotReadyAddresses: <none> Ports: Name Port Protocol ---- ---- -------- <unset> 9090 TCPEvents: <none>能够发现Endpoints为空也就是endpoints 并没有绑定到外部service上。为何会这样？后面的配置貌似也没任何问题，通过和官网文档比照，仔细的敌人可能会发现，service配置里spec.ports有个name（之前写service习惯会把port再定义个name）.先去掉这个name再从新创立试试没问题，去掉name，申请service通了。 ...

家喻户晓 gRPC 是基于 HTTP/2，而 HTTP/2 是基于 TCP 长连贯的。 k8s 自带一套基于 DNS 的服务发现机制 —— Service。 但基于 Service 的服务发现对于 gRPC 来说并不是开箱即用的，这外面有很多坑。 谬误姿态 ClusterIP ServicegRPC client 间接应用 ClusterIP Service 会导致负载不平衡。因为 HTTP/2 多个申请能够复用一条连贯，并发达到最大值才会创立新的连贯。这个最大值由 MaxConcurrentStreams 管制，Golang client 默认是100。 除非运气比拟好，例如并发数是 (200, 300]，正好与三个不同 pod 建设了三条长连贯。所以应用 ClusterIP Service 不太靠谱。 为什么 HTTP/1.1 不受影响HTTP/1.1 默认开启 Keepalive，也会放弃长连贯。 然而 HTTP/1.1 多个申请不会共享一个连贯，如果连接池里没有闲暇连贯则会新建一个，通过 Service 的负载平衡，各个 pod 上的连贯是绝对平衡的。 正确姿态长连贯负载平衡的原理是与后端每个 pod 都建设一个长连贯，LB 算法抉择一个写入申请。 gRPC client LB 配合 Headless Service创立 Headless Service 后，k8s 会生成 DNS 记录，拜访 Service 会返回后端多个 pod IP 的 A 记录，这样利用就能够基于 DNS 自定义负载平衡。 ...

本文首发于 Nebula Graph 官网：https://nebula-graph.com.cn/posts/how-to-deploy-nebula-graph-in-kubernetes/Kubernetes 是什么Kubernetes 是一个开源的，用于治理云平台中多个主机上的容器化的利用，Kubernetes 的指标是让部署容器化的利用简略并且高效，Kubernetes 提供了利用部署，布局，更新，保护的一种机制。 Kubernetes 在设计构造上定义了一系列的构建模块，其目标是为了提供一个能够部署、保护和扩大应用程序的机制，组成 Kubernetes 的组件设计理念为松耦合和可扩大的，这样能够使之满足多种不同的工作负载。可扩展性在很大水平上由 Kubernetes API 提供，此 API 次要被作为扩大的外部组件以及 Kubernetes 上运行的容器来应用。 Kubernetes 次要由以下几个外围组件组成： etcd 保留了整个集群的状态kube-apiserver 提供了资源操作的惟一入口，并提供认证、受权、访问控制、API 注册和发现等机制kube-controller-manager 负责保护集群的状态，比方故障检测、主动扩大、滚动更新等kube-scheduler 负责资源的调度，依照预约的调度策略将Pod调度到相应的机器上kubelet 负责保护容器的生命周期，同时也负责 Volume和网络的治理kube-proxy 负责为 Service 提供 cluster 外部的服务发现和负载平衡Kubernetes 和数据库数据库容器化是最近的一大热点，那么 Kubernetes 能为数据库带来什么益处呢？ 故障复原：Kubernetes 提供故障复原的性能，数据库利用如果宕掉，Kubernetes 能够将其主动重启，或者将数据库实例迁徙到集群中其余节点上存储管理：Kubernetes 提供了丰盛的存储接入计划，数据库利用能通明地应用不同类型的存储系统负载平衡：Kubernetes Service 提供负载平衡性能，能将内部拜访平衡到不同的数据库实例正本上程度拓展：Kubernetes 能够依据以后数据库集群的资源利用率状况，缩放正本数目，从而晋升资源的利用率目前很多数据库，如：MySQL，MongoDB 和 TiDB 在 Kubernetes 集群中都能运行良好。 Nebula Graph 在 Kubernetes 中的实际Nebula Graph 是一个分布式的开源图数据库，次要组件有：Query Engine 的 graphd，数据存储的 storaged，和元数据的 meted。在 Kubernetes 实际过程中，它次要给图数据库 Nebula Graph 带来了以下的益处： Kubernetes 能平衡 nebula graphd，metad 和 storaged 不同正本之间的负载。graphd，metad 和 storaged 能够通过 Kubernetes 的域名服务主动发现彼此。通过 StorageClass，PVC 和 PV 能够屏蔽底层存储细节，无论应用本地卷还是云盘，Kubernetes 均能够通明对接。通过 Kubernetes 能够在数秒内胜利部署一套 Nebula 集群，Kubernetes 也能够无感知地实现 Nebula 集群的降级。Nebula 集群通过 Kubernetes 能够做到自我复原，单体正本 crash，Kubernetes 能够从新将其拉起，无需运维人员染指。Kubernetes 能够依据以后 Nebula 集群的资源利用率状况弹性伸缩集群规模，从而晋升集群的性能。上面来解说下具体的实际内容。 ...

1、简介k8s是基于容器技术的分布式架构当先计划。是Google开源的一个容器编排引擎，反对自动化部署、大规模可伸缩、利用容器化治理。 k8s能够进行容器的自动化复制和部署。能够随时扩大或膨胀容器规模，并提供负载平衡。能够不便地进行容器降级，提供容器弹性，如果其中一个正本生效，则替换它。对于有问题的容器，尝试重启或修复。 master是主服务器，node是利用于部署利用容器的服务器pod是根本的操作单元，也是利用运行的载体。个别一个pod搁置一个容器 deployment定义了pod部署信息，如运行参数、正本个数等 若干个pod组成一个service ,对外提供服务 正本是一个pod的多个实例 namespace用于多租户的资源隔离。比方能够在测试环境中划分成多套测试环境。默认有2个namespace：kube-system和default k8s调度过程1、k8s client将申请发送给API server2、API Server依据申请类型，将解决的后果存入高可用键值存储系统Etcd中3、Scheduler将未散发的pod绑定到可用的node节点，存到Etcd中4、controller manager依据etcd中的信息，调用node中的kubelete创立pod5、controller manager监控pod的运行状况并确保运行失常

背景因为k8s集群的资源有余，将局部服务器关机扩容再启动，发现局部pod始终没有起来。 排查过程查看pod的日志，发现解析集群内的域名失败，揣测是dns的问题。 查看dns相干的pod，发现nodelocaldns始终在重启。 root@master1:~# k get pods --all-namespaces | grep dnskube-system coredns-74d59cc5c6-9brnf 1/1 Running 0 15dkube-system coredns-74d59cc5c6-g46rf 1/1 Running 0 15dkube-system nodelocaldns-bwnml 1/1 Running 0 15dkube-system nodelocaldns-f8tmj 0/1 CrashLoopBackOff 2926 12dkube-system nodelocaldns-rtngg 0/1 CrashLoopBackOff 44 15d登录对应的node，netstat -ntple | grep 53查看53端口的占用状况，发现被named过程占用。 将named过程kill掉，在/lib/systemd/system目录下定位到是bind9服务开机自启动，并将其禁用掉，实现修复工作。 root@node1:/lib/systemd/system# grep -rn named ././bind9-pkcs11.service:3:Documentation=man:named(8)./bind9-pkcs11.service:8:Environment=KRB5_KTNAME=/etc/bind/named.keytab./bind9-pkcs11.service:10:ExecStart=/usr/sbin/named-pkcs11 -f -u bind./bind9-resolvconf.service:3:Documentation=man:named(8) man:resolvconf(8)./bind9-resolvconf.service:11:ExecStart=/bin/sh -c 'echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.named'./bind9-resolvconf.service:12:ExecStop=/sbin/resolvconf -d lo.named./systemd-hostnamed.service:12:Documentation=man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5)./systemd-hostnamed.service:13:Documentation=https://www.freedesktop.org/wiki/Software/systemd/hostnamed./systemd-hostnamed.service:16:ExecStart=/lib/systemd/systemd-hostnamed./bind9.service:3:Documentation=man:named(8)./bind9.service:10:ExecStart=/usr/sbin/named -f $OPTIONSroot@node1:/lib/systemd/system# systemctl disable bind9Synchronizing state of bind9.service with SysV service script with /lib/systemd/systemd-sysv-install.Executing: /lib/systemd/systemd-sysv-install disable bind9

起源：K8s技术圈 作者：阳明 Kubernetes Ingress 只是 Kubernetes 中的一个一般资源对象，须要一个对应的 Ingress 控制器来解析 Ingress 的规定，裸露服务到内部，比方 ingress-nginx，实质上来说它只是一个 Nginx Pod，而后将申请重定向到其余外部（ClusterIP）服务去，这个 Pod 自身也是通过 Kubernetes 服务裸露进来，最常见的形式是通过 LoadBalancer 来实现的。同样本文咱们心愿用一个简略清晰的概述，让你来理解 Kubernetes Ingress 背地的货色，让你更容易了解应用的 Ingress。 咱们能够应用 Ingress 来使外部服务裸露到集群内部去，它为你节俭了贵重的动态 IP，因为你不须要申明多个 LoadBalancer 服务了，此次，它还能够进行更多的额定配置。上面咱们通过一个简略的示例来对 Ingress 进行一些阐明吧。 01 简略HTTP server首先，咱们先回到容器、Kubernetes 之前的时代。 之前咱们更多会应用一个（Nginx）HTTP server 来托管咱们的服务，它能够通过 HTTP 协定接管到一个特定文件门路的申请，而后在文件系统中查看这个文件门路，如果存在则就返回即可。 例如，在 Nginx 中，咱们能够通过上面的配置来实现这个性能。 location /folder { root /var/www/; index index.html;}除了下面提到的性能之外，咱们能够当 HTTP server 接管到申请后，将该申请重定向到另一个服务器（意味着它作为代理）去，而后将该服务器的响应重定向到客户端去。对于客户端来说，什么都没有扭转，接管到的后果依然还是申请的文件（如果存在的话）。 同样如果在 Nginx 中，重定向能够配置成上面的样子： location /folder { proxy_pass http://second-nginx-server:8000;}这意味着 Nginx 能够从文件系统中提供文件，或者通过代理将响应重定向到其余服务器并返回它们的响应。 ...

这个月9号，间隔公司k8s生产集群部署刚好一整年，k8s 默认的证书到期生效，以致生产零碎多个节点不可用。 排查问题，看到了报错 certificate has expired or is not yet valid。原本是一个非常简单的问题，但过后头脑重大迷糊，居然从新生成证书，将NotReady的节点进行重新部署。后果重复试验，重启，导致整个集群所有节点都不可用。 这不是最遭的，更糟的是加班到深夜3点多，头脑迷糊的我将整个集群从新进行了部署，尽管还有仅剩的理智，想着只有不毁坏 etcd的数据，集群是能从新复原的。 大失所望，集群起来了，但所有的 pod 无奈启动，因为不知什么起因k8s的集群服务网段产生了变动，导致新的网段证书无奈受权。批改网段，pod终于起来了。但令我万分丧气的是，尽管 所有的 pvc 都没有变动，还是之前etcd数据中的pvc，但 。。。 数据库尽然是空的，是空的，是空的。。。 尽管零碎正式启动也就一个多月的工夫，但这两个月也有了很多生产数据，最要害的是，原本就对我有所不满的主管，终于有理由对我之前提的所有的技术计划说不了。 k8s，干掉，MongoDB，干掉，go语言，干掉，我就乖乖的弄前端那一亩三分地吧。所有的服务器，干掉Linux，上Windows，后端的服务器，居然上了个win10，只是因为docker在win10下才有可视化的保护界面。 公司最大的业务零碎MES，简直都是我一个人写的，终于在10月底上线。老板很快乐，还请咱们团队吃了饭。但这些天年底绩效评估，没有功绩，只有过错。绩效简直不合格，来年的涨薪不要再想。终于我彻底地心灰意冷了。 当初还不晓得为什么我的服务都起来了，用的也是之前etcd的数据，之前的pod和pvc配置都在，存储用的是 ceph，为什么数据就全丢了。还是怪本人学艺不精，遇事头脑不清晰，最重要的是，没有和主管处好关系。之前测试集群就曾经挂掉，我猜测是同样的起因，但因为重启零碎没有胜利，无奈再连贯。之前的运维被挤走，新来的运维服务器这块还没有交接。因为和主管不和，我居然就不想和他谈话，让他在运维端把机器重启一下，失去了最开始发现和解决问题的最佳时机。在此吸取教训，当前不论怎么样，要和下级处好关系。 在此把解决办法贴说一下，心愿遇到此问题的其余小伙伴，当前可能顺利解决。 其实很简略啊。 删除过期的节点kubectl delete node [node-name]进入被删除的节点，重启 kubeletsystemctl restart kubelet过一段时间之后，查看节点kubectl get nodes会发现之前删除的节点从新呈现，但节点 AGE 是最新的工夫

argogithub https://github.com/argoproj/argo 装置启动kubectl create namespace argo kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/stable/manifests/install.yaml # This is an auto-generated file. DO NOT EDITapiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: clusterworkflowtemplates.argoproj.iospec: group: argoproj.io names: kind: ClusterWorkflowTemplate listKind: ClusterWorkflowTemplateList plural: clusterworkflowtemplates shortNames: - clusterwftmpl - cwft singular: clusterworkflowtemplate scope: Cluster version: v1alpha1 versions: - name: v1alpha1 served: true storage: true---apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: cronworkflows.argoproj.iospec: group: argoproj.io names: kind: CronWorkflow listKind: CronWorkflowList plural: cronworkflows shortNames: - cwf - cronwf singular: cronworkflow scope: Namespaced version: v1alpha1 versions: - name: v1alpha1 served: true storage: true---apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: workfloweventbindings.argoproj.iospec: group: argoproj.io names: kind: WorkflowEventBinding listKind: WorkflowEventBindingList plural: workfloweventbindings shortNames: - wfeb singular: workfloweventbinding scope: Namespaced version: v1alpha1 versions: - name: v1alpha1 served: true storage: true---apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: workflows.argoproj.iospec: additionalPrinterColumns: - JSONPath: .status.phase description: Status of the workflow name: Status type: string - JSONPath: .status.startedAt description: When the workflow was started format: date-time name: Age type: date group: argoproj.io names: kind: Workflow listKind: WorkflowList plural: workflows shortNames: - wf singular: workflow scope: Namespaced subresources: {} version: v1alpha1 versions: - name: v1alpha1 served: true storage: true---apiVersion: apiextensions.k8s.io/v1beta1kind: CustomResourceDefinitionmetadata: name: workflowtemplates.argoproj.iospec: group: argoproj.io names: kind: WorkflowTemplate listKind: WorkflowTemplateList plural: workflowtemplates shortNames: - wftmpl singular: workflowtemplate scope: Namespaced version: v1alpha1 versions: - name: v1alpha1 served: true storage: true---apiVersion: v1kind: ServiceAccountmetadata: name: argo---apiVersion: v1kind: ServiceAccountmetadata: name: argo-server---apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: argo-rolerules:- apiGroups: - "" resources: - secrets verbs: - get---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" name: argo-aggregate-to-adminrules:- apiGroups: - argoproj.io resources: - workflows - workflows/finalizers - workfloweventbindings - workfloweventbindings/finalizers - workflowtemplates - workflowtemplates/finalizers - cronworkflows - cronworkflows/finalizers - clusterworkflowtemplates - clusterworkflowtemplates/finalizers verbs: - create - delete - deletecollection - get - list - patch - update - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: rbac.authorization.k8s.io/aggregate-to-edit: "true" name: argo-aggregate-to-editrules:- apiGroups: - argoproj.io resources: - workflows - workflows/finalizers - workfloweventbindings - workfloweventbindings/finalizers - workflowtemplates - workflowtemplates/finalizers - cronworkflows - cronworkflows/finalizers - clusterworkflowtemplates - clusterworkflowtemplates/finalizers verbs: - create - delete - deletecollection - get - list - patch - update - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: rbac.authorization.k8s.io/aggregate-to-view: "true" name: argo-aggregate-to-viewrules:- apiGroups: - argoproj.io resources: - workflows - workflows/finalizers - workfloweventbindings - workfloweventbindings/finalizers - workflowtemplates - workflowtemplates/finalizers - cronworkflows - cronworkflows/finalizers - clusterworkflowtemplates - clusterworkflowtemplates/finalizers verbs: - get - list - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: argo-cluster-rolerules:- apiGroups: - "" resources: - pods - pods/exec verbs: - create - get - list - watch - update - patch - delete- apiGroups: - "" resources: - configmaps verbs: - get - watch - list- apiGroups: - "" resources: - persistentvolumeclaims verbs: - create - delete - get- apiGroups: - argoproj.io resources: - workflows - workflows/finalizers verbs: - get - list - watch - update - patch - delete - create- apiGroups: - argoproj.io resources: - workflowtemplates - workflowtemplates/finalizers - clusterworkflowtemplates - clusterworkflowtemplates/finalizers verbs: - get - list - watch- apiGroups: - "" resources: - serviceaccounts verbs: - get - list- apiGroups: - argoproj.io resources: - cronworkflows - cronworkflows/finalizers verbs: - get - list - watch - update - patch - delete- apiGroups: - "" resources: - events verbs: - create - patch- apiGroups: - policy resources: - poddisruptionbudgets verbs: - create - get - delete---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: argo-server-cluster-rolerules:- apiGroups: - "" resources: - configmaps verbs: - get - watch - list- apiGroups: - "" resources: - secrets verbs: - get - create- apiGroups: - "" resources: - pods - pods/exec - pods/log verbs: - get - list - watch - delete- apiGroups: - "" resources: - events verbs: - watch - create - patch- apiGroups: - "" resources: - serviceaccounts verbs: - get - list- apiGroups: - argoproj.io resources: - workflows - workfloweventbindings - workflowtemplates - cronworkflows - clusterworkflowtemplates verbs: - create - get - list - watch - update - patch - delete---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: argo-bindingroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: argo-rolesubjects:- kind: ServiceAccount name: argo---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: argo-bindingroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: argo-cluster-rolesubjects:- kind: ServiceAccount name: argo namespace: argo---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: argo-server-bindingroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: argo-server-cluster-rolesubjects:- kind: ServiceAccount name: argo-server namespace: argo---apiVersion: v1kind: ConfigMapmetadata: name: workflow-controller-configmap---apiVersion: v1kind: Servicemetadata: name: argo-serverspec: ports: - name: web port: 2746 targetPort: 2746 selector: app: argo-server---apiVersion: v1kind: Servicemetadata: name: workflow-controller-metricsspec: ports: - name: metrics port: 9090 protocol: TCP targetPort: 9090 selector: app: workflow-controller---apiVersion: apps/v1kind: Deploymentmetadata: name: argo-serverspec: selector: matchLabels: app: argo-server template: metadata: labels: app: argo-server spec: containers: - args: - server image: argoproj/argocli:v2.12.2 name: argo-server ports: - containerPort: 2746 name: web readinessProbe: httpGet: path: / port: 2746 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 20 volumeMounts: - mountPath: /tmp name: tmp nodeSelector: kubernetes.io/os: linux securityContext: runAsNonRoot: true serviceAccountName: argo-server volumes: - emptyDir: {} name: tmp---apiVersion: apps/v1kind: Deploymentmetadata: name: workflow-controllerspec: selector: matchLabels: app: workflow-controller template: metadata: labels: app: workflow-controller spec: containers: - args: - --configmap - workflow-controller-configmap - --executor-image - argoproj/argoexec:v2.12.2 command: - workflow-controller image: argoproj/workflow-controller:v2.12.2 name: workflow-controller nodeSelector: kubernetes.io/os: linux securityContext: runAsNonRoot: true serviceAccountName: argo创立领有create pod之类的权限的workflow账户给argo应用kubectl apply -f ...

应用kubeadm搭建k8s(1.18.2版本)高可用集群如果想更相熟k8s的各个组件的话还是倡议应用二进制搭建学习。1 节点布局信息172.16.197.49 master49172.16.197.50 master50172.16.197.56 master56172.16.197.52 node52172.16.197.53 node53172.16.197.200 k8s-lb 2 根底环境筹备环境信息| 软件 | 版本 || kubernetes | 1.18.2 || docker | 19.0.3 | 2.1 环境初始化 （在每台机器上执行）1）配置主机名，以k8s-master49为例(须要顺次依据节点布局角色批改主机名)k8s-lb不须要设置主机名，只需在及群里的每台机器写hosts（能够了解成keepalive的hosts或者域名，在kubeadmi 创立集群应用k8s-lb:xxxx 所以须要配host）[root@localhost ~]# hostnamectl set-hostname master49 2）配置主机hosts映射（在每台机器上执行）[root@localhost ~]# vim /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6172.16.197.49 master49172.16.197.50 master50172.16.197.56 master56172.16.197.52 node52172.16.197.53 node53172.16.197.200 k8s-lb3）禁用防火墙[root@localhost ~]# systemctl stop firewalld[root@localhost ~]# systemctl disable firewalld` 4）敞开selinux[root@localhost ~]# setenforce 0[root@localhost ~]# sed -i "s/^SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config 5）敞开swap分区[root@localhost ~]# swapoff -a # 长期[root@localhost ~]# sed -i '/ swap / s/^(.*)$/#1/g' /etc/fstab #永恒 6）工夫同步[root@localhost ~]# yum install chrony -y[root@localhost ~]# systemctl enable chronyd[root@localhost ~]# systemctl start chronyd[root@localhost ~]# chronyc sources7）配置ulimt[root@localhost ~]# ulimit -SHn 655358）配置内核参数[root@localhost ~]# cat >> /etc/sysctl.d/k8s.conf << EOFnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward = 1vm.swappiness=0EOF[root@localhost ~]# sysctl -p2.2 内核降级（在每台机器上执行）因为centos7.6的零碎默认内核版本是3.10，3.10的内核有很多BUG，最常见的一个就是group memory leak(四台主机都要执行) ...

下载sealos命令wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/latest/sealos && \ chmod +x sealos && mv sealos /usr/bin下载资源包wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/7b6af025d4884fdd5cd51a674994359c-1.18.0/kube1.18.0.tar.gz批改 hostname# 留神主机名不要有特殊符号hostnamectl set-hostname your-new-host-name查看批改后果hostnamectl status设置 hostname 解析echo "127.0.0.1 $(hostname)" >> /etc/hosts开始装置集群sealos init --passwd 123456 \ --master 192.168.253.130 --master 192.168.253.131 --master 192.168.253.132 \ --node 192.168.253.133 \ --pkg-url /root/kube1.18.0.tar.gz \ --version v1.18.0centos版本为7.*，倡议升高kube-proxy版本，修复在集群内解释不了外部命名空间等地址的问题kubectl -n kube-system set image daemonset/kube-proxy *=registry.aliyuncs.com/k8sxio/kube-proxy:v1.17.6

Kubernetes的呈现不仅主宰了容器编排的市场，也进化了过来的运维形式，不仅将开发与运维之间边界变得更加含糊，而且让DevOps这一角色变得更加清晰。它是目前可用的很风行的容器解决方案之一。 每个软件工程师都能通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且可能疾速实现程度扩容、蓝绿部署等在过来简单的运维操作。以下的一系列工具，能够助你充分运用Kubernetes。 集群部署工具1、Amazon EKS Amazon Elastic Container Service是一个Kubernetes DevOps工具，它容许用户治理和扩大他们的容器化应用程序，并应用Kubernetes简化部署。当你须要一个足够平安、足够稳固的Kubernetes服务， 用尽可能少的精力去保护基础设施，心愿将更多的精力投放在业务的研发上时，Amazon EKS 就会成为一个值得你抉择的选项。Amazon EKS具备灵便的布局并缩小了保护开销。 2、Kubespray KubeSpray是一个集群生命周期管理器，能够帮忙部署可用于生产的Kubernetes集群。它应用ansible-playbook来自动化Kubernetes集群配置。次要性能包含基于Ansible，高度可用，跨平台;风行的云提供商集成甚至是裸机，多种配置选项，多平台CI/CD等等。因为Kubespray领有一个凋谢的开发模型，易于应用，大大降低了编排集群的难度，任何人都能够很容易地学习如何应用Kubespray。 3、Conjure-up Conjure-up易于应用，容许用户以起码的问题部署他们的应用程序。反对本地主机部署、AWS、bare metal、Azure、VMware、Joynet和OpenStack。 监控工具4、Kubewatch Kubewatch是一个很好用的工具，kubewatch可能监控那些特定的Kubernetes事件，并将此类事件以告诉的模式推送到诸如Slack和PagerDuty的端点上。能够确保你的容器是平安的，并应用行业最佳实际进行打包，同时监督软件的破绽和更新。然而，用户示意，增加对多个实例的反对将会更有帮忙。反对多个端点，且易于部署。 5、Weave Scope Weave Scope用来监督和解决Kubernetes和Docker集群的故障，你就能够解放双手轻松地辨认和纠正你的容器化应用程序的问题。 6、Test-infra Testinfra 是一个基础架构测试框架，它能够轻松编写单元测试来验证服务器的状态。它反对的后端之一是 Ansible，所以这意味着 Testinfra 能够间接应用 Ansible 的清单文件和清单中定义的一组机器来对它们进行测试。对于解决简单的模板来测试和检测谬误十分有用。 7、Trireme Trireme通过进步Kubernetes过程、工作负载和容器的安全性和升高复杂性，引入了一种不同的网络受权办法。倡议用它来加重Kubernetes工作负载、容器和过程的复杂性。它能够帮忙你在应用程序层强制施行安全性。 8、Sysdig Falco 这是一个能够提供深度容器可见性的行为流动监督工具，它缩短了检测安全事件所需的工夫，并利用了容许你继续监督和检测容器、应用程序、主机和网络流动的规定。应用它能够对其基础设施进行继续查看、异样检测，并为任何类型的 Linux 零碎调用设置警报告诉。 还能够通过 Falco 监督 shell 何时在容器中运行、容器在哪里挂载、对敏感文件的意外读取、出站网络尝试以及其余可疑调用。 CLI工具9、Cabin Cabin是一个挪动仪表盘，通过Android或iOS对Kubernetes进行治理。它批准用户远程管理他们的集群，是个很赞的工具，能够对所有事件进行疾速补救。当Kubernetes应用程序来到主设施时，Cabin能够疾速治理它们。这并不是一个用于开发的工具。当工程师常常远离他们的主计算机，须要疾速治理他们的Kubernetes集群时，Cabin就很有用。 10、Kubectx/Kubens Kubectx/Kubens应用主动实现个性，通过在集群之间来回切换，帮忙用户轻松切换上下文，并同时连贯到各个集群。你能够应用它在Kubernetes命名空间之间安稳地切换。它有益于始终在集群或命名空间之间导航的用户。 开发工具11、Telepresence 它让你能够在本地调试Kubernetes服务，简化了开发和调试过程。 12、Helm Helm帮忙用户治理他们的Kubernetes应用程序，通过Helm图表让你能够共享你的应用程序。这让用户可能创立可共享可复制的构建，但它不举荐用于更高级、更频繁的部署。 13、Keel 它让用户能够从新专一于编写代码和测试他们的应用程序。因为如果库中有新的应用程序版本可用，它就会自动更新kubernetes的工作负载。 原文：https://xw.qq.com/amphtml/202...

写在后面钻研K8S有一段时间了，最开始学习K8S时，依据网上的教程装置K8S环境总是报错。所以，我就扭转了学习策略，先不搞环境搭建了。先通过官网学习了K8S的整体架构，底层原理，又硬啃了一遍K8S源码。别问我为哈这样学，只是我感觉对我集体来说，这样学能让我更好的了解整套云原生体系。这不，这次，我总结了如何一次性胜利装置K8S集群的办法。咱们明天先来说说如何基于一主两从模式搭建K8S集群。前面，咱们再上如何齐全无坑搭建K8S高可用集群的计划。文章和搭建环境所须要的yml文件已收录到：https://github.com/sunshinelyz/technology-binghe 和 https://gitee.com/binghe001/technology-binghe 。如果文件对你有点帮忙，别忘记给个Star哦！ 集群布局IP主机名节点操作系统版本192.168.175.101binghe101MasterCentOS 8.0.1905192.168.175.102binghe102WorkerCentOS 8.0.1905192.168.175.103binghe103WorkerCentOS 8.0.1905根底配置在三台服务器上的/etc/hosts文件中增加如下配置项。 192.168.175.101 binghe101192.168.175.102 binghe102192.168.175.103 binghe103查看零碎环境别离在三台服务器上查看零碎的环境。 1.查看服务器操作系统版本cat /etc/redhat-release装置Docker和K8S集群的服务器操作系统版本须要在CentOS 7以上。 2.查看服务器的主机名hostname留神：集群中服务器的主机名不能是localhost。3.查看服务器的CPU核数lscpu留神：集群中服务器的CPU核数不能少于2个。4.查看服务器网络以binghe101（Master）服务器为例。在服务器上执行 ip route show 命令来查看服务器的默认网卡，如下所示。 [root@binghe101 ~]# ip route showdefault via 192.168.175.2 dev ens33 proto static metric 100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.175.0/24 dev ens33 proto kernel scope link src 192.168.175.101 metric 100 在下面的输入信息中有如下一行标注了binghe101服务器所应用的默认网卡。 default via 192.168.175.2 dev ens33 proto static metric 100 能够看到，binghe101服务器应用的默认网卡为ens33。 接下来，应用ip address命令查看服务器的IP地址，如下所示。 ...

前言最近正在学习k8s集群的搭建过程，记录下来分享给大家。 筹备工作visualbox 虚拟机centos7 ISO镜像练习的电脑配置要高搭建kube-master虚拟机名称：kube-master内存：4G硬盘：10G网卡：网卡1和网卡2 留神：vboxnet0能够在全局网络配置外面点击增加！ 搭建过程：略 根本环境配置 敞开selinuxsetenforce 0sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config敞开swap分区或禁用swap文件swapoff -a# 正文掉对于swap分区的行yes | cp /etc/fstab /etc/fstab_bakcat /etc/fstab_bak |grep -v swap > /etc/fstab批改网卡配置$ vim /etc/sysctl.confnet.ipv4.ip_forward = 1net.bridge.bridge-nf-call-iptables = 1net.bridge.bridge-nf-call-ip6tables = 1$ sysctl -p启用内核模块$ modprobe -- ip_vs$ modprobe -- ip_vs_rr$ modprobe -- ip_vs_wrr$ modprobe -- ip_vs_sh$ modprobe -- nf_conntrack_ipv4$ cut -f1 -d " " /proc/modules | grep -e ip_vs -e nf_conntrack_ipv4$ vim /etc/sysconfig/modules/ipvs.modulesmodprobe -- ip_vsmodprobe -- ip_vs_rrmodprobe -- ip_vs_wrrmodprobe -- ip_vs_shmodprobe -- nf_conntrack_ipv4敞开防火墙$ systemctl stop firewalld$ systemctl disable firewalldkubectl、kubeadm、kubelet的装置增加Kubernetes的yum源vim /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64enabled=1gpgcheck=0repo_gpgcheck=0gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg装置kubelet、kubeadm、kubectlyum install -y kubelet kubeadm kubectl启动kubelet服务systemctl enable kubeletsystemctl start kubelet此时执行systemctl status kubelet查看服务状态，服务状态应为Error(255)， 如果是其余谬误可应用journalctl -xe查看错误信息。 ...

默认是安的sqlite3,须要应用etcd装置须要加flagcurl -sfL https://get.k3s.io | K3S_DATASTORE_ENDPOINT="etcd" sh - 配置以docker装置，数据放在/home/k3s下curl -sfL https://get.k3s.io | K3S_DATASTORE_ENDPOINT="etcd" sh -s - --docker --default-local-storage-path /home/k3s 装置后etcd的地位在/var/lib/rancher/k3s/server/db/etcd

环境服务器：172.17.17.20-22 三个服务器 （深服气aCloud虚拟化平台） 操作系统版本：CentOS 7.8 内核版本：3.10 景象在20-22三台上装置K8S集群（通过rancher的rke装置），装置结束后，发现拜访各个节点的80端口，只有20服务器可能失常返回，其余的都是Gateway Timeout。应用Rancher的提供的这个方法得悉Overlay网络不通。 排查过程排查网络通性依据Rancher文档上提到的，Host的8472/udp端口是Flannel/Calico的VXLAN Overlay网络专用端口，即所有跨Host的容器间网络通信都走这个端口。因而： 在172.17.17.22上，用tcpdump抓收回的包： tcpdump -nn 'udp and src host 172.17.17.22 and dst port 8472'另开一个22的终端，执行 curl http://localhost 可能看到 22->20 的UDP包，见下图： 在172.17.17.20上，用tcpdump抓收到的包： tcpdump -nn 'udp and src host 172.17.17.22 and dst port 8472'后果是没有抓到任何包。 排查虚拟机网络安全组正当狐疑虚拟机网络安全组没有放开8472/udp端口的拜访权限，在22上应用netcat发送数据： nc -u 172.17.17.20 8472轻易打点字回车传输，如下图： 后果在20上可能抓到收到的包： 这阐明网络安全组并没有拦截8472/udp端口的拜访。 初步假如狐疑这些数据在深服气aCloud虚拟化平台的网络中被过滤掉了。基于以下理由： k8s应用的是基于VXLAN的Overlay network，VNI=1，并且是基于UDP协定。而深服气aCloud高概率也应用VXLAN做Overlay网络。一般的udp协定数据传输tcpdump可能抓到包（见后面）tcpdump在网络栈中的地位inbound在iptables之前，outbound在iptables之后（材料）。如果tcpdump可能抓到收回的包，那么阐明是真的收回了。如果inbound没有抓到承受的包，那么就阐明这个包没有达到网卡。解决办法和深服气的同学沟通后，其确认是物理机也是用了8472/udp端口做Overlay网络，两者抵触了，因而当UDP包内蕴含了OTV数据内容后，先一步被aCloud拦挡，后果就是虚拟机的8472/udp端口收不到数据。 将物理机的8472/udp端口改掉后，问题解决。 PS. 8472/udp还是一个驰名端口 解决办法2也能够在rke创立k8s集群的时候批改flannel的端口，须要批改cluster.yml（参考文档）。 如果你用的是canal网络插件（默认）： ...network: plugin: canal options: canal_flannel_backend_type: vxlan canal_flannel_backend_port: "8872" ...如果用的是flannel网络插件： ...

本文章是自己依照博客文章：《002.应用kubeadm装置kubernetes 1.17.0》https://www.cnblogs.com/zyxnh... 以及《Kubernetes权威指南》等材料进行部署实现后进行的记录和总结。 本文分三个局部，（上）记录了基础设施环境的后期筹备和Master的部署，以及网络插件Flannel的部署。（中）记录了node的部署过程，以及一些必要的容器的部署。（下）介绍一些监控和DevOps的相干内容。 三。部署node此处当然倡议通过ansible等配置管理工具对立进行部署。我的文档只拿一台node来举例子。 1. 退出集群：kubeadm join命令[root@k8s-master opt]# kubeadm join 192.168.56.99:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:ef543a59aac99e4f86e6661a7eb04d05b8a03269c7784378418ff3ff2a2d2d3c2. 看后果：胜利了的话屏幕的回显应该是这样的，如果失败了，检查一下起因。 我这边就失败了，通过两个终端查看的方法终于发现，还是老问题，镜像拉取卡住。我本来认为镜像只在master上拉取过就够了，事实上每台node都应该有雷同的镜像。起初想明确了，镜像是通过文件系统的形式，对象存储来体现，一台机器上有这个文件对象不代表另一台机器上也有，另外不论K8S还是Docker都没有镜像同步的机制。 [root@k8s-master opt]# docker pull kubeimage/kube-proxy-amd64:v1.19.3[root@k8s-master opt]# docker pull kubeimage/pause-amd64:3.2这就看进去了，下面说的容器镜像该当封装到操作系统镜像中比拟好。公有云的Openstack或者VMVware vSphere，私有云的阿里云等等都反对自定义镜像的，一下子快好多。不光是镜像本地化，那些通用的配置也都不须要重复地配置了，节俭了很多生产力。 3. 部署Node时遇到的问题。（1）kubelet无奈启动。通过查看零碎服务状态发现该服务始终处于Activating 状态，而不是running. 查看了message 后发现kubelet.service 启动时会查看swap分区，分区存在的话无奈启动。手动敞开。日志写得很分明： Nov 6 09:04:24 k8s-node01 kubelet: F1106 09:04:24.680751 2635 server.go:265] failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: [Filename#011#011#011#011Type#011#011Size#011Used#011Priority /dev/dm-1 partition#011839676#0110#011-2]4. 部署node实现[root@k8s-master opt]# kubectl get nodesNAME STATUS ROLES AGE VERSION192.168.56.99 Ready master 4d22h v1.19.3k8s-node01 NotReady <none> 4d22h v1.19.3四。部署必要容器1. kubernetes-dashboard是整个集群的web治理界面，对于日后治理集群来说是必备的。[root@k8s-master opt]# wget https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended.yaml咱们先用标准配置去apply，有什么问题再去批改。 ...

一. 为什么是k8s v1.16.0？最新版的v1.16.2试过了，始终无奈装置实现，装置到kubeadm init那一步执行后，报了很多错，如：node xxx not found等。centos7都重装了几次，还是无奈解决。用了一天都没装置完，差点放弃。起初在网上搜到的装置教程根本都是v1.16.0的，我不太置信是v1.16.2的坑所以先前没打算降级到v1.16.0。没方法了就试着装置v1.16.0版本，居然胜利了。记录在此，防止后来者踩坑。 本篇文章，装置大步骤如下： 装置docker-ce 18.09.9（所有机器）设置k8s环境前置条件（所有机器）装置k8s v1.16.0 master治理节点装置k8s v1.16.0 node工作节点装置flannel（master）这里有重要的一步，请记住本人master和node之间通信的ip，如我的master的ip为192.168.99.104，node的ip为：192.168.99.105. 请确保应用这两个ip在master和node上能相互ping通，这个master的ip 192.168.99.104接下来配置k8s的时候须要用到。 我的环境： 操作系统：win10虚拟机：virtual boxlinux发行版：CentOS7linux内核(应用uname -r查看)：3.10.0-957.el7.x86_64master和node节点通信的ip(master)：192.168.99.104二. 装置docker-ce 18.09.9（所有机器）所有装置k8s的机器都须要装置docker，命令如下： # 装置docker所需的工具yum install -y yum-utils device-mapper-persistent-data lvm2# 配置阿里云的docker源yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo# 指定装置这个版本的docker-ceyum install -y docker-ce-18.09.9-3.el7# 启动dockersystemctl enable docker && systemctl start docker三. 设置k8s环境筹备条件（所有机器）装置k8s的机器须要2个CPU和2g内存以上，这个简略，在虚拟机外面配置一下就能够了。而后执行以下脚本做一些筹备操作。所有装置k8s的机器都须要这一步操作。 # 敞开防火墙systemctl disable firewalldsystemctl stop firewalld# 敞开selinux# 长期禁用selinuxsetenforce 0# 永恒敞开 批改/etc/sysconfig/selinux文件设置sed -i 's/SELINUX=permissive/SELINUX=disabled/' /etc/sysconfig/selinuxsed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config# 禁用替换分区swapoff -a# 永恒禁用，关上/etc/fstab正文掉swap那一行。sed -i 's/.*swap.*/#&/' /etc/fstab# 批改内核参数cat <<EOF >  /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsysctl --system四. 装置k8s v1.16.0 master治理节点如果还没装置docker，请参照本文步骤二装置docker-ce 18.09.9（所有机器）装置。如果没设置k8s环境筹备条件，请参照本文步骤三设置k8s环境筹备条件（所有机器）执行。 以上两个步骤查看结束之后，持续以下步骤。 装置kubeadm、kubelet、kubectl因为官网k8s源在google，国内无法访问，这里应用阿里云yum源 # 执行配置k8s阿里云源cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF# 装置kubeadm、kubectl、kubeletyum install -y kubectl-1.16.0-0 kubeadm-1.16.0-0 kubelet-1.16.0-0# 启动kubelet服务systemctl enable kubelet && systemctl start kubelet初始化k8s 以下这个命令开始装置k8s须要用到的docker镜像，因为无法访问到国外网站，所以这条命令应用的是国内的阿里云的源(registry.aliyuncs.com/google_containers)。另一个十分重要的是：这里的--apiserver-advertise-address应用的是master和node间能相互ping通的ip，我这里是192.168.99.104，刚开始在这里被坑了一个早晨，你请本人批改下ip执行。这条命令执行时会卡在[preflight] You can also perform this action in beforehand using ''kubeadm config images pull，大略须要2分钟，请急躁期待。# 下载治理节点中用到的6个docker镜像，你能够应用docker images查看到# 这里须要大略两分钟期待，会卡在[preflight] You can also perform this action in beforehand using ''kubeadm config images pullkubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.16.0 --apiserver-advertise-address 192.168.99.104 --pod-network-cidr=10.244.0.0/16 --token-ttl 0下面装置完后，会提醒你输出如下命令，复制粘贴过去，执行即可。 # 下面装置实现后，k8s会提醒你输出如下命令，执行mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config记住node退出集群的命令 下面kubeadm init执行胜利后会返回给你node节点退出集群的命令，等会要在node节点上执行，须要保留下来，如果遗记了，能够应用如下命令获取。kubeadm token create --print-join-command以上，装置master节点结束。能够应用kubectl get nodes查看一下，此时master处于NotReady状态，临时不必管。 五. 装置k8s v1.16.0 node工作节点如果还没装置docker，请参照本文步骤二装置docker-ce 18.09.9（所有机器）装置。如果没设置k8s环境筹备条件，请参照本文步骤三设置k8s环境筹备条件（所有机器）执行。 以上两个步骤查看结束之后，持续以下步骤。 装置kubeadm、kubelet# 执行配置k8s阿里云源cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF# 装置kubeadm、kubectl、kubeletyum install -y  kubeadm-1.16.0-0 kubelet-1.16.0-0# 启动kubelet服务systemctl enable kubelet && systemctl start kubelet退出集群 这里退出集群的命令每个人都不一样，能够登录master节点，应用kubeadm token create --print-join-command 来获取。获取后执行如下。# 退出集群，如果这里不晓得退出集群的命令，能够登录master节点，应用kubeadm token create --print-join-command 来获取kubeadm join 192.168.99.104:6443 --token ncfrid.7ap0xiseuf97gikl     --discovery-token-ca-cert-hash sha256:47783e9851a1a517647f1986225f104e81dbfd8fb256ae55ef6d68ce9334c6a2退出胜利后，能够在master节点上应用kubectl get nodes命令查看到退出的节点。 ...

Akri 使您能够轻松地将异构叶子设施（例如IP摄像机和USB设施）公开为Kubernetes集群中的资源，同时还反对公开嵌入式硬件资源（例如GPU和FPGA）。 Akri一直检测有权拜访这些设施的节点，并依据这些节点调度工作负载。 Why Akri在边缘，有各种各样的传感器，控制器和MCU类设施正在产生数据并执行动作。为了使Kubernetes成为可行的边缘计算解决方案，Kubernetes集群须要轻松利用这些异构的“叶子设施”。然而，许多此类叶子设施太小，无奈自行运行Kubernetes。 Akri 是一个开源我的项目，将这些叶设施公开为Kubernetes集群中的资源。它利用并扩大了 Kubernetes设施插件框架，该框架是在思考云的根底上创立的，并专一于动态资源，例如GPU和其余零碎硬件。 Akri采纳了此框架并将其利用于边缘，边缘蕴含一组具备独特通信协议和间歇可用性的叶子设施。 Akri专为边缘设计，可解决叶子设施的动态创建和销毁状况。 Akri提供了相似于CNI的形象层，然而它没有对底层网络详细信息进行形象。操作员只须要将Akri配置利用于集群，即可指定发现协定（例如ONVIF）和应部署的Pod（例如视频帧服务器）。而后剩下的事，Akri来实现。操作员还能够容许多个节点应用分支设施，从而在节点脱机的状况下提供高可用性。此外，Akri将为每种类型的叶子设施（或Akri Configuration）主动创立Kubernetes服务，从而无需应用应用程序来跟踪Pod或节点的状态。 最重要的是，Akri被构建为可扩大的。咱们目前领有ONVIF和udev发现协定，并且正在努力实现OPC UA，同时社区成员能够轻松增加更多协定。 Akri反对的协定越多，Akri能够发现的叶子设施的范畴越广。 Akri 工作原理Akri的架构由四个要害组件组成： Akri Configuration CRDAkri Instance CRDAgent( 一个设施插件实现)一个自定义控制器您能够在第一个自定义资源Akri Configuration中对其进行命名。这通知Akri应该寻找哪种设施。 Akri的设施插件实现会应用Akri的第二个自定义资源Akri Instance查找设施并跟踪其可用性。找到设施后，Akri Controller能够帮忙您应用它。它查看每个Akri实例（代表叶子设施），并部署一个“broker” Pod，该Pod晓得如何连贯到资源并加以利用。 对于该架构深度解析，大家能够参考官网文档。 示例咱们通过官网的一个示例，来加深对Arki的了解。 作为解决动静共享叶设施的示例，曾经为ONVIF摄像机协定创立了一个实现。 ONVIF是许多IP摄像机应用的规范，它定义了RTSP摄像机流的发现和拜访。除了用于ONVIF的协定实现外，Akri还提供了ONVIF配置和示例代理（akri-onvif-video-broker），它充当帧服务器。 应用Akri的默认ONVIF配置来发现和利用ONVIF摄像机如下所示： 操作员将ONVIF配置利用于集群。Akri Agent 应用ONVIF协定发现IP摄像机，并为每个发现的摄像机创立实例。Akri控制器将看到实例并部署在配置中指定的akri-onvif-video-broker pod。控制器还将为每个ONVIF摄像机创立一个Kubernetes服务，并为所有ONVIF摄像机创立一个服务。该我的项目由微软开源主导，能够完满配合k3s 等基于k8s实现的边缘框架。我的项目实现语言为rust。

前两篇说了ceph集群搭建及rbd的应用等一些性能，然而ceph毕竟是作为一个存储，须要集成到利用中，rdb反对多种设施应用，大体上有libvirt,OpenStack,CloudStack,Kubernetes当初应用ceph作为k8s的存储，也就是ceph-rbd和StorageClass相结合，为pod提供存储，没有k8s集群能够应用kubeadm搭建 Ceph集群中创立资源等配置创立存储池并设定pg和pg_numceph osd pool create kubernetes 32 32初始化存储池rbd pool init kubernetes创立client用户拜访过程池ceph auth get-or-create client.kubernetes mon 'profile rbd' osd 'profile rbd pool=kubernetes' mgr 'profile rbd pool=kubernetes'Kubernetes装置ceph-rbd驱动配置每台k8s节点装置ceph-rbd命令包yum install ceph-common设置ceph-cm配置文件clusterID为你ceph集群idmonitors为你ceph的mon服务地址---apiVersion: v1kind: ConfigMapdata: config.json: |- [ { "clusterID": "9bb7af93-99f3-4254-b0b3-864f5d1413e4", "monitors": [ "192.168.21.100:6789", "192.168.21.101:6789", "192.168.21.102:6789" ] } ]metadata: name: ceph-csi-config namespace: ceph-stkubectl apply -f csi-config-map.yaml创立拜访ceph集群的证书，userID为下面创立的name，userKey为生成的key，遗记应用ceph auth list查看cat <<EOF > csi-rbd-secret.yamlmetadata: name: csi-rbd-secret namespace: defaultstringData: userID: kubernetes userKey: AQCb7mpfCr4oGhAAalv/q8WSnUE/vyu59Ge3Hg==EOF装置ceph-rbd驱动程序wget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-provisioner-rbac.yamlwget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-nodeplugin-rbac.yamlwget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin-provisioner.yamlwget https://raw.githubusercontent.com/ceph/ceph-csi/master/deploy/rbd/kubernetes/csi-rbdplugin.yaml[root@k8s-master rbd]# cat ceph-csi-encryption-kms-config.yaml apiVersion: v1kind: ConfigMapdata: config.json: |- { "vault-test": { "encryptionKMSType": "vault", "vaultAddress": "http://vault.default.svc.cluster.local:8200", "vaultAuthPath": "/v1/auth/kubernetes/login", "vaultRole": "csi-kubernetes", "vaultPassphraseRoot": "/v1/secret", "vaultPassphrasePath": "ceph-csi/", "vaultCAVerify": "false" } }metadata: name: ceph-csi-encryption-kms-config namespace: ceph-stkubectl apply -f ./创立StorageClass---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: csi-rbd-sc namespace: ceph-stprovisioner: rbd.csi.ceph.comparameters: clusterID: 9bb7af93-99f3-4254-b0b3-864f5d1413e4 pool: kubernetes csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret csi.storage.k8s.io/provisioner-secret-namespace: ceph-st csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret csi.storage.k8s.io/node-stage-secret-namespace: ceph-st imageFeatures: "layering"reclaimPolicy: DeletemountOptions: - discard创立PVC测试性能查看服务状态 ...

摘要：有没有办法绕开CCE的限度，自在的调用K8s的API呢？有还便宜，2.4元/集群/天。申明：所有的一切都是为了使得华为云能够更好，而不是为了diss它。 通过华为云购买多个K8s集群，又想应用原生K8s接口调用这些集群，有什么好的形式？目前应用CCE服务的API仍然是最好的抉择。但同时CCE的API又存在诸多限度，如API限流，局部原生接口未凋谢等。那有没有办法绕开CCE的限度，自在的调用K8s的API呢？本文就是给出一个绕开“防线”的思路。欢送交换斧正~ 一、应用场景+遇到的艰难应用场景：我有多个K8s集群。我的“治理模块”（即主零碎，是一个批处理零碎）跑在一个独立的VPC中，与干活的K8s隔离。而后会调用K8s的接口，投递Job工作到对应的K8s集群中开始干活。如下图： 以后遇到的艰难：限流+局部API未裸露。所以心愿能有一条上图黄色的通道。 1.1 给每个K8s集群，买个EIP呗？显然，可行性没问题。然而这个计划并不好： （1） EIP须要额定付费，价格也不便宜。 （2） EIP是互联网地址，明明我所有程序都在华为云，为什么报文要走互联网绕一圈。 （3） K8s集群并不想对互联网内部裸露，徒增平安危险。 那看看其余形式吧 1.2 华为云VPC买通服务 VPC-endpoint咱们晓得跨vpc（特地是跨租户的vpc），可通过华为云的 vpc-endpoint 服务实现连贯通道的买通。 参考：https://support.huaweicloud.c... 既然EIP不适合，那咱们就走全副华为云内网的 vpc-endpoint 计划吧。 二、跨VPC买通通道定下整体计划是就是利用 vpc-endpoint 来买通绕开CCE API-Server的限度。 以下就是操作过程： 2.1 VPCEP间接连3台K8s-Master。（失败）每个CCE集群，都会有一个内网拜访的IP地址。其Master的IP能够在界面看到。 那咱间接让 vpc-endpoint 对接这个IP不就完了么？ 如下图： 想法尽管好，可是事实是残暴的。 （1） CCE给出的这个内网IP地址是一个vip（虚IP），自身是用来保障可靠性的。当某台master挂了，会主动漂移到其余2台Master下面。 （2） 通过确认：Vpc-endpoint应用的是vxlan隧道，走的是点对点协定。 也就是vpcep会最终绑定到Master节点的理论IP地址。当vip产生漂移时，vpcep就会生效（不反对自动检测漂移，须要从新绑定到新的节点）。 所以也就没方法通过vpcep间接连3台Master了。 三、通过ELB直达一次连K8s-Mastervpcep服务以后只能对接 （1）ELB实例 or （2）具体的ECS 这2种后端。 而这里咱们有3台Master节点，显然第（2）种就不适合。所以咱就走（1）elb实例吧。 接下来==》那咱重点剖析 “k8s集群怎么对接elb”吧。 3.1 应用CCE提供的：Service绑定elb性能。（失败）K8s自带了一个拜访api-server的 service。 所有集群外面的容器，都能够通过这个地址，拜访Master。 那咱们通过elb去连贯这个svc，不就能够了么？ 依据CCE的文档，操作起来： https://support.huaweicloud.c... 给SVC设置一个：annotation，带上elb实例id。走起~ 嗯？报错了。。 k8s外面的controller报错说：连elb的svc必须要有selector。 ...

Kubernetes网络模型的外围要求之一是每个Pod应该取得本人的IP地址，并且集群中的每个Pod应该可能应用该IP地址与其进行对话。有几种网络提供商（flannel, calico, canal等）实现此网络模型。 当我开始应用Kubernetes时，我还不分明如何为每个Pod调配IP地址。我理解了各个组件如何独立工作，然而还不分明这些组件如何组合在一起。例如，我理解了什么是CNI插件，然而我不晓得它们是如何被调用的。因而，我想写这篇文章来分享我对各种网络组件的理解，以及如何将它们组合到kubernetes集群中，以便每个Pod都能接管IP地址。在kubernetes中有多种设置网络的办法，以及容器运行时的各种选项。在这篇文章中，我将应用Flannel作为网络提供者，并应用Containered作为容器运行时。另外，我将假设您晓得容器网络的工作原理，并且仅在上下文中分享一个十分简短的概述。 一些背景概念容器网络概述有一些十分好的博客解释了容器网络的工作形式。就上下文而言，我将在这里通过波及Linux网桥网络和数据包封装的繁多办法在一个十分高级的概述中进行介绍。 同一主机上的容器在同一主机上运行的容器能够通过其IP地址互相通信的办法之一是通过linux bridge。在kubernetes（和docker）世界中，创立了veth（虚构以太网）设施来实现此目标。此veth设施的一端插入容器网络名称空间，另一端连贯到主机网络上的linux bridge。同一主机上的所有容器都将veth对的一端连贯到linux网桥，并且它们能够通过网桥应用其IP地址互相通信。 linux网桥也被调配了一个IP地址，它充当从目的地到不同节点的Pod流出流量的网关。 不同主机上的容器在不同主机上运行的容器能够通过其IP地址互相通信的形式之一是应用数据包封装。 Flannel通过vxlan反对此性能，vxlan将原始数据包包装在UDP数据包中并将其发送到指标。在kubernetes集群中，Flannel在每个节点上创立一个vxlan设施和一些路由表条目。每个发往不同主机上的容器的数据包都会通过vxlan设施，并封装在UDP数据包中。在指标地位，检索封装的数据包，而后将数据包路由到目的地的pod。 留神：这只是能够配置容器之间的网络的办法之一。什么是 CRI?CRI（容器运行时接口）是一个插件接口，容许kubelet应用不同的容器运行时。各种容器运行时都实现了CRI API，这使用户能够在kubernetes装置中应用他们抉择的容器运行时。 什么是 CNI?CNI我的项目蕴含一个标准，可为Linux容器提供基于通用插件的联网解决方案。它还由各种插件组成，这些插件在配置Pod网络时执行不同的性能。 CNI插件是遵循CNI标准的可执行文件，咱们将在上面的文章中探讨一些插件。 为节点调配Pod IP地址的子网如果要求所有Pod具备IP地址，那么确保整个集群中的所有Pod具备惟一的IP地址十分重要。这是通过为每个节点调配一个惟一的子网来实现的，从该子网中为Pod调配了该节点上的IP地址。 Node IPAM Controller将nodeipam作为选项传递给kube-controller-manager的--controllers命令行标记时，它将为每个节点调配来自集群CIDR（集群网络的IP范畴）的专用子网（podCIDR）。因为这些podCIDR是不相交的子网，因而它容许为每个Pod调配一个惟一的IP地址。当Kubernetes节点首次向集群注册时，会为其调配一个podCIDR。要更改调配给集群中节点的podCIDR，须要先登记节点，而后应用首先利用于kubernetes管制立体的任何配置更改来从新注册节点。能够应用以下命令列出节点的podCIDR。 $ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'10.244.0.0/24Kubelet，容器运行时和CNI插件-如何将它们全副组合在一起当在节点上调度Pod时，启动Pod会产生很多事件。在本节中，我将仅着重与为Pod配置网络无关的交互。一旦在节点上调度了Pod，以下交互将导致配置网络并启动应用程序容器。 容器运行时与CNI插件之间的交互每个网络提供商都有一个CNI插件，容器运行时会调用该插件，以在Pod启动时为其配置网络。应用容器化作为容器运行时，容器化CRI插件将调用CNI插件。每个网络提供商都在每个kubernetes节点上都装置了一个代理，以配置pod网络。装置了网络提供商代理后，它要么随CNI配置一起提供，要么在节点上创立一个，而后由CRI插件用来确定要调用哪个CNI插件。 CNI配置文件的地位是可配置的，默认值为/etc/cni/net.d/<config-file>。集群管理员须要在每个节点上交付CNI插件。 CNI插件的地位也是可配置的，默认值为/opt/cni/ bin。 如果应用容器作为容器运行时，则能够在容器配置的[plugins."io.containerd.grpc.v1.cri".cni]局部下指定CNI配置和CNI插件二进制文件的门路。 因为咱们在这里将Flannel称为网络提供商，因而我将简要介绍Flannel的设置形式。 Flanneld是Flannel守护程序，通常作为守护程序安装在kubernetes集群上，并以install-cni作为初始化容器。 install-cni容器在每个节点上创立CNI配置文件-/etc/cni/net.d/10-flannel.conflist。 Flanneld创立一个vxlan设施，从apiserver获取网络元数据，并监督pod上的更新。创立Pod时，它将为整个集群中的所有Pod调配路由，这些路由容许Pod通过其IP地址相互连接。 容器式CRI插件和CNI插件之间的交互能够如下所示： 如上所述，kubelet调用Containered CRI插件以创立容器，而Containered CRI插件调用CNI插件为容器配置网络。网络提供商CNI插件调用其余根本CNI插件来配置网络。 CNI插件之间的交互如下所述。 CNI插件之间的交互各种CNI插件可帮忙配置主机上容器之间的网络。对于这篇文章，咱们将参考3个插件。 Flannel CNI Plugin当应用Flannel作为网络提供程序时，Containered CRI插件应用CNI配置文件/etc/cni/net.d/10-flannel.conflist调用Flannel CNI插件。 $ cat /etc/cni/net.d/10-flannel.conflist{ "name": "cni0", "plugins": [ { "type": "flannel", "delegate": { "ipMasq": false, "hairpinMode": true, "isDefaultGateway": true } } ]}Fannel CNI插件与Flanneld联合应用。当Flanneld启动时，它会从apiserver中获取podCIDR和其余与网络相干的详细信息，并将它们存储在文件-run/flannel/subnet.env中。 ...

又一次偷偷化解了可能产生的重大事故。不想看过程的能够间接跳到开端看解决计划。 一个网络谬误某天，上kplcloud构建一个测试利用，构建实现之后发现新pod始终启动失败，并且抛出了以下错误信息: Failed create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up pod "xxxxxx-fc4cb949f-gpkm2_xxxxxxx" network: netplugin failed but error parsing its diagnostic message "": unexpected end of JSON input 会k8s的运维同学早已不在，忽然出问题了怎么办？ 试着开始解决问题。 一、有没有可能是镜像拉取失败，开始找问题:登录集群所有服务器查看空间是否占满（然而并没有占满）查问集群所有服务器网络状况（也没有问题）再启一个pod试试？（起不来）这就难堪了......，有没有可能是calico的问题？ 二、查看服务器报错信息尝试以下命令看服务器的报错信息: $ journalctl -exf 的确有一些错误信息: 这个谬误太宽泛了，持续尝试从其余中央找找问题。 此时曾经开始在思考如何跑路的问题了... 要不尝试从重启是否解决？ 危险太大，不能冒险。尽管很多时候重启能解决大部分问题，但重启docker、k8s在这种状况下不是最佳抉择。 持续搜刮日志，猜想是无奈调配IP的问题，那指标转向calico 从calico-node下面找问题 查问ip池是否用完。 应用calicoamd命令查问calico是否失常失常运行 $ calicoctl get ippools -o wideCIDR NAT IPIP172.20.0.0/16 true false$ calicoctl node status ...

Contour持续增加新性能，以帮忙大家更好地治理集群中的ingress操作。咱们的最新release版本Contour 1.9.0当初包含： 对外部受权的反对，从而能够依据受权服务器验证申请。CORS反对反对提供用于TLS的客户端证书，以验证后端服务迁徙到v1自定义资源定义（CRD）。内部受权的反对当初，能够利用Contour的内部受权反对来受权对ingress资源的传入申请。当初，Contour启用了Envoy中的内部受权网络过滤器，该过滤器调用内部受权服务以查看传入申请是否被受权。如果网络过滤器认为该申请是未受权的，则连贯将被敞开。 对这项新性能的反对依赖于名为ExtensionService的新自定义资源定义（CRD）。这个新的API形容了Envoy如何连贯到内部受权服务器。 内部验证的事件程序： 将一个内部受权服务部署到您的群集：此服务与您的Auth Provider进行对话，并确定是否应受权该申请。创立ExtensionService CRD：此CRD容许在上一步中创立的内部受权服务可用，以便Contour能够应用该gRPC端点配置Envoy。创立HTTPProxy资源：ingress对象中的VirtualHost援用将虚拟主机链接到受权服务的ExternalService CRD。在每个客户申请中，Envoy都会向内部验证服务发送受权查看以确定受权。CORS 反对Contour的HTTPProxy API当初反对指定CORS策略，该策略配置了Envoy的CORS过滤器，以容许网络应用程序申请来自不同起源的资源。CORS应用其余HTTP标头来通知浏览器，使运行在一个终点上的Web应用程序能够拜访来自其起源（域，协定或端口）不同的选定资源。 在此示例中，跨域申请将被容许用于任何域（请留神*值): apiVersion: projectcontour.io/v1kind: HTTPProxyspec: virtualhost: fqdn: local.projectcontour.io corsPolicy: allowCredentials: true allowOrigin: - "*" # allows any origin allowMethods: - GET - POST - OPTIONS allowHeaders: - authorization - cache-control exposeHeaders: - Content-Length - Content-Range maxAge: "10m" # preflight requests can be cached for 10 minutes. routes: - conditions: - prefix: / services: - name: s1 port: 80反对提供用于TLS的客户端证书，以验证后端服务Contour当初反对可选地指定Envoy应该提供给Kubernetes的Kubernetes secret，以作为TLS的客户端证书，以便上游服务能够验证来自Envoy的连贯。 ...

您是否想晓得站点可靠性工程（SRE）团队如何无效地治理简单的应用程序？在Kubernetes生态系统中，只有一个答案：Kubernetes Operator！在本文中，咱们将钻研它们是什么以及它们如何工作。 Kubernetes Operator概念是由CoreOS的工程师于2016年提出的，它是在Kubernetes集群上构建和驱动每个应用程序的高级原生办法，须要特定畛域的常识。通过与Kubernetes API的密切合作，它提供了一种统一的办法来主动解决所有应用程序操作流程，而无需任何人工响应。换句话说，Operator是打包，运行和治理Kubernetes应用程序的一种形式。 Kubernetes Operator模式的行为遵循外围Kubernetes原理之一：管制实践。在机器人技术和自动化中，它是一种间断运行动静零碎的机制。它依赖于一种能力，即尽可能精确地依据可用资源疾速调整工作负载需要。目标是开发具备必要逻辑的管制模型，以帮忙应用程序或零碎保持稳定。在Kubernetes世界中，该局部由控制器解决。控制器是一种非凡的软件，能够在循环中响应更改并在集群中执行调整操作。第一个Kubernetes控制器是kube-controller-manager。它被视为所有Operator的始祖。 什么是管制循环?简而言之，控制器循环是控制器动作的根底。设想一下，一个非终止过程（在Kubernetes中称为reconciliation 循环）重复产生，如下图所示： 该过程察看至多一个Kubernetes对象，该对象蕴含无关所需状态的信息。诸如...的对象 DeploymentsServicesSecretsIngressConfig Maps…由配置文件定义，这些配置文件由JSON或YAML的清单组成。而后，控制器依据内置逻辑通过Kubernetes API进行间断调整，以模拟所需状态，直到以后状态变为所需状态。 这样，Kubernetes通过解决一直的变动来应答Cloud Native零碎的动静个性。为达到预期状态而执行的批改示例包含： 留神节点何时呈现故障并须要新的节点。查看是否须要复制Pod。如果须要，请创立一个新的负载均衡器。Kubernetes Operator如何工作？Operator是特定于应用程序的控制器。它扩大了Kubernetes API以代表人员（操作工程师或站点可靠性工程师）创立，配置和治理简单的应用程序。让咱们看看Kubernetes文档对此有何评论。Operator是Kubernetes的软件扩大，它利用自定义资源来管理应用程序及其组件。Operator遵循Kubernetes准则，尤其是管制回路。 到目前为止，您晓得Operator利用了察看Kubernetes对象的控制器。这些控制器有点不同，因为它们跟踪的是自定义对象，通常称为自定义资源（CR）。 CR是Kubernetes API的扩大，它提供了一个能够存储和检索结构化数据（应用程序的冀望状态）的中央。下图显示了整个操作原理。 Operator间断跟踪与特定类型的定制资源无关的集群事件。能够跟踪的这些自定义资源上的事件类型为： AddUpdateDelete当Operator接管到任何信息时，它将采取行动将Kubernetes集群或内部零碎调整为所需状态，作为其自定义控制器中reconciliation 循环的一部分。 如何减少一个Custom Resource自定义资源通过增加对你的应用程序有帮忙的新对象，扩大了Kubernetes的性能。 Kubernetes提供了两种向集群增加自定义资源的办法： 通过API聚合，这是一种高级办法，须要您构建本人的API服务器，但能够为您提供更多控制权通过自定义资源定义（CRD），这是一种无需任何编程常识即可创立的简略办法，是对原始Kubernetes API服务器的扩大。这两个选项可满足不同用户的需要，他们能够在灵活性和易用性之间进行抉择。 Kubernetes社区创立了一个比拟，能够帮忙您确定适宜您的办法，然而最受欢迎的抉择是CRD。 Custom Resource Definitions自定义资源定义曾经存在了很长一段时间。 Kubernetes 1.16.0公布了第一个次要的API标准。以下清单提供了一个示例： apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinitionmetadata: name: application.stable.example.com spec: group: stable.example.com version: v1 scope: Namespaced names: plural: application singular: applications kind: Application shortNames: - app 通过此CRD，您能够创立一个称为“Application”的CR。前两行定义要创立的对象类型CustomResourceDefinition的apiVersion apiextensions.k8s.io/v1beta1。元数据形容了资源的名称，但最重要的中央是“ spec”字段。它使您能够指定组和版本以及可见性范畴（命名空间或集群范畴）。之后，您能够应用多种格局定义名称并创立一个不便的简称，该名称使您能够执行命令kubectl get app来获取现有的CR。 Custom Resource下面的CRD容许您创立以下自定义资源清单。 ...

一、部署阐明能够应用kubesphere，疾速搭建MySQL环境。 有状态服务抽取配置为 ConfigMap有状态服务必须应用 pvc 长久化数据服务集群内拜访应用 DNS 提供的稳固域名 k8s部署有状态服务的话就是参照下面的图。部署具体阐明： 有状态服务抽取配置为ConfigMap在之前咱们应用Docker 部署MySQL的时候也会将conf、logs、data等数据挂载到宿主机上，那么在k8s外面的话专门有一个空间是治理配置文件的也就是下面提到的ConfigMap，能够将一些罕用的配置抽离进去做成ConfigMap配置，起初不论是MySQL挂了重启还是创立新的MySQL都可已应用同一个ConfigMap中的配置，这也就是第一点将有状态服的配置抽离到ConfigMap中来，这样前期批改配置就只须要更改ConfigMap就行了有状态服务必须应用PVC长久化数据每个MySQL都会用本人的数据存储，那么在k8s中存在一个专门存储数据的空间，也就是下面提到的PVC， 每一个MySQL都会调配一个PVC数据存储空间，或者共享一个PVC空间，也就是想Docker挂载进去的data目录一样，在Docker中的MySQL容器重启后MySQL中的数据还存在，那么k8s中的MySQL挂掉后重启后也会在PVC中找长久化的数据，那么这样就不会存在在其余节点拉起MySQL存在数据失落的问题了服务集群内拜访应用DNS提供稳固的域名在下面图中存在一个主节点MySQL和两个从节点MySQL，在这个MySQL集群中个节点间是要互相通信拜访的，这里实现各节点间通信拜访的话就须要应用Headless Service服务，这个服务就是集群两头互相拜访的，在k8s中最小的部署单元是pod，如MySQL0就是一个pod，那么咱们将这个pod包装成一个Service，同时让k8s为这个Service生成一个域名，DNS为这个服务提供一个稳固域名，如图上为MySQL0这个服务提供了mysql-0.test域名，其余的pod对外裸露服务后也会提供相应的域名，那么各节点通信就能够应用域名拜访，这里提供域名的益处就是避免某台对外裸露的服务忽然挂掉了，在别的机器上拉起，那么这时的ip就会产生扭转，那么集群内的所有利用，包含服务本人都能够应用域名来拜访二、创立主从有状态服务1、创立mysql master有状态服务 操作步骤：1)、根本信息： 2)、容器镜像：设置MySQL容器镜像，MySQL:5.7 版本，内存设置为2G，环境变量应用之前设置好的MySQL密钥。 3)、挂载存储： 这里能够挂载配置文件或密钥，所以，接下来另开一个窗口，在配置核心->配置，创立配置文件： ①、创立配置根本信息 ②、设置mysql配置文件my.cnf [client]default-character-set=utf8[mysql]default-character-set=utf8[mysqld]init_connect='SET collation_connection = utf8_unicode_ci'init_connect='SET NAMES utf8'character-set-server=utf8collation-server=utf8_unicode_ciskip-character-set-client-handshakeskip-name-resolve#master-slaver repicationserver_id=1log-bin=mysql-binread-only=0binlog-do-db=gulimall_umsbinlog-do-db=gulimall_pmsbinlog-do-db=gulimall_omsbinlog-do-db=gulimall_smsbinlog-do-db=gulimall_wmsbinlog-do-db=gulimall_adminreplicate-ignore-db=mysqlreplicate-ignore-db=sysreplicate-ignore-db=information_schemareplicate-ignore-db=performance_schema my.cnf配置内容间接复制粘贴到如下文本框内即可，kubesphere提供了可视化界面，也提供了yaml编辑模式，咱们能够点击编辑模式查看yaml文件是如何写的。 mysql-master-cnf.yaml编辑模式： apiVersion: v1kind: ConfigMapmetadata: namespace: gulimall labels: app: mysql-master-cnf name: mysql-master-cnf annotations: kubesphere.io/alias-name: master配置spec: template: metadata: labels: app: mysql-master-cnfdata: my.cnf: |- [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] init_connect='SET collation_connection = utf8_unicode_ci' init_connect='SET NAMES utf8' character-set-server=utf8 collation-server=utf8_unicode_ci skip-character-set-client-handshake skip-name-resolve #master-slaver repication server_id=1 log-bin=mysql-bin read-only=0 binlog-do-db=gulimall_ums binlog-do-db=gulimall_pms binlog-do-db=gulimall_oms binlog-do-db=gulimall_sms binlog-do-db=gulimall_wms binlog-do-db=gulimall_admin replicate-ignore-db=mysql replicate-ignore-db=sys replicate-ignore-db=information_schema replicate-ignore-db=performance_schema配置设置好之后，而后点击创立就创立好了： ...

作者：Jessie翻译：Bach（才云） 校对：星空下的文仔（才云）、bot（才云） 随着 Kubernetes v1.16 推出了一段时间，许多 Kubernetes 托管平台已开始应用，大家应该曾经据说过弃用 API（API Deprecation），这事看似简略，但如果不加留神，也会重大影响服务。 K8sMeetup 什么是弃用 API？ 随着 Kubernetes 性能的倒退，API 也必须跟着倒退以反对变动，不是每个版本都会呈现这种状况，但最终，咱们都必须应用新版本和新格局的 API，因为旧的 API 版本和格局不再被反对。 K8sMeetup 为什么 v1.16 特地重要？ 在 Kubernetes 之前版本中保留的一些弃用 API，在 v1.16 中被彻底删除，即以下 API Group 和版本： Deployment — extensions/v1beta1、apps/v1beta1 和 apps/v1beta2NetworkPolicy — extensions/v1beta1PodSecurityPolicy — extensions/v1beta1DaemonSet — extensions/v1beta1 和 apps/v1beta2StatefulSet — apps/v1beta1 和 apps/v1beta2ReplicaSet — extensions/v1beta1、apps/v1beta1 和 apps/v1beta2如果咱们在 v1.16 中，尝试应用其中任何一种来创立资源，都会齐全失败。 K8sMeetup 如何查看是否受影响？ 咱们能够手动遍历所有 manifest ，但这会十分耗时，并且如果有多个团队部署在集群中，或者没有将所有 manifest 放在一个中央，那么很容易会漏掉。这种做法也有点不切实际，不过 Kube-No-Trouble（kubent）在此就能够施展其作用。 K8sMeetup 如何检测？ ...

前言公有仓库用于企业外部公有 Docker 镜像的存储。 能够将公有仓库装置到 K8S 集群中。 Harbor 镜像仓库是由 VMware 开源的一款企业级镜像仓库零碎。 更新历史20200719 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/19/harbor.html自定义证书openssl genrsa -out ca.key 4096openssl req -x509 -new -nodes -sha512 -days 3650 -subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=zuolinux.com" -key ca.key -out ca.crtopenssl genrsa -out harbor.zuolinux.com.key 4096openssl req -sha512 -new -subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=zuolinux.com" -key harbor.zuolinux.com.key -out harbor.zuolinux.com.csrcat > v3.ext <<-EOFauthorityKeyIdentifier=keyid,issuerbasicConstraints=CA:FALSEkeyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEnciphermentextendedKeyUsage = serverAuthsubjectAltName = @alt_names[alt_names]DNS.1=harbor.zuolinux.comDNS.2=*.harbor.zuolinux.comDNS.3=hostnameEOFopenssl x509 -req -sha512 -days 3650 \ -extfile v3.ext \ -CA ca.crt -CAkey ca.key -CAcreateserial \ -in harbor.zuolinux.com.csr \ -out harbor.zuolinux.com.crtopenssl x509 -inform PEM -in harbor.zuolinux.com.crt -out harbor.zuolinux.com.cert装置 harborhelm install nginx-ingress --set "rbac.create=true,controller.service.externalIPs[0]=192.168.10.15" apphub/nginx-ingresskubectl create ns harborkubectl create secret tls harbor.zuolinux.com --key harbor.zuolinux.com.key --cert harbor.zuolinux.com.crt -n harborhelm repo add harbor https://helm.goharbor.iohelm repo updatehelm install harbor --namespace harbor harbor/harbor \ --set expose.ingress.hosts.core=core.harbor.zuolinux.com \ --set expose.ingress.hosts.notary=notary.harbor.zuolinux.com \ --set expose.tls.secretName=harbor.zuolinux.com \ --set persistence.enabled=false \ --set externalURL=https://core.harbor.zuolinux.com \ --set harborAdminPassword=明码查看装置状况和服务地址 ...

前言StorageClass 相当于一个创立 PV 的模板，用户通过 PVC 申请存储卷，StorageClass 通过模板主动创立 PV，而后和 PVC 进行绑定。 更新历史20200712 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/12/storageclass.html启用动静卷供给创立 StorageClass 对象即可，即创立了模板。 apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: slowprovisioner: kubernetes.io/gce-pdparameters: type: pd-standard--- apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: fastprovisioner: kubernetes.io/gce-pdparameters: type: pd-ssd以上文件创建了两种不同类型的 StorageClass，用户依据本人需要通过 PVC 申请即可。 应用动静卷供给用户通过 PVC 来申请。 apiVersion: v1kind: PersistentVolumeClaimmetadata: name: claim1spec: accessModes: - ReadWriteOnce storageClassName: fast resources: requests: storage: 30Gi以上文件阐明该 PVC 向 storageClassName 为 fast 的存储类申请卷，将会失去一个 PV 来与该 PVC 进行绑定。 实际《K8S实战（六）| 配置NFS动静卷提供长久化存储》 https://blog.zuolinux.com/2020/06/10/nfs-client-provisioner.html ...

前言PV 用来定义长久化存储卷，可将内部存储如 NFS/GFS/CFS 等定义为一个 K8S 外部对象，是一个服务提供者。 PVC 会寻找适合的 PV 进行绑定，绑定胜利后，PVC 就能够提供给 pod 应用。 更新历史20200710 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/10/storage-pv-pvc.html定义 PV/PVC定义一个 PV [root@master01 ~]# cat pv.yaml apiVersion: v1kind: PersistentVolumemetadata: name: nfs1-pvspec: storageClassName: manual capacity: storage: 1Gi accessModes: - ReadWriteMany nfs: server: 192.168.10.17 path: "/data/nfs"定义一个 PVC [root@master01 ~]# cat pvc.yaml apiVersion: v1kind: PersistentVolumeClaimmetadata: name: nfs1-pvcspec: accessModes: - ReadWriteMany storageClassName: manual resources: requests: storage: 1Gi# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs1-pv 1Gi RWX Retain Released default/nfs1-pvc manual 118s# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEnfs1-pvc Pending manual 14sPVC 会查找 storageClassName 名称统一的 PV，而后在这些 PV 中查找满足 spec.resources.requests.storage 条件的 PV，找到后就绑定 PVC 到该 PV 上。 ...

前言容器中的文件在磁盘上是长期寄存，容器解体重启后，容器将被以洁净状态重建，解体之前创立的文件将被革除。 K8S 应用卷的概念来治理容器生成的需长久化的文件，卷也可用于同一个 Pod 中多个容器之间共享文件。 更新历史20200708 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/08/about-storage-volume.htmlVolume 的类型emptyDir 卷容器解体并不会导致 Pod 被从节点上移除，因而容器解体时 emptyDir 卷中的数据是平安的。当 Pod 因为某些起因被从节点上删除时，emptyDir 卷中的数据也会永恒删除。示例 apiVersion: v1kind: Podmetadata: name: test-pdspec: containers: - image: nginx name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}persistentVolumeClaim 卷persistentVolumeClaim 卷用来将长久卷（PersistentVolume）挂载到 Pod 中。 长久卷（PV）是用户在不晓得特定云环境细节的状况下"申领"长久存储（例如 NFS 或者 iSCSI 卷）的一种办法。 cephfs 卷cephfs 容许您将现存的 CephFS 卷挂载到 Pod 中。cephfs 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。这意味着 CephFS 卷能够被事后填充数据，并且这些数据能够在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。configMap 卷ConfigMap 资源提供了向 Pod 注入配置数据的办法。ConfigMap 对象中存储的数据能够被 configMap 类型的卷援用，而后被利用到 Pod 中运行的容器。能够在 volumes 字段中援用 configMap 名称来生成一个卷。能够自定义 ConfigMap 中特定条目所要应用的门路。如果容器以 subPath 卷挂载形式应用 ConfigMap 时，将无奈接管 ConfigMap 的更新。示例 ...

前言ConfigMap 对象能够用来治理一般的、非秘密的配置信息，以明文模式寄存。 Secret 对象用来治理重要的、秘密的、不能泄露的相似秘钥、明码等信息。 ConfigMap 对象能够实现程序的配置和程序自身的解耦，从而使程序更具移植性。 更新历史20200705 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/07/05/about-configmap.html通过目录/文件创建 ConfigMap从目录创立 mkdir configmapwget https://kubernetes.io/examples/configmap/game.properties -O configmap/game.propertieswget https://kubernetes.io/examples/configmap/ui.properties -O configmap/ui.propertieskubectl create configmap game-config --from-file=configmap/能够看到两个文件内容合并存储到 data 中，文件名转换为 key # kubectl get configmap game-config -o yamlapiVersion: v1data: game.properties: |- enemies=aliens lives=3 enemies.cheat=true enemies.cheat.level=noGoodRotten secret.code.passphrase=UUDDLRLRBABAS secret.code.allowed=true secret.code.lives=30 ui.properties: | color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNicekind: ConfigMap。。。。。。通过文件创建 kubectl create configmap game-config-2 --from-file=configmap/game.properties通过多个文件创建 成果和通过目录创立一样 kubectl create configmap game-config-2 --from-file=configmap/game.properties --from-file=configmap/ui.properties从环境文件创建 ConfigMap ...