Kubernetes

能够应用 kubectl describe 命令查看一个 pod 的详细信息，其中也包含健康检查的配置信息。 具体命令为： kubectl describe pod <pod-name>在输入信息中，找到 Containers 上面的容器信息，而后找到 Liveness 和 Readiness 的相干配置。例如： Containers: my-container: Container ID: docker://abc123456789 Image: my-image:v1.0.0 ... Liveness: tcp-socket :8080 delay=30s timeout=1s period=10s # <--- 这里是健康检查的配置 Readiness: tcp-socket :8080 delay=30s timeout=1s period=10s # <--- 这里是健康检查的配置 ...能够看到，在这个 pod 的 my-container 容器中，Liveness 和 Readiness 的查看频率都是 10 秒。其中，period=10s 指定了查看的频率。

DataCap是用于数据转换、集成和可视化的集成软件，反对多种数据源、文件类型、大数据相干数据库、关系数据库、NoSQL数据库等。通过该 DataCap 能够实现对多个数据源的治理，对数据源下的数据进行各种操作转换，制作数据图表，监控数据源等性能。 在 Rainbond 上部署 DataCap前提装置 Rainbond，可通过一条命令疾速装置 Rainbond。 curl -o install.sh https://get.rainbond.com && bash ./install.sh对接 Rainbond 开源利用商店并部署 DataCapDataCap 已公布到 Rainbond 开源利用商店，可通过 Rainbond 开源利用商店一键部署 DataCap。 进入 Rainbond 控制台的 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 DataCap 并装置。 装置实现后，可通过 Rainbond 提供的默认域名拜访 DataCap，默认用户明码 admin/12345678 DataCap 疾速入门增加数据源进入到 治理 -> 数据源 增加 Mysql 数据源 在 配置 中配置 MySQL 拜访地址，这里能够配置 DataCap 应用的 MySQL，拜访地址可在 MySQL 组件 -> 端口 中获取拜访地址，MySQL 默认用户明码 root/root SQL 编辑器进入到 查问 中抉择数据源，就能够在编辑器中编写SQL进行数据源的查问等相干操作。 ...

为了深刻学习 kube-scheduler，本系从源码和实战角度深度学 习kube-scheduler，该系列一共分6篇文章，如下： kube-scheduler 整体架构初始化一个 scheduler一个 Pod 是如何调度的如何开发一个属于本人的scheduler插件开发一个 prefilter 扩大点的插件开发一个 socre 扩大点的插件上一篇，咱们说了 kube-scheduler 的整体架构，是从整体的架构方面来思考的，本文咱们说说 kube-scheduler 是如何初始化进去的，kube-scheduler 外面都有些什么货色。 因为 kube-scheduler 源码内容比拟多，对于那些不是要害的货色，就疏忽不做探讨。 Scheduler之Profiles上面咱们先看下 Scheduler 的构造 type Scheduler struct { Cache internalcache.Cache Extenders []framework.Extender NextPod func() *framework.QueuedPodInfo FailureHandler FailureHandlerFn SchedulePod func(ctx context.Context, fwk framework.Framework, state *framework.CycleState, pod *v1.Pod) (ScheduleResult, error) StopEverything <-chan struct{} SchedulingQueue internalqueue.SchedulingQueue Profiles profile.Map client clientset.Interface nodeInfoSnapshot *internalcache.Snapshot percentageOfNodesToScore int32 nextStartNodeIndex int}上一篇咱们说过，为一个 Pod 抉择一个 Node 是依照固定程序运行扩大点的；在扩大点内，是依照插件注册的程序运行插件，如下图 下面的这些扩大点在 kube-scheduler 中是固定的，而且也不反对减少扩大点（实际上有这些扩大点曾经足够了），而且扩大点程序也是固定执行的。 ...

Jpom 是一个简而轻的低侵入式在线构建、主动部署、日常运维、我的项目运维监控软件。提供了： 节点治理：集群节点，对立治理多节点的我的项目，实现疾速一键散发我的项目文件项目管理：创立、启动、进行、实时查看我的项目控制台日志，治理我的项目文件SSH 终端：在浏览器中执行 SSH 终端，不便进行日常运维,记录执行命令记录在线构建：在线拉取 GIT、SVN 仓库疾速构建我的项目包，不必运维人员手动上传我的项目包在线脚本：在线治理脚本、定时执行脚本、webhook 钩子执行、执行日志等Docker治理：在线治理镜像、容器、SWARM 集群。界面化治理 DOCKER用户治理：多用户治理,实现不同用户不同权限，用户操作、治理日志欠缺记录我的项目监控：实时监控我的项目以后状态、如果异样主动触发邮件、钉钉报警告诉NGINX 配置、SSL 证书：在线疾速不便的批改 NGINX 配置文件，SSL 证书对立治理Rainbond 与 Jpom 联合 Rainbond 与 Jpom 联合能够实现云原生我的项目和本地我的项目的对立治理，例如： 应用 Rainbond 部署和治理 Jpom可通过 Jpom 构建可容器化的云原生我的项目并部署在 Rainbond 上治理和运维通过 Jpom 治理一些无奈容器化的传统我的项目以及部署通过 Jpom 治理 Rainbond 集群的服务器，可作为堡垒机应用应用 Jpom 治理脚本、执行脚本和定时脚本等。部署 Jpom前提装置 Rainbond，可通过一条命令疾速装置 Rainbond。 curl -o install.sh https://get.rainbond.com && bash ./install.sh对接开源利用商店并部署 JpomJpom 已公布到 Rainbond 开源利用商店，可通过 Rainbond 开源利用商店一键部署 Jpom。 进入 Rainbond 控制台的 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 Jpom 并装置。 装置实现后，可通过 Rainbond 提供的默认域名拜访 Jpom并登陆进行用户注册。 ...

kube-scheduler 作为 k8s 的调度器，就好比人的大脑，将口头指定传递到手脚等器官，进而执行对应的动作，对于 kube-scheduler 则是将 Pod 调配（调度）到集群内的各个节点，进而创立容器运行过程，对于k8s来说至关重要。 为了深刻学习 kube-scheduler，本系从源码和实战角度深度学 习kube-scheduler，该系列一共分6篇文章，如下： kube-scheduler 整体架构初始化一个 scheduler一个 Pod 是如何被调度的如何开发一个属于本人的scheduler插件开发一个 prefilter 扩大点的插件开发一个 socre 扩大点的插件本篇先相熟 kube-scheduler 的整体架构设计，看清全局，做到心里有数，在前面的篇章再庖丁解牛，一步步开掘细节。 咱们先看看官网是怎么形容 scheduler 的 The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. The scheduler determines which Nodes are valid placements for each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation.k8s scheduler 是一个管制面过程，它调配 Pod 到 Nodes。依据限度和可用资源，scheduler 确定哪些节点合乎调度队列里的 Pod。而后对这些合乎的节点进行打分，而后把Pod绑定到适合的节点上。一个集群内能够存在多个scheduler，而 kube-scheduler 是一个参考实现。 ...

作者：京东科技 徐宪章 1 什么是超容量扩容超容量扩容性能，是指事后调度肯定数量的工作节点，当业务高峰期或者集群整体负载较高时，能够使利用不用期待集群工作节点扩容，从而迅速实现利用横向扩容。通常状况下HPA、ClusterAutosacler和超容量扩容同时应用以满足负载敏感度高的业务场景。 超容量扩容性能是通过K8S利用优先级设置和ClusterAutosaler独特作用实现的，通过调整低优先级空载利用的数量，使集群已调度资源放弃在较高的状态，当其余高优先级利用因为HPA或者手动调整利用分片数量时，能够通过驱赶空载的形式凌空调度资源却保高优先级利用能够在第一工夫调度并创立。当空载利用从被驱赶转变为等到状态时，ClusterAutosaler此时对集群机型扩容，确保下次高优先级利用调度时，有足够的空载利用能够被驱赶。 超容量扩容性能的外围为OverprovisionAutoscaler（超容量扩容）和ClusterAutosaler(集群主动扩容)，两者都须要通过一直调整参数配置去适配多重业务需要需要。 超容量扩容性能在肯定水平上升高了资源应用饱和度，通过减少老本进步了集群和利用的稳定性，理论业务场景中须要依据需要进行取舍并合理配置。 2 什么状况下须要应用超容量扩容当集群值开启Hpa和Autoscaler时，在产生节点扩容的状况下，利用调度工夫通常为4-12分钟，次要取决于创立工作节点资源以及工作节点从退出集群到Ready的总耗时。以下为最佳和最差效率剖析 最佳案例场景－４分钟 • 30秒 - 指标指标值更新：30-60秒 • 30秒 - HPA查看指标值：30秒 - >30秒 - HPA查看指标值：30秒 - > • <2秒 - Pods创立之后进入pending状态<2秒 －Pods创立之后进入pending状态 • <2秒 - CA看到pending状态的pods，之后调用来创立node 1秒<2秒 －CA看到pending状态的pods，之后调用来创立node 1秒 • 3分钟 - cloud provider创立工作节点，之后退出k8s之后期待node变成ready 最蹩脚的状况 - 12分钟 • 60 秒 —指标指标值更新 • 30 秒 — HPA查看指标值 • < 2 秒 — Pods创立之后进入pending状态 • < 2 秒 —CA看到pending状态的pods，之后调用来创立node 1秒 • 10 分钟 — cloud provider创立工作节点，之后退出ｋ8s之后期待node变成ready ...

client-go提供了Informer机制，client能够指定监听的资源对象类型，而后Informer： 首先，全量list所有的该类型的对象；而后，监听该类型对象的变动(Add/Update/Delete)，并调用用户注册的Handler；一. 实现机制由sharedIndexInformer类型实现，整体实现机制如下图所示： Reflector负责向apiserver list&watch资源对象；Reflector list&watch到的对象及其变动，被放入DeltaFIFO队列；Informer负责pop DeltaFIFO队列的变动事件，而后： 更新对象到Indexer；调用用户注册的ResourceEventHandler； 二. 源码框架整体对外接口：sharedInformerFactory，通过map让各种resourceType的informer能够共享； 客户端调用创立进去的informer对象：sharedIndexInformer，其中包含： indexer Indexer: 索引&存储；controller Controller: 调用Reflector&FIFO&indexer实现事件的散发、LocalStore的保护；将Reflector&FIFO的逻辑串联起来；processor *sharedProcessor: 利用散发的事件，调用client的ResourceEventHandler；listwatcher ListerWatcher: 被reflector.Run()调用，进行资源对象的List&Watch；objectType runtime.Object: 监听的对象类型； 三. 源码：sharedInformerFactory如何share informerclient创立Informer的过程： 先创立sharedInformerFactory；再用factory创立informer；factory := informers.NewSharedInformerFactoryWithOptions(clientset, 10*time.Second, informers.WithNamespace(""))factory.Core().V1().Pods().Informer()sharedInformerFactory的构造： informers：保留了所有已创立的sharedIndexInformer；startedInformers: 保留了所有已启动的sharedIndexInformer：// staging/src/k8s.io/client-go/informers/factory.gotype sharedInformerFactory struct { ... informers map[reflect.Type]cache.SharedIndexInformer startedInformers map[reflect.Type]bool ...}底层client-go创立podInformer: // staging/src/k8s.io/client-go/informers/core/v1/interface.go// Pods returns a PodInformer.func (v *version) Pods() PodInformer { return &podInformer{factory: v.factory, namespace: v.namespace, tweakListOptions: v.tweakListOptions}}// staging/src/k8s.io/client-go/informers/core/v1/pod.gofunc (f *podInformer) Informer() cache.SharedIndexInformer { return f.factory.InformerFor(&corev1.Pod{}, f.defaultInformer)}InformerFor()执行创立，并将podInformer增加到factory: ...

二进制装置Kubernetes（k8s） v1.27.1 IPv4/IPv6双栈 可脱离互联网https://github.com/cby-chen/Kubernetes 开源不易，帮忙点个star，谢谢了 介绍kubernetes（k8s）二进制高可用装置部署，反对IPv4+IPv6双栈。 我应用IPV6的目标是在公网进行拜访，所以我配置了IPV6动态地址。 若您没有IPV6环境，或者不想应用IPv6，不对主机进行配置IPv6地址即可。 不配置IPV6，不影响后续，不过集群仍旧是反对IPv6的。为前期留有扩大可能性。 若不要IPv6 ，不给网卡配置IPv6即可，不要对IPv6相干配置删除或操作，否则会出问题。 强烈建议在Github上查看文档 ！！！Github出问题会更新文档，并且后续尽可能第一工夫更新新版本文档 ！！！手动我的项目地址：https://github.com/cby-chen/Kubernetes1.环境主机名称IP地址阐明软件 192.168.1.60外网节点下载各种所需安装包Master01192.168.0.31master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxMaster02192.168.0.32master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxMaster03192.168.0.33master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxNode01192.168.0.34node节点kubelet、kube-proxy、nfs-client、nginxNode02192.168.0.35node节点kubelet、kube-proxy、nfs-client、nginx 192.168.0.36VIP 软件版本kernel5.4.240CentOS 8v8、 v7、Ubuntukube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxyv1.27.1etcdv3.5.8containerdv1.6.20dockerv23.0.3cfsslv1.6.4cniv1.2.0crictlv1.26.1haproxyv1.8.27keepalivedv2.1.5网段 物理主机：192.168.0.0/24 service：10.96.0.0/12 pod：172.16.0.0/12 安装包曾经整顿好：https://github.com/cby-chen/Kubernetes/releases/download/v1.27.1/kubernetes-v1.27.1.tar 1.1.k8s根底零碎环境配置1.2.配置IPssh root@192.168.0.345 "nmcli con mod eth0 ipv4.addresses 192.168.0.31/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@192.168.0.347 "nmcli con mod eth0 ipv4.addresses 192.168.0.32/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@192.168.0.344 "nmcli con mod eth0 ipv4.addresses 192.168.0.33/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@192.168.0.341 "nmcli con mod eth0 ipv4.addresses 192.168.0.34/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@192.168.0.346 "nmcli con mod eth0 ipv4.addresses 192.168.0.35/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"# 没有IPv6抉择不配置即可ssh root@192.168.0.31 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::10; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@192.168.0.32 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::20; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@192.168.0.33 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::30; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@192.168.0.34 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::40; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@192.168.0.35 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::50; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"# 查看网卡配置[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=EthernetPROXY_METHOD=noneBROWSER_ONLY=noBOOTPROTO=noneDEFROUTE=yesIPV4_FAILURE_FATAL=noIPV6INIT=yesIPV6_AUTOCONF=noIPV6_DEFROUTE=yesIPV6_FAILURE_FATAL=noIPV6_ADDR_GEN_MODE=stable-privacyNAME=eth0UUID=424fd260-c480-4899-97e6-6fc9722031e8DEVICE=eth0ONBOOT=yesIPADDR=192.168.0.31PREFIX=24GATEWAY=192.168.8.1DNS1=8.8.8.8IPV6ADDR=fc00:43f4:1eea:1::10/128IPV6_DEFAULTGW=fc00:43f4:1eea:1::1DNS2=2400:3200::1[root@localhost ~]# 1.3.设置主机名hostnamectl set-hostname k8s-master01hostnamectl set-hostname k8s-master02hostnamectl set-hostname k8s-master03hostnamectl set-hostname k8s-node01hostnamectl set-hostname k8s-node021.4.配置yum源# 对于 Ubuntused -i 's/cn.archive.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list# 对于 CentOS 7sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.tuna.tsinghua.edu.cn|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于 CentOS 8sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org/$contentdir|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于公有仓库sed -e 's|^mirrorlist=|#mirrorlist=|g' -e 's|^#baseurl=http://mirror.centos.org/\$contentdir|baseurl=http://192.168.1.123/centos|g' -i.bak /etc/yum.repos.d/CentOS-*.repo1.5.装置一些必备工具# 对于 Ubuntuapt update && apt upgrade -y && apt install -y wget psmisc vim net-tools nfs-kernel-server telnet lvm2 git tar curl# 对于 CentOS 7yum update -y && yum -y install wget psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git tar curl# 对于 CentOS 8yum update -y && yum -y install wget psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git network-scripts tar curl1.5.1 下载离线所需文件(可选)在互联网服务器上安装一个截然不同的零碎进行下载所需包 ...

kubernetes delta_fifo源码解析1.介绍kubernetes delta_fifo是一个先入先出队列，相较于fifo，有两点不同： • 与key相关联的不间接是obj，而是Deltas，它是一个切片，Delta不仅蕴含了obj，还蕴含了DeltaType• 当Deltas最初一个元素Delta.DeltaType曾经是Deleted类型时，再增加一个Deleted类型的Delta，Deltas不再新增 delta_fifo的API与fifo类型，不再具体分析2.应用参考TestDeltaFIFO_ReplaceMakesDeletions[1] `go // 取testFifoObject中name作为key func testFifoObjectKeyFunc(obj interface{}) (string, error) { return obj.(testFifoObject).name, nil }type testFifoObject struct { name string val interface{} } func mkFifoObj(name string, val interface{}) testFifoObject { return testFifoObject{name: name, val: val} } // literalListerGetter实现了KeyListerGetter接口 type literalListerGetter func() []testFifoObject var _ KeyListerGetter = literalListerGetter(nil) func (kl literalListerGetter) ListKeys() []string { result := []string{} for _, fifoObj := range kl() { result = append(result, fifoObj.name) } return result } ...

PUT/Patch都能够对资源进行操作。 PUT对资源进行残缺内容的批改，Patch能够对资源进行局部批改。 1.Patch类型JSONPatchTypeMergePatchTypeStrategicMergePatch2.测试对象创立deploy，上面的Patch操作以此为例： apiVersion: apps/v1kind: Deploymentmetadata: name: demospec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx tolerations: - effect: NoSchedule key: abc value: xyzdeloy蕴含： 2个pod；每个pod含1个container:nginx；带1个toleration；# kubectl get deploy,podNAME READY UP-TO-DATE AVAILABLE AGEdeployment.apps/demo 2/2 2 2 11sNAME READY STATUS RESTARTS AGEpod/demo-7ff49f4cdb-d9jpc 1/1 Running 0 11spod/demo-7ff49f4cdb-t6lsl 1/1 Running 0 11s3.JSONPatch:通过client.Patch()进行JSONPatch，批改deploy的replicas=3： var replicaPatchData = `[{"op": "replace", "path": "/spec/replicas", "value": 3}]`ctx := context.Background()result, err := client.AppsV1().Deployments("default"). Patch(ctx, "demo", types.JSONPatchType, []byte(replicaPatchData), metav1.PatchOptions{})能够看到，JSONPatch的body中须要指明： ...

zyplayer-doc 是一款适宜企业和集体应用的WIKI知识库管理工具，提供在线化的知识库治理性能，专为私有化部署而设计，最大水平上保障企业或集体的数据安全，能够齐全以内网的形式来部署应用它。 当然也能够将其作为企业产品的阐明文档来应用，反对一键将整个空间的内容凋谢到互联网，并提供有不同格调的凋谢文档页款式可供选择，省去您为了产品的阐明文档而去定制开发一个零碎的老本。 本文将介绍通过 Rainbond 部署在线知识库零碎 zyplayer-doc 的两种形式，应用 Rainbond 开源利用商店一键部署和通过源代码部署。 部署 zyplayer-doc装置 RainbondRainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，反对治理多个Kubernetes集群，和治理企业应用全生命周期。次要性能包含利用开发环境、利用市场、微服务架构、利用交付、利用运维、利用级多云治理等。 可通过一条命令疾速装置 Rainbond。 curl -o install.sh https://get.rainbond.com && bash ./install.sh通过利用商店部署 zyplayer-doczyplayer-doc 曾经公布到 Rainbond 开源利用商店，用户可通过开源利用商店一键装置 zyplayer-doc。 在 Rainbond 的 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 zyplayer-doc 并装置。 部署实现后拓扑图如下。 可通过 Rainbond 默认提供的域名拜访 zyplayer-doc，拜访须要加后缀 /zyplayer-doc/，如：http://xxx.cn/zyplayer-doc/，默认用户明码 zyplayer/123456。 通过源码部署 zyplayer-doczyplayer-doc 是由 Java 编写的 SpringBoot 我的项目，Rainbond 对于 Java 我的项目能够通过辨认我的项目的 pom.xml 文件来进行模块的打包以及构建和部署，实现一键式体验。 部署 MySQLzyplayer-doc 须要应用 MySQL 服务，能够通过 Rainbond 开源利用商店疾速部署 MySQL。 ...

kubernetes fifo源码解析1.介绍kubernetes fifo是一个先入先出队列，实现了Add、Update、Delete、Get、Pop等根本API，以及Replace、HasSynced等API，具体如下： type FIFO struct { lock sync.RWMutexcond sync.Cond// key和obj的映射items map[string]interface{}// key的队列，去重queue []string// 当Delete/Add/Update被首先调用，或Replace()的items全副被pop时populated为truepopulated bool// Replace()首先被调用时的objs的数量initialPopulationCount int// keyFunc是用来将obj生成key的keyFunc KeyFunc// 队列是否敞开，用在Pop办法内的循环管制中closed bool}func NewFIFO(keyFunc KeyFunc) *FIFO 创立一个先入先出队列 func (f *FIFO) Add(obj interface{}) error 增加一个obj，当f.queue中已存在对应的key时，f.queue不再增加 func (f *FIFO) AddIfNotPresent(obj interface{}) error 当f.items不存在obj对应的key时才增加，这在繁多生产者/消费者有用，消费者能够平安的重试，防止与生产者竞争以及重入队已生产的item func (f *FIFO) Close() 敞开队列 func (f *FIFO) Delete(obj interface{}) error 删除不存在f.queue中的item，因为这个实现假如使用者只关怀对象，而不关怀创立/增加对象的程序 func (f *FIFO) Get(obj interface{}) (item interface{}, exists bool, err error) 返回申请的item，不存在时exists为false func (f *FIFO) GetByKey(key string) (item interface{}, exists bool, err error) ...

K8S后端存储：NFS 大家都晓得，NFS是一种基于网络的文件系统协定，容许在不同的机器之间共享文件系统资源。在K8S中，能够应用NFS作为后端存储，以提供长久化存储和共享存储卷。但是否适宜在生产环境应用NFS作为后端存储，这取决于具体的应用程序和应用场景。如果应用程序对性能和可靠性要求比拟高，可能须要抉择其余更适宜的存储计划，比方ceph。如果只是在测试或者开发环境中，我感觉应用NFS能够更不便地实现共享存储卷，进步测试或者开发的效率。 搭建NFS# step1 装置yum install nfs-utils -yyum install nfs-utils -y# step2 创立NFS共享目录mkdir /data/nfs_k8s_storage_share# step3 配置NFS共享，编辑/etc/exports文件，将要共享的目录增加到文件中/data/nfs_k8s_storage_share *(rw,sync,no_root_squash) # 这将容许任何客户端以读写模式访问共享目录。# step4 从新加载NFS配置exportfs -r# step5 启动NFS服务systemctl start nfs-serversystemctl enable nfs-server# step6 确认NFS服务正在运行systemctl status nfs-server# step7 留神防火墙，能够敞开或增加容许策略firewall-cmd --permanent --zone=public --add-service=nfsfirewall-cmd --reload# step8 验证是否共享胜利showmount -e 192.168.11.254k8s工作节点装置nfs-utils装置完即可，无需做任何配置 yum install nfs-utils -y“ 具体在哪个工作节点装置得看在上面的deployment.yaml中拉起的NFS客户端配置程序pod跑在哪个节点上，能够让该pod调度到指定的节点，那么该节点就要装置好nfs-utils。如果不干预调度行为，或者思考到后续要跑多个正本就能够将全副工作节点都装置好nfs-utils。 ” 在k8s master节点上装置nfs动静供应插件仓库： https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner 相干yaml下载链接： https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/deploy/rbac.yaml https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/deploy/deployment.yaml https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/deploy/class.yaml rbac.yaml：受权拜访ApiServerdeployment.yaml：部署插件，部署之前要批改外面的指向的nfs服务器地址和共享目录class.yaml：创立存储类开始部署插件部署rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: nfs-client-provisioner  # replace with namespace where provisioner is deployed  namespace: default---kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: nfs-client-provisioner-runnerrules:  - apiGroups: [""]    resources: ["nodes"]    verbs: ["get", "list", "watch"]  - apiGroups: [""]    resources: ["persistentvolumes"]    verbs: ["get", "list", "watch", "create", "delete"]  - apiGroups: [""]    resources: ["persistentvolumeclaims"]    verbs: ["get", "list", "watch", "update"]  - apiGroups: ["storage.k8s.io"]    resources: ["storageclasses"]    verbs: ["get", "list", "watch"]  - apiGroups: [""]    resources: ["events"]    verbs: ["create", "update", "patch"]---kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: run-nfs-client-provisionersubjects:  - kind: ServiceAccount    name: nfs-client-provisioner    # replace with namespace where provisioner is deployed    namespace: defaultroleRef:  kind: ClusterRole  name: nfs-client-provisioner-runner  apiGroup: rbac.authorization.k8s.io---kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata:  name: leader-locking-nfs-client-provisioner  # replace with namespace where provisioner is deployed  namespace: defaultrules:  - apiGroups: [""]    resources: ["endpoints"]    verbs: ["get", "list", "watch", "create", "update", "patch"]---kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:  name: leader-locking-nfs-client-provisioner  # replace with namespace where provisioner is deployed  namespace: defaultsubjects:  - kind: ServiceAccount    name: nfs-client-provisioner    # replace with namespace where provisioner is deployed    namespace: defaultroleRef:  kind: Role  name: leader-locking-nfs-client-provisioner  apiGroup: rbac.authorization.k8s.iokubectl create -f rbac.yaml部署deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: nfs-client-provisioner  labels:    app: nfs-client-provisioner  # replace with namespace where provisioner is deployed  namespace: defaultspec:  replicas: 1  strategy:    type: Recreate  selector:    matchLabels:      app: nfs-client-provisioner  template:    metadata:      labels:        app: nfs-client-provisioner    spec:      serviceAccountName: nfs-client-provisioner      containers:        - name: nfs-client-provisioner          image: tantianran/nfs-subdir-external-provisioner:v4.0.1 # 应用到镜像曾经转存到我的仓库          volumeMounts:            - name: nfs-client-root              mountPath: /persistentvolumes          env:            - name: PROVISIONER_NAME              value: k8s-sigs.io/nfs-subdir-external-provisioner            - name: NFS_SERVER              value: 192.168.11.254 #此处批改成nfs服务器的ip地址            - name: NFS_PATH              value: /data/nfs_k8s_storage_share # 此处批改成nfs的共享目录      volumes:        - name: nfs-client-root          nfs:            server: 192.168.11.254 #此处批改成nfs服务器的ip地址            path: /data/nfs_k8s_storage_share # 此处批改成nfs的共享目录kubectl create -f deployment.yaml创立存储类class.yamlapiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: nfs-clientprovisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'parameters:  archiveOnDelete: "false"kubectl create -f class.yaml查看# 查看受权kubectl get sa# 查看存储类kubectl get sc应用创立一个PVCapiVersion: v1kind: PersistentVolumeClaimmetadata:  name: my-pvcspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 5Gi  storageClassName: nfs-client在这里，PVC名称为my-pvc，申请5GB的存储空间，并将存储类设置为nfs-client 查看pvc# pvc已创立[root@k8s-a-master nfs-storage-yaml]# kubectl get pvcNAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGEmy-pvc   Bound    pvc-ce18ae0a-d4b4-4fa9-8241-b8b9551baa61   5Gi        RWO            nfs-client     2m6s# 对应的pv曾经主动创立[root@k8s-a-master nfs-storage-yaml]# kubectl get pvNAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGEpvc-ce18ae0a-d4b4-4fa9-8241-b8b9551baa61   5Gi        RWO            Delete           Bound    default/my-pvc   nfs-client              2m7s[root@k8s-a-master nfs-storage-yaml]# 创立一个利用podapiVersion: v1kind: Podmetadata:  name: test-nginx-podspec:  containers:  - name: test-nginx-container    image: nginx    volumeMounts:    - name: storage      mountPath: /data  volumes:  - name: storage    persistentVolumeClaim:      claimName: my-pvc查看pod是否挂载胜利[root@k8s-a-master nfs-storage-yaml]# kubectl exec -it test-nginx-pod -- df -h...                                                                                            3.9G     0  3.9G   0% /sys/fs/cgroup192.168.11.254:/data/nfs_k8s_storage_share/default-my-pvc-pvc-ce18ae0a-d4b4-4fa9-8241-b8b9551baa61  500G  1.8G  499G   1% /data...本文转载于WX公众号：不背锅运维（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/f8eCJNxztMFc3uQ_YJzwgg

 本文首发自「慕课网」，想理解更多IT干货内容，程序员圈内热闻，欢送关注"慕课网"！ 作者：一凡|慕课网讲师 集群内拜访 在k8s中创立的微服务，大部分都是在集群外部相互调用，这时候，应用DNS就能够很方面拜访。 比方：服务名是 my-service，端口号是8080，命名空间是yifan，那么就能够通过域名+端口 “my-service.yifan.svc.cluster.local:8080” 在集群内拜访。 当然，也能够间接用服务的ClusterIP+服务的端口号，只是这么应用的较少。 DNS解析到的IP也就是这个服务的ClusterIP，只是咱们不须要记住ClusterIP，记住服务名对应的域名更加容易。 编辑 如上图所示，就是k8s集群内的服务拜访流程。 客户端通过DNS服务的域名解析 my-service.yifan.svc.cluster.local 返回这个服务的ClusterIP。 而后创立TCP连贯到这个ClusterIP+端口号上。 网络申请通过Iptables/ipvs规定解决，通过负载平衡策略，把这个ClusterIP重定向到服务的后端实例，也就是这个服务的某一个Pod得PodIP。 这样TCP连贯胜利创立，客户端也就建设了与服务的后端实例的连贯，也就能够进行后续的申请了。 上面是Cluster类型的service的yaml文件示例： 这个YAML文件蕴含以下内容： apiVersion: 指定Kubernetes API的版本。kind: 指定要创立的对象类型，此处为Service。metadata.name: 指定Service的名称，此处为“my-service”。spec.type: 指定Service的类型，此处为“ClusterIP”。spec.selector: 指定要为Service抉择的Pod或正本集的标签选择器。在这个例子中，标签选择器是“app=my-app”。spec.ports: 指定要公开的端口及其配置信息。在这个例子中，将公开端口80，名称为“http”，将流量转发到Pod中的端口8080。要应用此YAML文件创建Service，请应用以下命令： 这是集群内拜访的流程，接下来，再来看看本文的核心内容，外网如何拜访。 集群外拜访 k8s集群的外网拜访形式有3种： Ingress, NodePort和LoadBanlancer。 其中Ingress是k8s的一个形象层，有很多的IngressController和服务能够来实现这个Ingress服务，而后由这个Ingress服务把外网的申请转发到集群内的服务。 NodePort和LoadBanlancer是k8s中service的类型。下面讲到的集群内拜访，ClusterIP也是service的一种类型。 而LoadBanlancer类型须要各个云厂商本人来实现的CloudControllerManager，所以，采纳不同的云厂商，它们的LoadBanlancer也就会有一些区别，它们的性能以及应用办法也就不一样了。 接下里，咱们就独自来看看这3种外网拜访形式吧。 Ingress转发外网申请 先来看下Ingress配置的yaml文件： apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: my-ingressspec: rules: - host: yifan-online.com http: paths: - path: /app1 pathType: Prefix backend: service: name: app1-service port: name: http - path: /app2 pathType: Prefix backend: service: name: app2-service port: name: http此文件指定了一个名为“my-ingress”的Ingress，将传入的申请路由到两个不同的服务，其中一个服务名称为“app1-service”，另一个服务名称为“app2-service”。 ...

Kubernetes 作为一项核心技术已成为古代应用程序架构的根底，越来越多的企业应用 Kubernetes 作为容器编排零碎。 上面的数据来自 2020 CNCF Survey 的原始数据，能够看到应用 Kubernete 的企业占比达到了 80%。 Kubernetes 的风行次要有以下几个起因： 自动化：Kubernetes 实现了容器的部署、扩大、负载平衡、故障复原、滚动更新等操作的自动化，极大地简化了应用程序的治理和保护工作。这种自动化也晋升了应用程序的弹性和可用性。可移植性：Kubernetes 基于容器的架构模型，使得利用无需从新编码或更新配置就能够在任何云平台、物理机或者虚拟机中运行。生态系统：Kubernetes 作为一个胜利地开源我的项目，领有弱小的社区反对和生态系统，使其能够取得更好的翻新、优化和安全性保障。从社区中，咱们能够找到各种插件和工具，为开发者提供了丰盛的抉择和扩展性。从单 Kubernetes 集群到多 Kubernetes 集群初露端倪企业中的应用程序通常比较复杂，须要不同的环境来进行开发、测试和生产部署。为了防止应用程序之间的烦扰和穿插，通常须要在不同的 Kubernetes 集群中别离部署和管理应用程序。 在同一个数据中心不同的环境部署独立的 Kubernetes 集群之后不同环境下的集群规模、治理形式、可靠性和安全性各有不同，从开发、测试到生产，老本的投入也逐渐地晋升，来保障更好的性能、更高的可靠性和安全性。 这也是多 Kubernetes 集群的一种模式（留神这里说的是 多 Kubernetes 集群）。 迅猛发展随着对云计算接受程度一直进步、企业规模的持续增长，越来越多的企业开始思考采纳或者曾经采纳多云和混合云的架构。多云和混合云的驱动因素很多，总结之后分成了两类：被动因素和被动因素。 被动因素防止厂商锁定：防止厂商锁定：企业通过采纳多云混合云策略，能够防止适度依赖繁多云服务提供商，从而加重由厂商锁定带来的危险。晋升性能、升高提早：企业依据业务需要，将服务部署在地理位置更靠近用户的数据中心。更大范畴的伸缩性：在不同的云服务提供商之间实现资源的弹性伸缩，从而提供更大范畴的伸缩性以满足业务需要。晋升可靠性：在不同的云服务提供商和公有数据中心之间进行利用部署之后，即便某个云服务提供商呈现故障，企业的利用仍可持续运行。老本因素：能够选择性地应用各个云服务提供商提供的服务，以便在老本和性能之间找到最佳均衡。被动因素数据中心能力限度：数据中心基础设施的规模、性能无奈满足需要。上云、下云的过渡期：在上云或下云的过程中，存在着私有云和公有云共存的景象，过渡期可能会被拉长。繁多云笼罩区域无限：只管云服务提供商一直扩大其寰球数据中心的覆盖范围，但依然可能存在繁多云服务提供商无奈满足企业在特定地区的部署需要的状况。业务隔离：在某些状况下，企业须要对不同业务进行隔离，以升高危险和进步安全性。将利用部署到不同的数据中心，来确保敏感数据和要害利用的平安。合规和数据隔离：不同国家和地区可能有不同的法规要求，这些要求可能会限度企业在特定云服务提供商上存储和解决数据。多云混合云策略的引入，相应地，Kubernetes 集群的数量也变得越来越多。尽管集群的数量在减少，然而实质与单集群无异：每个 Kubernetes 集群有本人的管制立体（api-server、控制器）和一组工作节点，能够独立进行应用程序的部署和治理（这就是为何后面称之为多 Kubernetes 集群）。在“多集群”环境下，每个集群是独立的，当须要治理的时候，采纳的是“一个一个治理”的形式。 挑战多多多 Kubernetes 集群能够在不同的云平台、不同的数据中心、不同的网络环境和不同的物理基础设施中部署，以满足不同的应用程序和业务需要。但随着集群数量的减少，也面临着诸多挑战： 集群治理复杂性减少：不同的 Kubernetes 集群部署在不同的云服务商平台上，领有不同的网络架构和安全策略。随着数量的减少，集群治理的复杂性也会相应减少。这包含资源分配、访问控制、网络管理、集群降级和保护等方面。利用治理成本增加：企业须要在多个 Kubernetes 集群上部署和管理应用程序。跨集群网络和服务通信：Kubernetes 人造的网络隔离个性，又因为部署在不同网络架构的云平台上，须要解决跨集群网络和服务通信的问题。这包含跨平台网络互联、跨集群服务发现和路由等问题。从多 Kubernetes 集群到 Kubernetes 多集群为了应答下面的种种挑战，呈现了另一个概念 Kubernetes 多集群。Kubernetes 多集群和多 Kubernetes 集群是两个不同的概念，为了便于辨别咱们也能够将其称为 Kubernetes 联邦。 Kubernetes 联邦是将多个 Kubernetes 集群连贯在一起，以便协同工作和实现跨集群资源和利用的对立治理、跨地区和跨云的故障切换、依据理论需要动态分配资源降低成本、晋升业务的灵活性和扩展性。 尽管对于如何连贯多个 Kubernetes 集群没有官网的解决方案，然而得益于弱小的社区和生态，已有不少开源和商业化的解决方案。 ...

kubernetes client-go提供了Informer，让客户端能够监听kubernetes资源对象的变更。 Informer中有一个Resync机制，依照Resync工夫定期的对资源进行同步。 一.Informer的ResyncInformer中的Reflector会List/Watch apiserver中的资源变动(event)，将其放入DeltaFIFO中，同时会更新Indexer本地缓存； func NewSharedInformerFactory(client kubernetes.Interface, defaultResync time.Duration) SharedInformerFactory { return NewSharedInformerFactoryWithOptions(client, defaultResync)}Resync是定期将Indexer缓存中的事件同步到DeltaFIFO中。 Informer的事件监听函数，在处理事件时，可能存在解决失败的状况，定期的Resync让这些事件有个从新OnUpdate解决的机会。 二.Resync的源码// k8s.io/client-go/tools/cache/delta_fifo.go// 从新同步一次 Indexer 缓存数据到 Delta FIFO 队列中func (f *DeltaFIFO) Resync() error { ... // 遍历 indexer 中的 key，传入 syncKeyLocked 中解决 keys := f.knownObjects.ListKeys() for _, k := range keys { if err := f.syncKeyLocked(k); err != nil { return err } } return nil}sync的过程： func (f *DeltaFIFO) syncKeyLocked(key string) error { obj, exists, err := f.knownObjects.GetByKey(key) ... id, err := f.KeyOf(obj) if err != nil { return KeyError{obj, err} } // 如果发现 FIFO 队列中曾经有雷同 key 的 event 进来了，阐明该资源对象有了新的 event， // 在 Indexer 中旧的缓存应该生效，因而不做 Resync 解决间接返回 nil if len(f.items[id]) > 0 { return nil } // 否则，从新放入 FIFO 队列中 if err := f.queueActionLocked(Sync, obj); err != nil { return fmt.Errorf("couldn't queue object: %v", err) } return nil}Informer对于sync事件的解决： ...

kubernetes通过GVK惟一标识一个API对象类型，比方HPA: G=autoscalingV=v1/v2beta1/v2beta2/v2...Kind=HorizontalPodAutoscaler随着kubernetes版本的迭代，产生了不同的Version，这就引发如下的问题： 当应用不同的Version创立的资源对象时，最终存储在etcd的是哪个Version?当应用不同的Version Get资源对象时，在apiserver中是如何转换的?一. APIVersion的流转APIVersion蕴含以下几种： External Version: apiserver对外裸露的version，比方v1/v2beta1等；Internal Version: 外部version，是所有version字段的超集，通常是latest external version；Storage Version: 保留到etcd的version，通常是external version中stable的vervsion，比方v1/v2等；ApiServer中各个version之间不能间接转换，通常应用Internal version进行直达，即： v1-->internal version-->v2beta1APIVersion的流转过程： 通过kubectl create创立资源对象时，client端应用External Version，即apiserver裸露的version和scheme；在apiserver中，对于External Version的对象： 首先，被转换为Interval version；而后，将Internal version转换为storage version；通过kubectl get查问资源对象时，依据client应用的Version： 首先，将Storage Version对象转换为Internal version；而后，将Internal version转换为External version，返回给client； 二. storageVersion1.抉择入口抉择etcd保留Version的入口代码： 通过storageVersioner抉择version；storageVersioner是storageProvider的对象内属性；// vendor/k8s.io/apiserver/pkg/endpoints/installer.gofunc (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage, ws *restful.WebService) (*metav1.APIResource, *storageversion.ResourceInfo, error) { ... storageVersionProvider, isStorageVersionProvider := storage.(rest.StorageVersionProvider) ... var apiResource metav1.APIResource if utilfeature.DefaultFeatureGate.Enabled(features.StorageVersionHash) && isStorageVersionProvider && storageVersionProvider.StorageVersion() != nil { versioner := storageVersionProvider.StorageVersion() // 通过storageVersioner抉择version gvk, err := getStorageVersionKind(versioner, storage, a.group.Typer) // 失去保留的GVK if err != nil { return nil, nil, err } apiResource.StorageVersionHash = discovery.StorageVersionHash(gvk.Group, gvk.Version, gvk.Kind) } ...}storageProvider即Store，storageVersioner是其中的一个属性，其属性的构建： ...

Block Devices（块存储） 在 Rook 中，块存储有两种存储类型：正本存储和纠删码存储。这两种存储类型都能够在 Kubernetes 集群中应用，能够通过在 CephBlockPool 中指定不同的存储类别来实现。 「正本存储：」 是一种基于正本的存储形式，其中数据被复制到多个节点上，以进步数据的可靠性和可用性。在正本存储中，数据被复制到指定数量的节点，当其中任何一个节点呈现故障时，零碎依然能够从其它节点读取数据，从而保障了数据的可靠性和可用性。「纠删码存储：」 是一种基于纠删码的存储形式，其中数据被编码为多个数据块，并在不同的节点上存储这些数据块的编码片段。在纠删码存储中，数据被编码为多个数据块，并依据指定的参数对这些数据块进行编码。编码后的数据块被扩散存储到不同的节点上，当某个节点呈现故障时，零碎能够应用存储在其它节点上的数据块编码片段来复原数据。纠删码存储在数据可靠性和存储效率方面具备劣势，但它通常须要更多的 CPU 和网络资源来执行编码和解码操作。如何抉择在生产环境中抉择 Rook 中的正本存储或纠删码存储须要思考多个因素，包含数据的重要性、可用性要求、存储老本和零碎性能等。 正本存储提供了简略、易于治理的数据冗余解决方案，通过复制多个数据正本到不同的节点上来进步数据的可靠性和可用性。在正本存储中，数据的每个正本都能够间接读取和写入，因而能够提供较低的读写提早和较高的吞吐量。纠删码存储通过对数据进行编码和分片，将数据的冗余信息散布到不同的节点上，以进步数据的可靠性和可用性。纠删码存储通常须要更少的存储空间和更低的存储老本，因为它只须要存储数据的冗余分片而不是残缺的正本。然而，在读取和写入数据时，须要对多个节点进行通信和协调，因而可能会带来更高的读写提早和较低的吞吐量，而且在产生节点故障时，复原数据的工夫也可能会更长在抉择 Rook 中的正本存储或纠删码存储时，须要思考数据的重要性和可用性要求，以及存储老本和零碎性能等因素。如果数据的重要性较高，可用性要求较高，并且存储老本较高，能够抉择正本存储；如果数据的可用性要求较高，存储老本较低，并且能够容忍较高的读写提早和较低的吞吐量，能够抉择纠删码存储。在抉择存储计划时，还须要思考硬件资源和网络带宽等因素，以确保所选计划能够满足零碎性能和可用性要求。实战创立CephBlockPool和StorageClass资源对象apiVersion: ceph.rook.io/v1kind: CephBlockPoolmetadata:  name: replicapoolspec:  failureDomain: host  replicated:    size: 3    requireSafeReplicaSize: true---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: rook-ceph-blockprovisioner: rook-ceph.rbd.csi.ceph.comparameters:  pool: replicapool  imageFormat: "2"  imageFeatures: layering  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node  csi.storage.k8s.io/fstype: ext4allowVolumeExpansion: truereclaimPolicy: Delete这是一个用于配置Rook与Ceph集群交互的 Kubernetes StorageClass 的 YAML 文件。 StorageClass 提供了一种形象形式，容许应用程序申请动静卷（PVC），而不须要当时理解存储资源的底层细节。 在这个 YAML 文件中，有两个 Kubernetes 对象：CephBlockPool 和 StorageClass。 CephBlockPool 是 Rook 中用于治理 Ceph 存储集群的块存储池的 Kubernetes 对象。这个特定的块存储池名为 replicapool，它应用主机故障域进行故障域拆散，应用正本存储策略，并将每个对象的正本数量设置为 3，要求所有正本都必须是平安的。每个 CephBlockPool 都对应一个特定的存储后端，用于提供块存储服务。通过创立不同的 CephBlockPool，能够为不同的应用程序提供不同的存储配置和性能要求。 StorageClass 对象指定了应用 Rook Ceph 提供的 CSI 驱动程序创立的存储卷的默认设置。其中 provisioner 指定应用的 CSI 驱动程序名称，pool 指定应用的 Ceph 块存储池名称，imageFormat 指定创立块设施时要应用的映像格局，imageFeatures 指定要启用的块设施个性，例如层次化，csi.storage.k8s.io/provisioner-secret-name，csi.storage.k8s.io/controller-expand-secret-name 和 csi.storage.k8s.io/node-stage-secret-name 别离指定用于身份验证和受权的 Kubernetes 密钥名称，而 allowVolumeExpansion 和 reclaimPolicy 别离定义了动静卷是否容许扩容以及何时删除。 ...

建木 是一个面向 DevOps 畛域的极易扩大的开源无代码(图形化)/低代码(GitOps)工具，能够帮忙用户轻松编排各种DevOps流程并散发到不同平台执行。 建木的图形化编排提供了多个节点，节点能够定义该步骤要执行的操作，用户可通过多个节点自由组合流水线。Rainbond 社区参加了建木节点的开发并奉献了 Rainbond组件创立与继续部署 节点。用户可应用该节点在 Rainbond 中主动创立组件和继续部署组件。 建木利用的部署则能够通过 Rainbond 开源利用商店一键装置，使建木利用的部署更简略，同时也能够作为利用插件扩大 Rainbond 构建体系。 下图是最终要实现的成果，也是建木的图形化流水线配置，本文将以下图的流程为例进行介绍： 克隆我的项目源代码应用 Maven 构建我的项目构建 Docker 镜像在 Rainbond 上主动创立组件并部署 部署 Rainbond 与建木Rainbond 部署Rainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，反对治理多个Kubernetes集群，和治理企业应用全生命周期。 可参阅 基于主机装置Rainbond 文档进行装置。 建木部署通过 Rainbond 开源利用商店一键装置建木利用，在 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 建木，进行装置。 装置实现后，建木利用拓扑图如下，可通过 Rainbond 默认提供的域名拜访建木 UI，默认用户明码 admin/123456 同时也能够在 平台治理 -> 扩大 -> 插件 中看到建木利用插件的定义。 建木应用将通过一个 Java SpringBoot Demo 我的项目进行演示，我的项目地址：https://gitee.com/zhangbigqi/java-maven-demo 配置图形化流水线拜访建木UI，进入图形我的项目。 1.增加 git clone 节点并配置 git 地址。 ...

在近程机器上启动集群，而后在本地机器上，通过IDE近程调试kubernetes的代码。 以apiserver为例。 一.环境筹备(近程机器)1. 环境OS: centos7.6kubernetes源码：v1.20golang: go1.17.12dlv: 1.9.12. 装置golang参考：https://docs.studygolang.com/doc/install 3. 装置dlv参考：https://github.com/go-delve/delve/tree/master/Documentation/installation # go install github.com/go-delve/delve/cmd/dlv@latest4. 下载kubernetes源码git clone -b release-1.20 git@github.com:kubernetes/kubernetes.git二.批改编译参数（近程机器）进入到kubernetes的源码，批改hack/lib/golang.sh文件，从而让编译器不去优化掉debug的信息，次要包含： 禁止-w -s，保留文件名、行号；加上-gcflags="all=-N -l"，禁止优化和内联；批改点： kube::golang::build_binaries() { # Create a sub-shell so that we don't pollute the outer environment ( # Check for `go` binary and set ${GOPATH}. kube::golang::setup_env V=2 kube::log::info "Go version: $(GOFLAGS='' go version)" local host_platform host_platform=$(kube::golang::host_platform) local goflags goldflags goasmflags gogcflags gotags # If GOLDFLAGS is unset, then set it to the a default of "-s -w". # Disable SC2153 for this, as it will throw a warning that the local # variable goldflags will exist, and it suggest changing it to this. # shellcheck disable=SC2153 # goldflags="${GOLDFLAGS=-s -w -buildid=} $(kube::version::ldflags)" goldflags="${GOLDFLAGS=-buildid=} $(kube::version::ldflags)" // 去掉-s -w goasmflags="-trimpath=${KUBE_ROOT}" gogcflags="${GOGCFLAGS:-} -trimpath=${KUBE_ROOT}" gogcflags="${gogcflags} -N -l" // 减少-N -l # extract tags if any specified in GOFLAGS # shellcheck disable=SC2001 gotags="selinux,notest,$(echo "${GOFLAGS:-}" | sed -e 's|.*-tags=\([^-]*\).*|\1|')" local -a targets=() local arg ...}三. 装置etcd（近程机器）进入kubernetes的源码，执行以下脚本，装置etcd: ...

1.长期存储的概念长期存储即宿主机节点的本地存储。 晚期版本的kubernetes提供了对container的CPU、内存的限度，并没有提供对container应用的本地存储的限度，这种状况下，可能存在某些container大量耗费宿主机的存储容量，导致宿主机没有足够的磁盘空间运行外围组件。 container应用的宿主机空间： 寄存log的目录：/var/lib/kubelet、/var/log/pods寄存rootfs的目录: /var/lib/dockerkubernetes在1.8版本引入了ephemeral storage资源，以治理本地长期存储的应用。 2.长期存储的配置Pod的container能够配置长期存储的requests和limits: * spec.containers[].resources.limits.ephemeral-storage* spec.containers[].resources.requests.ephemeral-storage创立一个deploy，ephemeral-storage申请300Mi，限度300Mi: apiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest imagePullPolicy: IfNotPresent command: - nginx - -g - "daemon off;" workingDir: /usr/share/nginx/html ports: - name: http containerPort: 80 protocol: TCP resources: limits: ephemeral-storage: 300Mi requests: ephemeral-storage: 300Mi创立进去2个pod: # kubectl get podNAME READY STATUS RESTARTS AGEnginx-774779ddfb-89f5m 1/1 Running 0 12snginx-774779ddfb-k8r2r 1/1 Running 0 12s在其中一个pod写入400Mi的文件： ...

download：Kubernetes零碎精讲 Go语言实战K8S集群可视化摘要次要介绍计算机网络传输一些基础的概念与原理学识，帮助更好的对java网络编程有一个明显的认知和学习。本博文将介绍一下有对于计算机网络相干学识和NIO相干学识。 NIO通信模型基础概念阻塞（Block）与非阻塞（Non-Block）阻塞和非阻塞是过程在拜访数据的时候，数据是否准备就绪的一种处理形式，当数据没有筹备的时候。 阻塞：经常需要等待缓冲区中的数据筹备好过后才处理其余的事件，否则一直等待在那里。 非阻塞:当咱们的过程拜访咱们的数据缓冲区的时候，如果数据没有筹备好则间接返回，不会等待。如果数据已经筹备好，也间接返回。 阻塞 IO ： 非阻塞 IO ： 同步（Synchronous）与异步（Asynchronous）同步和异步都是基于应用程序和操作系统处理 IO 事件所采纳的形式。比如 同步：是应用程序要直接参与 IO 读写的操作。 异步：所有的 IO 读写交给操作系统去处理，应用程序只需要等待告诉。 同步形式在处理 IO 事件的时候，必须阻塞在某个方法下面等待咱们的 IO 事件实现（阻塞 IO 事件或者通过轮询 IO事件的形式），对于异步来说，所有的 IO 读写都交给了操作系统。这个时候，咱们可能去做其余的事件，并不需要去实现真正的 IO 操作，当操作实现 IO 后，会给咱们的应用程序一个告诉。所以异步相比较于同步带来的间接好处就是在咱们处理IO数据的时候，异步的形式咱们可能把这部分等待所消耗的资源用于处理其余事务，晋升咱们服务自身的性能。 同步 IO ： 异步 IO ： BIO（传统IO）：BIO是一个同步并阻塞的IO模式，传统的 java.io 包，它基于流模型实现，提供了咱们最熟知的一些 IO 功能，比如File抽象、输入输出流等。交互方式是同步、阻塞的形式，也就是说，在读取输出流或者写入输入流时，在读、写动作实现之前，线程会一直阻塞在那里，它们之间的调用是可靠的线性次序。 NIO（Non-blocking/New I/O）NIO 是一种同步非阻塞的 I/O 模型，于 Java 1.4 中引入，对应 java.nio 包，提供了 Channel , Selector，Buffer 等抽象。NIO 中的 N 可能理解为 Non-blocking，不单纯是 New。它反对面向缓冲的，基于通道的 I/O 操作方法。 NIO 提供了与传统 BIO 模型中的 Socket 和 ServerSocket 绝对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都反对阻塞和非阻塞两种模式。对于高负载、高并发的（网络）利用，应使用 NIO 的非阻塞模式来开发 ...

写在开篇“ 上一次，我发了一篇：《实践篇：让咱们一起鲁克鲁克——rook（开源存储编排）》。这次，来一篇实战，应用rook在k8s上把ceph集群搞起来。后续，还会陆续分享如何对接k8s（作为k8s的后端存储）、以及分享一些在生产上的实践经验。 ” 环境规划主机名IP角色数据磁盘k8s-a-master192.168.11.10k8s master k8s-a-node01192.168.11.11k8s worker、ceph osd1个1TB硬盘k8s-a-node02192.168.11.12k8s worker、ceph osd1个1TB硬盘k8s-a-node03192.168.11.13k8s worker、ceph osd1个1TB硬盘k8s-a-node04192.168.11.14k8s worker、ceph osd1个1TB硬盘k8s-a-node05192.168.11.15k8s worker、ceph osd1个1TB硬盘k8s-a-node06192.168.11.16k8s worker、ceph osd1个1TB硬盘k8s-a-node07192.168.11.17k8s worker、ceph osd1个1TB硬盘k8s-a-node08192.168.11.18k8s worker、ceph osd1个1TB硬盘k8s-a-node09192.168.11.19k8s worker、ceph osd1个1TB硬盘k8s-a-node010192.168.11.20k8s worker、ceph osd1个1TB硬盘筹备工作“ 筹备工作在所有worker节点上做操作。 ” 数据盘筹备，除了sda是装了操作系统之外，sdb是用于osd盘的，不能被格式化文件系统[root@k8s-a-node01 ~]# lsblk sda               8:0    0  500G  0 disk ├─sda1            8:1    0    2G  0 part /boot└─sda2            8:2    0  498G  0 part   ├─centos-root 253:0    0  122G  0 lvm  /...sdb               8:16   0 1000G  0 disk  # 就是这块装置lvm2 如果在裸设施或未应用的分区上创立OSD，则Ceph OSD具备对LVM（逻辑卷治理）的依赖。yum install -y lvm2加载rbd模块 Ceph 须要应用带有 RBD 模块的 Linux 内核。许多 Linux 发行版都曾经蕴含了 RBD 模块，但不是所有的发行版都有，所以要确认。modprobe rbdlsmod | grep rbd“ Rook 的默认 RBD 配置仅指定了 layering 个性，以便与较旧的内核放弃兼容。如果您的 Kubernetes 节点运行的是 5.4 或更高版本的内核，您能够抉择启用其余个性标记。其中，fast-diff 和 object-map 个性尤其有用。 ” 降级内核（可选） 如果你将应用 Ceph 共享文件系统（CephFS）来创立卷（Volumes），则 rook 官网倡议应用至多 4.17 版本的 Linux 内核。如果你应用的内核版本低于 4.17，则申请的 Persistent Volume Claim（PVC）大小将不会被强制执行。存储配额（Storage quotas）只能在较新的内核上失去强制执行。在 Kubernetes 中，PVC 用于向存储系统申请指定大小的存储空间。如果申请的 PVC 大小无奈失去强制执行，则无奈保障所申请的存储空间大小。因为存储配额在较旧的内核上无奈失去强制执行，因而在应用 CephFS 创立卷时，如果应用较旧的内核版本，则可能无奈正确地治理和调配存储空间。因而，rook 官网倡议应用至多 4.17 版本的内核。 ...

引言最近买了台新电脑，之前的电脑下面k8s多集群拜访配置形式当初忘了过后是怎么配置了，于是本人再次摸索配置胜利，记录下来分享给大家。留神：自己电脑是Mac，接下来的操作默认是在Mac下面的zshell下面执行。 操作1、首页装置docker和kubectl docker装置点击这里，下载即可装置。 ➜ ~ docker -vDocker version 20.10.23, build 7155243kubectl装置点击这里 ➜ ~ kubectl versionWARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version.Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.2", GitCommit:"fc04e732bb3e7198d2fa44efa5457c7c6f8c0f5b", GitTreeState:"clean", BuildDate:"2023-02-22T13:32:21Z", GoVersion:"go1.20.1", Compiler:"gc", Platform:"darwin/arm64"}Kustomize Version: v4.5.7Server Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.6-aliyun.1", GitCommit:"e0e067a81f9fa91d46792937d79ec41ec79762eb", GitTreeState:"clean", BuildDate:"2023-02-28T12:15:08Z", GoVersion:"go1.18.6", Compiler:"gc", Platform:"linux/amd64"}WARNING: version difference between client (1.26) and server (1.24) exceeds the supported minor version skew of +/-12、启用k8s ...

写在开篇本文联合了官网文档对rook的知识点做了一个梳理，帮忙有须要的敌人疾速入门，本篇不讲实战操作，下篇再讲。官网文档：https://rook.io/docs/rook/v1.11/Getting-Started/intro/什么叫面向K8S的开源云原生存储面向Kubernetes的开源云原生存储通常是指反对Kubernetes本地对象存储API的存储解决方案，以满足容器化应用程序的存储需要。这些解决方案能够应用Kubernetes内置的存储资源对象，例如PV（Persistent Volume）和PVC（Persistent Volume Claim），这使得治理存储资源变得更加容易和标准化。 一些次要的面向Kubernetes的开源云原生存储解决方案包含： Rook：这是一个开源的存储编排零碎，它将Ceph、NFS、iSCSI等存储系统转化为Kubernetes上的资源，使得它们能够被动静治理和调度。OpenEBS：这是一个开源的块存储解决方案，它应用Kubernetes原生的API来提供弹性块存储。OpenEBS反对多种存储引擎，例如ZFS、Ceph等。Longhorn：这是一个开源的分布式块存储系统，它应用Kubernetes原生的API来提供高可用性、可扩展性和持久性的块存储。Longhorn应用Raft算法来提供高可用性，并应用快照和增量备份来提供持久性。Ceph：这是一个开源的分布式存储系统，它反对块存储、文件存储和对象存储，并能够与Kubernetes集成。Ceph反对多个存储协定，例如RADOS、RBD、CephFS等。这些解决方案都应用了开源技术，并在Kubernetes上提供牢靠的云原生存储。依据应用程序的需要，能够抉择适宜本人的存储解决方案。Rook是什么Rook 是一款开源的云原生存储编排器，能够帮忙在Kubernetes上部署和治理Ceph集群，使得Ceph更容易地与Kubernetes集成。简而言之，Rook是一种在Kubernetes上运行Ceph的工具。 当 Rook 部署在 Kubernetes 中时，它会主动部署一个 Ceph 集群。这个 Ceph 集群将会由若干个 Ceph Mon 节点和若干个 Ceph OSD 节点组成。Ceph Mon 节点次要负责元数据的治理和监控，Ceph OSD 节点次要负责数据存储和复原。 在 Kubernetes 中应用 Rook 治理存储时，咱们须要创立 Kubernetes 对象（例如 PVC 和 StorageClass），这些对象通过 Rook Operator 转换为 Ceph 对象（例如 RBD 和 CephFS），而后 Rook Operator 会主动将 Ceph 对象转换为 Ceph 集群的配置文件，最初将这些配置文件利用到 Ceph 集群中。 当咱们应用 Kubernetes 客户端来创立 PVC 时，Kubernetes 会调用 Rook 提供的 CSI 驱动程序来为 PVC 创立一个 RBD 卷。这个 RBD 卷实际上是由 Rook 创立的 Ceph RBD 卷，并被挂载到了指标 Pod 中。同时，Rook 还会主动将 Ceph RBD 卷的映射信息保留在 Kubernetes 的 PV 中，以便于后续的应用。 ...

Ingress的呈现Ingress是一种Kubernetes资源，用于将内部流量路由到Kubernetes集群内的服务。与NodePort相比，它提供了更高级别的路由性能和负载平衡，能够依据HTTP申请的门路、主机名、HTTP办法等来路由流量。 因而，能够说Ingress是为了补救NodePort在流量路由方面的有余而生的。应用NodePort，只能将流量路由到一个具体的Service，并且必须应用Service的端口号来拜访该服务。然而，应用Ingress，就能够应用自定义域名、门路和其余HTTP头来定义路由规定，以便将流量路由到不同的Service。 tantianran@test-b-k8s-master:~$ kubectl api-resources | grep ingressingressclasses                                 networking.k8s.io/v1                   false        IngressClassingresses                         ing          networking.k8s.io/v1                   true         Ingress此外，Ingress还能够与负载均衡器配合应用，以提供高可用性和程度扩大。这些性能使得Ingress比NodePort更适宜在生产环境中应用。Ingress和Ingress Controller 「Ingress」Ingress 是 Kubernetes 中的一个形象资源，它提供了一种定义利用裸露入口的办法，能够帮忙管理员在 Kubernetes 集群中治理多个服务的拜访入口，不便用户拜访。Ingress资源对象只是一个规范化的API对象，用于定义流量路由规定和 TLS 设置等信息。它自身不会间接解决或转发流量，而是须要配合一个 Ingress 控制器来实现。方才提到，Ingress 须要配合 Ingress Controller 应用，须要留神了，不同的 Ingress Controller 可能反对的性能和配置形式不同，须要依据理论状况进行抉择和配置。「Ingress Controller」Ingress 控制器是一个独立的组件，它会监听 Kubernetes API 中的 Ingress 资源变动，并依据定义的路由规定配置负载均衡器、反向代理或其余网络代理，从而实现内部流量的转发。因而，能够将 Ingress 控制器视为 Ingress 资源的理论执行者。总之，Kubernetes 的 Ingress 资源对象须要配合 Ingress 控制器能力实现内部流量的转发和路由。Ingress 控制器是 Ingress 资源的理论执行者，负责依据定义的路由规定配置网络代理。支流的Ingress Controller在 Kubernetes 中，有很多不同的 Ingress 控制器能够抉择，例如 Nginx、Traefik、HAProxy、Envoy 等等。不同的控制器可能会提供不同的性能、性能和可靠性，能够依据理论需要来抉择适合的控制器。Kubernetes生态系统中有许多不同的Ingress控制器可供选择，其中比拟支流的有： Nginx Ingress Controller：基于Nginx的Ingress控制器，提供了宽泛的性能和配置选项。Traefik Ingress Controller：Traefik是一个风行的反向代理和负载均衡器，Traefik Ingress Controller提供了灵便的配置选项和主动发现服务的性能。Istio Ingress Gateway：Istio是一种服务网格，它提供了基于Envoy代理的Ingress Gateway来治理入站和出站流量。Contour Ingress Controller：基于Envoy代理的Ingress控制器，具备高度可扩展性和灵便的路由规定。Kong Ingress Controller：Kong是一个API网关，提供了可扩大的路由和服务治理性能。Ambassador API Gateway：Ambassador是一个Kubernetes-native API Gateway，提供了自动化的服务发现和路由治理性能。能够依据理论须要抉择适当的Ingress控制器，并进行相应的配置和部署。控制器的部署计划Ingress控制器通常倡议部署在 Kubernetes 集群外部。这样能够确保 Ingress 控制器与 Kubernetes API Server 之间的网络提早较低，并且能够通过 Kubernetes Service 来治理 Ingress 控制器的负载平衡和高可用性。在 Kubernetes 集群外部部署 Ingress 控制器通常有两种形式： ...

Curve 是网易主导自研的现代化存储系统, 目前反对文件存储(CurveFS)和块存储(CurveBS)。 CurveBS 的外围利用场景次要包含： 虚拟机/容器的性能型、混合型、容量型云盘或长久化卷，以及物理机的近程存储盘高性能存算拆散架构：基于RDMA+SPDK的高性能低时延架构，撑持MySQL、kafka等各类数据库、中间件的存算拆散部署架构，晋升实例交付效率和资源利用率CurveFS 的外围利用场景次要包含： AI训练（含机器学习等）场景下的高性价比存储大数据场景下的冷热数据自动化分层存储私有云上高性价比的共享文件存储：可用于AI、大数据、文件共享等业务场景混合云存储：热数据存储在本地IDC，冷数据存储在私有云 应用 CurveAdm 部署 CurveFSCurveAdm 是 Curve 团队为进步零碎易用性而设计的工具，其次要用于疾速部署和运维 CurveBS/CurveFS 集群。次要个性： 疾速部署 CurveBS/CurveFS 集群容器化服务运维 CurveBS/CurveFS 集群同时治理多个集群一键降级谬误精确定位装置 CurveAdmbash -c "$(curl -fsSL https://curveadm.nos-eastchina1.126.net/script/install.sh)"主机列表主机模块用来对立治理用户主机，以缩小用户在各配置文件中反复填写主机 SSH 连贯相干配置。咱们需导入部署集群和客户端所需的机器列表，以便在之后的各类配置文件中填写部署服务的主机名。 这里采纳一台服务器，做单节点集群。 配置免密登陆生成密钥并配置服务器免密登陆 # 始终回车即可ssh-keygen# 应用 ssh-copy-id 配置ssh-copy-id root@172.31.98.243# 验证免密ssh root@172.31.98.243# 无需输出明码登陆胜利即可导入主机列表筹备主机列表文件 hosts.yaml $ vim hosts.yamlglobal: user: root # ssh 免密登陆用户名 ssh_port: 22 # ssh 端口 private_key_file: /root/.ssh/id_rsa # 密钥门路hosts: - host: curve hostname: 172.31.98.243导入主机列表 $ curveadm hosts commit hosts.yaml查看主机列表 $ curveadm hosts ls筹备集群拓扑文件CurveFS 反对单机部署和高可用部署，这里咱们采纳单机部署验证。 ...

原文作者：Owen Garrett of F5原文链接：在 Kubernetes 中部署利用交付服务（第 2 局部） - NGINX转载起源：NGINX 官方网站NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 本文是以下系列博文中的一篇： 在 Kubernetes 中部署利用交付服务（第 1 局部）解释了为什么因分治而重复使用的应用服务反而能够进步整体效率：因为 NetOps 和 DevOps 团队有不同的要求，所以他们会抉择最适宜他们特定需要的工具。在 Kubernetes 中部署利用交付服务（第 2 局部）（本文）以 WAF 为例，就利用交付服务在 Kubernetes 环境中的部署地位提供了领导。您能够依据本人的需要，以基于每个 Service 或基于每个 POD 的形式，将 WAF 部署在 Kubernetes 环境的“前门” 或 Ingress Controller上。在本系列博文的上一篇，咱们探讨了 DevOps 在管制利用部署、治理和交付形式方面日益增长的影响力。尽管这可能看似会引发与 NetOps 团队的抵触，但企业须要明确的是，每个团队都有不同的职责、指标和运维模式。要想实现专门化并进步运维效率，要害是要谨慎抉择负载平衡和 Web 利用防火墙 (WAF) 等利用交付服务的部署地位，在某些状况下还须要反复部署这些利用交付服务。 在本系列博文的上一篇，咱们探讨了 DevOps 在管制利用部署、治理和交付形式方面日益增长的影响力。尽管这可能看似会引发与 NetOps 团队的抵触，但企业须要明确的是，每个团队都有不同的职责、指标和运维模式。要想实现专门化并进步运维效率，要害是要谨慎抉择负载平衡和 Web 利用防火墙 (WAF) 等利用交付服务的部署地位，在某些状况下还须要反复部署这些利用交付服务。 在确定利用交付服务的部署地位时，需遵循两个次要规范： 您心愿部署的服务是 (a) 针对特定利用或业务，还是 (b) 通用于所有利用？服务配置是 (a) 属于 DevOps 或 DevSecOps 治理，还是 (b) 属于 NetOps 或 SecOps 治理？如果您偏向于 (a)，那么最好将服务部署到凑近须要它的利用左近，并将控制权交给负责这些利用运维的 DevOps 团队。 ...

概述只有是个公司，基本上都有邮箱和 AD(Active Directory). 在 AD 里，曾经有了： 用户 账号密码邮箱用户组 组织架构所以对于一些仅限于本公司肯定范畴内人员应用的治理或后盾或经营运维类零碎，其实是非常适合对接 AD 来进行认证、分组，以及依据分组来进行权限调配的。 对于 Rancher，假如使用者只会有这么几类： 管理员：运维部门我的项目管理员： 我的项目负责人使用者： 开发只读用户： 其余人员那么就能够间接对接 AD 来实现认证、登录、分组、受权。 ️Reference: 这使 Rancher 管理员能够对外部用户零碎中的用户和组进行集群和我的项目的访问控制，同时容许最终用户在登录 Rancher UI 时应用其 Active Directory 凭据进行身份验证。 AD 账号申请首先必须从邮箱管理员或 AD 管理员那申请一个新的 AD 用户，以用作 Rancher 的服务账户。此用户须要的权限是： 能够搜寻、读取（只读即可） AD 域下的用户和组，及其属性 （比方至多要有 运维部门/开发部门/我的项目部门相干 OU 下的权限）配置步骤具体的步骤间接查看这里：对接 Active Directory | Rancher 文档 这里联合集体的实际说一些实用技巧： AD 服务器参数服务帐户 (service account) 用户名：就是 AD 管理员提供给你的 CN, 这里可能会给到你这样的一个串：CN=RancherSA,OU=ApplicationAccount,DC=example,DC=com, 那么就只须要填写 RancherSA 就好了。用户搜寻库：如果 运维部门/开发部门/我的项目部门 都在 IT 部之下，IT 部的 OU 是：OU=ITDepartment,DC=example,DC=com, 那么就填写这个。用户组搜寻库：这里折腾了很久，你肯定要布局分明要依据什么维度来划分用户组，并且该用户组对应的 objectClass 是什么，而且该 objectClass 肯定要有 member 这样的属性和用户来关联。对于用户组的确认，我应用 JXplorer 来进行具体的剖析和查看，具体如下： ...

Gateway API 作为新一代的流量治理规范，对原有 Ingress 的扩大不标准、移植性差等问题做出了改良。从兼容K8s生态和优化网关体验登程，Rainbond 反对以插件的模式扩大平台网关能力，目前曾经有多家社区提供了 Gateway API 的实现，将其制作成平台插件后，一键部署后即可在平台中应用拓展网关能力。咱们能够制作不同的网关实现插件来应答不同的场景和需要，同时能够将本人制作的插件公布到利用商店供大家应用。 本篇文章将以 Envoy Gateway 为例具体介绍如何制作并公布你的 Kubernetes Gateway API 插件。最初公布到开源利用商店的 Gateway API 插件将能够被其余用户应用，同时积极参与奉献也有机会取得由咱们提供的小礼品。 前提条件Rainbond 版本大于 v5.13Rainbond 曾经对接过开源利用商店并领有推送权限Rainbond 与 Gateway API 集成机制在 Rainbond 中，之前仅反对内置网关，利用定义好路由规定后，内部流量即可间接拜访到对应利用。而 Gateway API 是以插件和能力扩大的模式与平台进行联合的。在平台中，只有装置了 Gateway API 自定义资源以及至多有一个网关实现后，才能够扩大平台网关能力。 如下图所示，如果 App 4、App 5等利用想要应用反对 Gateway API 的网关实现，那么首先须要定义 Gateway API 的相干资源，而这类资源是由 Gateway API 根底资源插件提供的，它次要蕴含了 Gateway API 资源类型的定义以及相干的 WebHook 资源。同时它在平台上裸露了 GatewayClass 和 Gateway 类型的资源，在平台能力扩大中能够看到。这样用户能够自定义网关行为和配置。 因而咱们只须要制作一个网关插件，即可读取 Gateway 类型的资源并生成对应的配置，向外提供网关能力。目前 Gateway API 已有多种实现，如 Envoy、Nginx、Istio 等。这里咱们抉择 Envoy 作为网关，这样内部流量进入 Envoy后，即可依据对应的路由策略达到 App 4 等利用上。 ...

概述书接上回：《Rancher 系列文章-Rancher 降级》, 咱们提到：将 Rancher 用 Helm 从 v2.6.3 降级到 v2.6.4). 接下来开始进行 K3S 集群的降级：将 K3S 集群从 v1.21.7+k3s1 降级到 v1.22.5+k3s2 相干信息本次降级的 K3S 集群的根本信息为： 天翼云上用 4 台机器装置的一个 1 master（及 etcd) 3 node 的 K3S 集群其实... 这个 K3S 集群应用 k3s-ansible 脚本批量装置的。..K3S v1.21.7+k3s1Rancher 刚降级到 v2.6.4, 验证没啥大问题K3S 集群有用到 Traefik 治理 IngressK3S 集群应用嵌入式 etcd 数据存储降级形式评估官网 提供了以下几种降级形式： 根底降级 应用装置脚本降级 K3s应用二进制文件手动降级 K3s主动降级 应用 Rancher 来降级 K3s 集群应用 system-upgrad-controller 来治理 K3s 集群降级我大略都过了一下，先说 Pass 的起因： 应用 Rancher 来降级 K3s 集群 - ♂️具体的文档在这里：降级 Kubernetes 版本 | Rancher | Rancher 文档 ...

概述书接上回：《Rancher 系列文章-K3S 集群降级》, 咱们提到：通过一键脚本降级 K3S 集群有报错。 接下来开始进行 Traefik 报错的剖析和修复, 问题是: 所有 Traefik 的 IngressRoute 拜访报错 404问题形容报错如下： time="2022-05-05T09:51:21Z" level=error msg="Failed to create middleware keys: middleware kube-system/hsts-header is not in the IngressRoute namespace cert-manager" namespace=cert-manager providerName=kubernetescrd ingress=grafana即无奈跨 NameSpace 调用 Traefik MiddleWare. 解决过程首先依据官网文档阐明：Kubernetes IngressRoute & Traefik CRD - Traefik 能够配置 allowCrossNamespace 参数，该参数默认为 false, 如果该参数设置为true, IngressRoutes 能够援用其余 NameSpace 中的资源。 基本上判定根因就是这个了。查看 K3s v1.22.5+k3s2 的 Traefik 配置，的确没有这个参数，如下： ...containers: - name: traefik image: rancher/mirrored-library-traefik:2.5.0 args: - '--entryPoints.metrics.address=:9100/tcp' - '--entryPoints.traefik.address=:9000/tcp' - '--entryPoints.web.address=:8000/tcp' - '--entryPoints.websecure.address=:8443/tcp' - '--api.dashboard=true' - '--ping=true' - '--metrics.prometheus=true' - '--metrics.prometheus.entrypoint=metrics' - '--providers.kubernetescrd' - '--providers.kubernetesingress' - >- --providers.kubernetesingress.ingressendpoint.publishedservice=kube-system/traefik - '--entrypoints.websecure.http.tls=true'... 所以，刚开始就打算通过编辑 Helm 的文件把这个参数加上。 ...

一.背景在kubernetes中，hpa（HorizontalPodAutoscaler）能够依据工作负载的指标（cpu/mem等），主动对其进行伸缩，即主动减少、缩小其pod数量。 cronhpa是一个定时扩缩容的组件，它反对依照Crontab表达式的策略，定时地对workload进行扩缩容，这里应用aliyun的kubernetes-cronhpa-controller。 cronhpa的例子如下： apiVersion: autoscaling.alibabacloud.com/v1beta1kind: CronHorizontalPodAutoscalermetadata: name: cronhpa-samplespec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx // 对deploy: nginx进行定时扩缩容； jobs: - name: "scale-down" // 在每分钟的30s，将deploy缩容到1个正本； schedule: "30 */1 * * * *" targetSize: 1 - name: "scale-up" // 在每分钟的0s，将deploy扩容到3个正本； schedule: "0 */1 * * * *" targetSize: 3问题如果CronHPA和HPA，同时操作一个scaleTargetRef，就会呈现replicas被CronHPA和HPA轮番批改的状况，比方: HPA依据指标，要将正本扩容为5个;CronHPA依据crontab规定，将正本扩容为3个;两个controller独立工作，两个扩容操作会互相笼罩；二.计划kubernetes-cronhpa-controller对该问题的计划： 将CronHPA的scaleTargetRef设置为HPA；再设置HPA的target为deployment，从而让CronHPA感知HPA的以后状态； 最终： CronHPA能够感知到HPA的minReplicas/maxReplicas/desiredReplicas；CronHPA能够通过HPA的target，晓得deploy的currentReplicas；CronHPA通过调整hpa.minReplicas/hpa.maxReplicas/deploy.replicas的形式，与HPA一起实现扩缩容操作。 策略调整在kubernetes-cronhpa-controller计划的根底上，能够依据本人的需要进行调整，比方： 规定cronhpa不批改hpa的参数；规定cronhpa在伸缩时，伸缩范畴为[hpa.minReplica, hpa.maxReplica]，不能超过范畴；三.源码看一下kubernetes-cronhpa-controller对cronhpa和hpa共存伸缩的源码。 1. 源码入口在执行定时工作的时候，对cronhpa.TargetRef.Kind="HPA"独自解决： // pkg/controller/cronjob.gofunc (ch *CronJobHPA) Run() (msg string, err error) { startTime := time.Now() times := 0 for { now := time.Now() ... // hpa compatible if ch.TargetRef.RefKind == "HorizontalPodAutoscaler" { // target=HPA msg, err = ch.ScaleHPA() if err == nil { break } } else { msg, err = ch.ScalePlainRef() // target=Deploy/Sts if err == nil { break } } ... } return msg, err}CronHPA对HPA伸缩时，进行两个操作： ...

k8s v1.18减少了hpa v2beta2的behavior字段，能够更精细化的管制伸缩的行为： 若不指定behavior字段，则按默认的behavior行为执行伸缩；若指定behavior字段，则按自定义的behavior行为执行伸缩；一. demo若behavior的策略(包含冷却工夫+伸缩策略)不满足需要，能够通过自定义behavior精细化管制伸缩的策略。 比方上面的behavior: apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata: name: sample-appspec: ... behavior: scaleUp: policies: - type: Percent value: 900 periodSeconds: 300 scaleDown: stabilizationWindowSeconds: 60 policies: - type: Pods value: 1 periodSeconds: 10扩容时： 立刻扩容；每次扩容最大(1+9)*currentReplicas，即10倍的replicas；1次扩容后，冷却300s后能力持续扩容；缩容时： 冷却60s才进行缩容，每次缩容1个正本；1次缩容后，冷却10s后能力持续缩容；以下面的Hpa v2beta2的定义为例，查看其扩缩容的过程: 扩容，将指标猛增(1-->13)： 首先，依照指标计算，应该将正本数从1扩容到13；但因为scaleUp.policies的限度，最多扩容10倍，即1-->10个正本；而后，依据指标计算，冷却300s后，最终将正本数扩容至13；# kubectl describe hpaName: sample-appNamespace: defaultLabels: <none>Annotations: <none>Reference: Deployment/sample-appMetrics: ( current / target ) "metric_hpa" on pods: 1 / 1Min replicas: 1Max replicas: 15Behavior: Scale Up: Stabilization Window: 0 seconds Select Policy: Max Policies: - Type: Percent Value: 900 Period: 300 seconds Scale Down: Stabilization Window: 60 seconds Select Policy: Max Policies: - Type: Pods Value: 1 Period: 10 secondsDeployment pods: 13 current / 13 desiredConditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric metric_hpa ScalingLimited False DesiredWithinRange the desired count is within the acceptable rangeEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 6m29s horizontal-pod-autoscaler New size: 10; reason: pods metric metric_hpa above target Normal SuccessfulRescale 79s horizontal-pod-autoscaler New size: 13; reason: pods metric metric_hpa above target缩容，将指标猛降(13-->1): ...

开篇 引言： 三人行必有我师焉常识共享，天下为公《K3s 系列文章》《Rancher 系列文章》计划在腾讯云的 K3S 上装置 Rancher 计划指标高可用 3 台 master 的 k3s 集群高可用模式的 rancher数据备份 rancher 数据备份到 腾讯云对象存储 cos平安加密 不能存在 http，全副是 https面向客户 公网可拜访；域名可拜访；正式证书尽量复用私有云的能力 Tencent Cloud Controller Manager (❌ 因为腾讯云曾经放弃保护相干源码，所以无奈复用）SVC LoadBalancer 调用 CLB (❌ 因为腾讯云曾经放弃保护相干源码，所以无奈复用）CLB - 应用 4 层 CLB备份 - 应用腾讯云 COS前提条件有腾讯云账户，账户至多领有如下权限：auto k3s 装置 - 设置 CAM 以及这些权限： QcloudTAGFullAccess该腾讯云账号有对应的 API 密钥，地址：拜访密钥 - 控制台 (tencent.com) ，或者领有相干权限：cam:QueryCollApiKey和 cam:CreateCollApiKey一个对象存储通 cos，用于备份Rancher 的域名Rancher 的域名对应的证书（如果没有，会尝试通过 cert-manager 和 let’s encrypt 主动生成收费的证书）注意事项Rancher 装置注意事项通过 Helm Chart 进行高可用装置装置前须要调整： ...

install minikube install helmbrew install kubernetes-helm# Kubernetes 集群上装置 Helm 服务器：helm inithelm install Prometheushelm repo add prometheus-community https://prometheus-community.github.io/helm-chartshelm repo updatehelm search repo prometheus# prometheushelm show values prometheus-community/prometheus > prometheus.yamlhelm install prometheus prometheus-community/prometheus -f prometheus.yaml# helm install prometheus prometheus-community/prometheus -f prometheus.yaml -n kube-server --create-namespace # helm upgrade --install prometheus prometheus-community/prometheus -f prometheus.yaml -n kube-server --create-namespace --version 15.8.0 --debug# helm -n kube-server uninstall prometheus helm install ingresshelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm pull ingress-nginx/ingress-nginx ...

创立用于测试的Deployment和ServiceapiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: test-goweb  name: test-gowebspec:  replicas: 6  selector:    matchLabels:      app: test-goweb  template:    metadata:      labels:        app: test-goweb    spec:      containers:      - image: 192.168.11.247/web-demo/goweb-demo:20221229v3        imagePullPolicy: IfNotPresent        name: goweb-demo        ports:        - containerPort: 8090          protocol: TCP---apiVersion: v1kind: Servicemetadata:  labels:    app: test-goweb  name: test-gowebspec:  ports:  - name: 80-8090    nodePort: 30010    port: 80    protocol: TCP    targetPort: 8090  selector:    app: test-goweb  type: NodePortService底层有哪些iptables链当在 Kubernetes 中创立 Service 时，将会创立以下几个 iptables 链。这些链都是用于实现 Service 的外围性能，上面列出所波及到的链： PREROUTING 链：此链是由 kube-proxy 组件创立的，用于将 Service IP 地址映射到对应的 Pod IP 地址上。当申请进入节点时，该链将被触发，它依据申请的 Service IP 地址来查找对应的 Pod IP 地址，并将申请转发到该 Pod。KUBE-SERVICES 链：此链蕴含了一系列规定，用于将 Service IP 地址映射到对应的 Pod IP 地址上。当申请进入节点时，该链将被触发，并依据申请的 Service IP 地址来查找对应的 Pod IP 地址。如果找到了对应的 Pod IP 地址，申请将被转发到该 Pod。KUBE-SVC-XXX 链：此链蕴含了一系列规定，其中 XXX 代表 Service 的名称。每个 Service 都有一个对应的 KUBE-SVC-XXX 链。当申请进入节点时，该链将被触发，并依据 Service IP 地址查找对应的 KUBE-SVC-XXX 链。该链中的规定将申请转发到对应的 Pod。KUBE-SEP-XXX 链：此链蕴含了一系列规定，其中 XXX 代表 Service 的名称。每个 Service 都有一个对应的 KUBE-SEP-XXX 链。当申请进入节点时，该链将被触发，并依据 Service IP 地址查找对应的 KUBE-SEP-XXX 链。该链中的规定将申请转发到对应的 Pod。KUBE-FIREWALL 链：此链用于解决来自 Kubernetes 的外部流量。该链蕴含了一些规定，用于管制拜访 Kubernetes 的 API、DNS 和其余一些服务。KUBE-NODEPORT 链：当 Service 类型为 NodePort 时，此链将被创立。该链蕴含了一些规定，用于将节点的端口映射到 Service 的端口上。KUBE-MARK-DROP 链：当申请被回绝时，会触发此链。该链蕴含了一些规定，用于标记被回绝的数据包。这些 iptables 链是 Kubernetes 中实现 Service 的要害组件。它们使得客户端能够应用 Service 名称来拜访运行在 Pod 中的应用程序，而不用理解其具体 IP 地址。查看和这个service无关的iptables规定 ...

kubernetes v1.18减少了HPA v2beta2的behavior字段，能够精细化的管制伸缩的行为。 若不指定behavior字段，则按默认的behavior行为执行伸缩。 一. 默认behavior默认的behavior: behavior: scaleDown: stabilizationWindowSeconds: 300 // 冷却工夫=5min policies: - type: Percent value: 100 periodSeconds: 15 scaleUp: stabilizationWindowSeconds: 0 // 没有冷却工夫 policies: - type: Percent value: 100 periodSeconds: 15 // replicas翻倍扩容 - type: Pods value: 4 periodSeconds: 15 // replicas扩容4个 selectPolicy: Max // 取最大的策略扩容时，疾速扩容： 不思考历史计算值(stabilizationWindowSeconds=0)，即reconcile()发现指标变动时，计算新replicas后，立刻执行伸缩；每15秒最多容许： 正本翻倍(减少currentReplicas*100%个正本) 或者 每15s新增4个正本，两者取max；即：max(2*currentReplicas, 4)缩容时，迟缓缩容： 缩容后的最终正本数不得<过来5min的历史最大值(stabilizationWindowSeconds=300)，即冷却工夫=300s；每15秒最多容许：正本缩小currentReplicas*100%个正本；二. demo扩容，将指标猛增(1-->13)： 首先，从1正本扩容到4正本；而后，从4正本扩容到8正本；最初，从8正本扩容至指标计算的13正本；# kubectl describe hpaName: sample-appNamespace: defaultLabels: <none>Annotations: <none>Reference: Deployment/sample-appMetrics: ( current / target ) "metric_hpa" on pods: 1 / 1Min replicas: 1Max replicas: 15Deployment pods: 13 current / 13 desiredConditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from pods metric metric_hpa ScalingLimited False DesiredWithinRange the desired count is within the acceptable rangeEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 2m14s horizontal-pod-autoscaler New size: 4; reason: pods metric metric_hpa above target Normal SuccessfulRescale 119s horizontal-pod-autoscaler New size: 8; reason: pods metric metric_hpa above target Normal SuccessfulRescale 103s horizontal-pod-autoscaler New size: 13; reason: pods metric metric_hpa above target缩容，将指标猛降(13-->1): ...

文本翻译自: https://itnext.io/working-with-the-kubernetes-api-587bc5941992 Kubernetes 公开了一个弱小的 API，可让您管制集群的各个方面。 大多数时候，它暗藏在 kubectl 前面，但没有人会阻止您间接应用它。 在本文中，您将学习如何应用 curl 或者您喜爱的编程语言向 Kubernetes API 发出请求。 但首先，让咱们回顾一下 Kubernetes API 的工作原理。 当您键入命令时，kubectl： 客户端校验申请。在文件上生成 YAML（例如kubectl run）。结构运行时对象。 此时，kubectl 还没有向集群收回任何申请。 下一步，它查问以后的 API 服务器并发现所有可用的 API 端点。 最初，kubectl 应用运行时对象和端点来协商正确的 API 调用。 如果您的资源是 Pod，kubectl 会读取 apiVersion 和 kind 字段并确保它们在集群中可用和受反对。 而后它发送申请。 了解在 Kubernetes 中 API 是分组的这很重要的。 为了进一步隔离多个版本，资源被版本化。 当初您曾经把握了基础知识，让咱们来看一个示例。 您能够应用 kubectl proxy 启动到 API 服务器的本地隧道。 然而如何检索所有 deployments 呢？ Deployments 属于 apps 组并且有一个 v1 版本。 您能够列出它们： ...

大家好，我是山西数智时代科技有限公司的赵佳鹏，咱们公司成立于2018年，专一于智慧游览、景区信息化建设。公司目前的次要产品有小悠出行管理系统、景区数字化运行管理系统、鼎云校园摆渡车经营管理系统、行车信息管理及流转零碎、觅四方商城零碎等，是集智慧游览布局、设计、建设、经营为一体的游览全产业链服务商。 智慧景区的整体架构 最早咱们的业务是单体服务，单体服务最大的问题就是业务无奈解耦，抗并发能力不高。业务降级为微服务架构之后解决了业务之间的解耦，晋升了业务的抗并发能力，降级微服务架构之后也减少了很多新性能，比方实时分账、套票的反对，多种渠道的购票交融，领取安全性、抢购、流动等都带来了肯定的复杂度，在检票的时候要保障多个渠道的库存、票状态要实时同步等对技术上有肯定的要求。 单体服务到微服务也是一次微小的挑战，服务器老本、人员老本、单体业务解耦、服务划分、运维等方面都存在很多问题。 存在的技术问题： 资源利用率，以前服务器都是每台上边部署几个我的项目，比方有台服务器 CPU、内存、磁盘等资源很多，但另一台服务器资源又很少，资源多的服务器没法齐全利用起来，资源少的服务器满了之后就没方法再部署业务，这会导致大量资源无奈无效的齐全利用。运维形式不对立，以前部署我的项目的时候多个项目组都是各自部署各自我的项目，各自部署形式不一样一会用主机形式，一会用镜像形式，每次须要找日志的时候都要查找半天，服务器上边的文件夹也是创立的乌七八糟的，没有对立的部署形式导致出问题后须要微小的老本。我的项目环境反复部署，之前服务器上会部署多个我的项目，每个我的项目环境都是各自我的项目组成员负责，导致环境不对立，有的中间件须要部署好几遍，Nginx 也是部署了很多不同的版本，节约了大量的工夫去做了雷同的事件，加大了运维老本。部署老本高，之前用 GitLab CI/CD 部署我的项目时须要写大量的 YAML 配置，同时还要解决 HTTP、HTTPS 拜访，证书每次都须要去手动生成，而后再拷贝到服务器上，呈现问题再一遍一遍的去改配置，YAML 语法也须要每个项目组的成员去学习，导致我的项目的老本进步。云原生平台选型采纳微服务架构之后，咱们决定全面转向容器化、云原生方向，所以咱们须要一个对开发者敌对、可视化部署、主动构建、易用的一个云原生 PaaS 平台。 在抉择 Rainbond 之前也应用过其余开源 PaaS 平台，因为公司没有业余的运维人员，在应用的时候发现对程序员都不是很敌对，还是脱离不了 YAML 的编写，学习老本太高，没有很好的扩大性能，起初理解到 Rainbond 后发现对程序员特地敌对，不须要写大量的 YAML 文件，通过界面化配置就能部署我的项目，而且官网文档很欠缺，部署例子也很多，操作简略，性能也能满足公司的需要。 应用 Rainbond 承载所有业务场景 在云原生架构之前，多台服务器的独自运维和部署复杂度高、资源利用率低、反复操作率高，对于线上我的项目的老本很大，线上服务出问题后无奈及时的判断问题出在哪个服务上，须要人工先找服务在哪台服务器，而后在通过一系列命令去查看等等。 在转向应用 Rainbond 云原生架构后，由 Rainbond 对立治理服务器、调度资源，而咱们只须要治理业务，升高了运维老本。以及相干运维操作都能够通过界面化实现，比方通过拓扑图就能够看到所有服务运行状况，哪个服务出现异常清晰明了，业务相干日志能够通过日志界面轻松查看，并且有历史日志保留等等。 整体上对于咱们来说升高了我的项目的老本，相应的为公司带来的利益就比之前多了很多。 应用 Rainbond 的最佳实际我的项目团队治理，公司不同我的项目会有不同的小组负责，这个性能就能够完满的解决这个问题，能够独自设置权限、集群资源。 代码仓库对接和疾速部署，公司用的华为云的代码仓库，在 Rainbond 上能够间接填仓库地址，而后通过源码间接构建部署，同时还反对 Maven多模块的批量构建，公司大部分我的项目都是多模块我的项目，用了这个性能之后比之前效率高了很多。测试环境一键复制到其余环境，Rainbond 能够将测试环境的利用疾速复制到其余环境中，省去了再次部署的问题，在之前不同环境都须要部署一次，用了这个性能后只须要部署一次，而后就能够疾速复制到不同环境中。可视化服务编排，我的项目部署胜利当前能够通过可视化的形式进行服务编排，这个性能是我在其余 PaaS 平台没有看到的，之前服务编排须要写大量的 YAML 文件，当初能够间接应用鼠标一拉一拽就能够实现，而且还是依据组件依赖状况按程序启动。 应用 Rainbond 总结从2022年8月份应用 Rainbond 到当初半年多的工夫里，显著感觉到在我的项目的开发效率上晋升了很多，之前每次反复的工作当初只须要干一次，运维上也不便了很多，间接界面化配置，比起之前写大量 YAML 文件省去了很多工夫老本，在运维上省去的工夫当初都用来开发我的项目，批改BUG了。 架构转变为云原生架构的这段时间里，发现了它的很多长处: 疾速迭代，在 Rainbond 上进行开发，使开发团队能够应用自动化能力和编排来疾速迭代，让开发人员有更多的精力聚焦于业务开发上。主动部署，云原生办法远优于传统的面向虚拟化的业务流程，传统办法须要投入大量的精力来构建开发环境，以及软件交付过程中的其余不同环境。而云原生架构具备自动化和组合性能，并且依赖于牢靠、通过验证和审核的已知良好流程的根底，交付非常麻利，而不再须要人工干预反复执行。独立高效，云原生带来了微服务化架构，一个微服务根本是一个能独立公布的应用服务，因而能够作为独立组件降级或复用等，对整个大利用的影响也较小，每个服务能够由专门的组织来独自实现，依赖方只有定好输出和输入口即可齐全开发、甚至整个团队的组织架构也会更精简，因而沟通成本低、效率高。屏蔽底层差别，Rainbond 尽管建设在 K8S 之上，但屏蔽了很多 K8S 的常识以及底层硬件的差异化，而咱们的开发人员就不须要思考利用对于底层硬件的差别，也不须要学习更多的容器常识，只须要专一于业务即可。同时对运维人员也十分敌对，不须要再为环境问题而苦恼。在将来我会更深刻的理解云原生和一直地尝试 Rainbond 带来的新性能。 ...

kubernetes引入HPA进行扩缩容，HPA能够依据指标(metrics)，主动对workload进行弹性的扩缩容。 HPA资源在autocaling这个group上面，HPA分为v1和v2版本： HPA v1仅反对基于CPU指标的伸缩；HPA v2beta1引入了基于Memory和自定义指标的伸缩；HPA v2beta2引入了自定义策略(behavior)的伸缩；HPA v2将v2beta2变成GA性能；# kubectl api-versions|grep autoautoscaling/v1autoscaling/v2beta1autoscaling/v2beta2autoscaling/v2一.HPA的指标类型Resouce: 提供Pod级别的CPU/Memory使用量； 通过metrics-server提供指标，调用metrics.k8s.io；ContainerResource: 提供Container级别的CPU/Memory使用量； 通过metrics-server提供指标，调用metrics.k8s.io；Object: 提供k8s集群内任意资源的相干指标； 通过prometheus-adapter提供指标，调用custom.metrics.k8s.io；Pods: 提供k8s集群内任意资源的相干指标； 通过prometheus-adapter提供指标，调用custom.metrics.k8s.io；External: 提供k8s集群外的指标数据； 二.HPA自定义指标的伸缩1. 部署prometheus-adapter自定义指标由prometheus-adapter查问prometheus失去，所以须要部署prometheus和prometheus-adatper组件。 这里应用helm chart的形式部署： prometheus: https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stackprometheus-adatper: https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-adapter部署实现当前： # kubectl get pod -n monitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 4d20hkube-state-metrics-796659d8b6-vr5w8 3/3 Running 0 4d20hnode-exporter-rn9nj 2/2 Running 0 4d20hprometheus-adapter-5f4df978c8-4fxjq 1/1 Running 0 46sprometheus-k8s-0 3/3 Running 1 4d20hprometheus-operator-7bc7bd7d7-jp754 2/2 Running 0 4d20h2. 创立deploy和servicedeploy: 初始为1个正本 apiVersion: apps/v1kind: Deploymentmetadata: name: sample-app labels: app: sample-appspec: replicas: 1 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - image: luxas/autoscale-demo:v0.1.2 name: metrics-provider ports: - name: http containerPort: 8080service: ...

Kubernetes 曾经成为了云原生时代基础设施的事实标准，越来越多的利用零碎在 Kubernetes 环境中运行。Kubernetes 曾经依附其弱小的自动化运维能力解决了业务零碎的大多数运行保护问题，然而还是要有一些情况是须要运维人员去手动解决的。那么和传统运维相比，面向 Kubernetes 解决业务运维问题是否有一些基本思路，是否能够借助其余工具简化排查流程，就是明天探讨的主题。 业务问题的领域首先有必要明确一点，什么样的问题算是 Kubernetes 畛域的业务零碎问题。Kubernetes 目前曾经是云原生时代各类 “上云” 业务零碎所处运行环境的事实标准。 咱们假设你曾经领有了一套强壮的 Kubernetes 环境，业务零碎的运行状态不会受到底层运行环境异常的影响，当业务零碎呈现问题时，Kubernetes 也能够正确的收集到业务零碎的运行状态信息。 有了这假设条件之后，咱们就能够将业务零碎问题束缚在业务从部署到失常运行起来这一时间区间内。所以本文探讨的业务零碎问题的领域包含： 业务零碎的规格定义问题业务零碎的调度问题业务零碎长期运行中的问题解决这类问题的意义解决这一类的问题的意义是不言而喻的，因为将业务零碎运行起来是一种最根底的需要。具备一套强壮的 Kubernetes 运行环境或者是编写了一套业务零碎代码都不会为咱们产生间接的价值。只有将业务零碎代码运行到一个稳固的环境中，面向最终用户提供服务时才会为咱们产生真正的价值。 值得庆幸的是，解决这类问题多半只须要咱们踩一次坑。对于大多数全新的业务零碎而言，部署到 Kubernetes 环境中去时，所可能遭逢的问题只须要被解决一次。一旦部署实现，业务零碎就能够专一于迭代性能，一直循环实现公布过程即可，顺利进入了一个周而复始的 CI/CD 流程之中。 除去根底需要这一不言而喻的意义，咱们也会探讨如何升高解决这类问题的难度，解决问题难度的升高自身也具备意义。云原生时代，咱们提倡每个开发人员都可能掌控本人的业务零碎，这种掌控也对开发人员提出了新的要求，即掌控 Kubernetes 的应用。这有点将运维层面的工作附加给开发人员的意思，理论推广过程并不顺利。为了便于开发人员应用 Kubernetes 来部署与调试本人开发的业务零碎，企业能够抉择云原生利用平台来升高开发人员应用 Kubernetes 的门槛，Rainbond 就是这样一款云原生利用治理平台，其易用性的特点升高了开发人员的学习门槛，同时可能为业务零碎赋能。 从一份yaml开始失常状况下，负责部署业务零碎的工作人员是通过申明式的配置文件来定义业务零碎的，其中的要害局部称之为规约(Spec)。这些规约字段通过格局严苛的 Yaml 类型配置文件来定义，正确填写其中的键与值须要庞杂的 Kubernetes 常识的保障。而把握配置文件的格局，以及配置中的内容，往往是开发人员学习原生 Kubernetes 的首个平缓门槛。 原生的应用形式中，kubectl 命令行工具会为这些配置文件提供严苛的校验机制，然而在校验无奈通过时，可能给出的提醒却并不是很敌对。 以一份非常简单的 Yaml 配置文件为例： apiVersion: apps/v1kind: Deploymentmetadata: labels: app: my-nginx name: my-nginx namespace: defaultspec: replicas: 1 selector: matchLabels: app: my-nginx template: metadata: labels: app: my-nginx spec: containers: - image: nginx name: nginx env: - name: DEMO_GREETING value: "true" # 此处必须用引号扩起来，因为这是个 string 类型 securityContext: privileged: true # 此处必须不能应用引号，因为这是个 bool 类型配置中有两个 true 值，然而其中一个必须应用引号，而另一个则不是，这对一些老手而言并不是很敌对。而加载这份配置文件的谬误版本时，零碎给出的报错尽管能够定位问题，然而交互体验更加不敌对。 ...

简介在上一篇文章中，咱们介绍了如何应用 KCL 编写并治理 Kubernetes 配置并将配置下发到集群，这一节咱们通过与其余 Kubernetes 配置管理工具的对比方 Helm 介绍 KCL 在 Kubernetes 配置管理场景更丰盛的内容。 Helm 是一个为 Kubernetes 对象生成可部署清单的工具，它承当了以两种不同模式生成最终清单的工作。Helm 是一个治理 Kubernetes 包（称为 charts）的必备模板工具。图表是 YAML 清单的模板化版本，其中混合了 Go template 的子集，它也是 Kubernetes 的包管理器，能够打包、配置和部署/利用 Helm 图表到 Kubernetes 集群。 在 KCL 中，用户能够应用更多的工具和 IDE 插件反对间接编写配置代码文件，而不是模板文件，这些工具和插件反对须要在相应地位的代码中进行批改，从而打消了读取 YAML 的老本。同时，用户能够通过代码重用配置片段，防止了YAML 配置的大量复制和粘贴。信息密度更高，更不容易出错。 上面以一个经典的 Helm Chart 配置管理的例子具体阐明 Kustomize 和 KCL 在 Kubernetes 资源配置管理上的区别。 HelmHelm 具备 values.yaml 和 template 的概念, 通常一个 Helm Chart 由一个蕴含 Chart.yaml 的门路组成。咱们能够执行如下命令取得一个典型的 Helm Chart 工程 创立 workload-helm 目录来保留 chart 工程# Create a directory to hold the chart projectmkdir workload-helm# Create a workload-helm/Chart.yamlcat <<EOF > workload-helm/Chart.yamlapiVersion: v2appVersion: 0.3.0description: A helm chart to provision standard workloads.name: workloadtype: applicationversion: 0.3.0EOF# Create a workload-helm/values.yamlcat <<EOF > workload-helm/values.yamlservice: type: ClusterIP ports: - name: www protocol: TCP port: 80 targetPort: 80containers: my-container: image: name: busybox:latest command: ["/bin/echo"] args: - "-c" - "Hello World!" resources: limits: cpu: 100m memory: 128Mi requests: cpu: 100m memory: 128MiEOF创立模版文件夹# Create a directory to hold templatesmkdir workload-helm/templates# Create a workload-helm/templates/helpers.tplcat <<EOF > workload-helm/templates/helpers.tpl{{/*Expand the name of the chart.*/}}{{- define "workload.name" -}}{{- default .Release.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}{{- end }}{{/*Create a default fully qualified app name.We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).If release name contains chart name it will be used as a full name.*/}}{{- define "workload.fullname" -}}{{- \$name := default .Chart.Name .Values.nameOverride }}{{- if contains \$name .Release.Name }}{{- .Release.Name | trunc 63 | trimSuffix "-" }}{{- else }}{{- printf "%s-%s" .Release.Name \$name | trunc 63 | trimSuffix "-" }}{{- end }}{{- end }}{{/*Create chart name and version as used by the chart label.*/}}{{- define "workload.chart" -}}{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" }}{{- end }}{{/*Common labels*/}}{{- define "workload.labels" -}}helm.sh/chart: {{ include "workload.chart" . }}{{ include "workload.selectorLabels" . }}{{- if .Chart.AppVersion }}app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}{{- end }}app.kubernetes.io/managed-by: {{ .Release.Service }}{{- end }}{{/*Selector labels*/}}{{- define "workload.selectorLabels" -}}app.kubernetes.io/name: {{ include "workload.name" . }}app.kubernetes.io/instance: {{ .Release.Name }}{{- end }}EOFcat <<EOF > workload-helm/templates/deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: {{ include "workload.name" . }} labels: {{- include "workload.labels" . | nindent 4 }}spec: selector: matchLabels: {{- include "workload.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "workload.selectorLabels" . | nindent 8 }} spec: containers: {{- range \$name, \$container := .Values.containers }} - name: {{ \$name }} image: "{{ $container.image.name }}" {{- with \$container.command }} command: {{- toYaml \$container.command | nindent 12 }} {{- end }} {{- with \$container.args }} args: {{- toYaml \$container.args | nindent 12 }} {{- end }} {{- with \$container.env }} env: {{- toYaml \$container.env | nindent 12 }} {{- end }} {{- with \$container.volumeMounts }} volumeMounts: {{- toYaml \$container.volumeMounts | nindent 12 }} {{- end }} {{- with \$container.livenessProbe }} livenessProbe: {{- toYaml \$container.livenessProbe | nindent 12 }} {{- end }} {{- with \$container.readinessProbe }} readinessProbe: {{- toYaml \$container.readinessProbe | nindent 12 }} {{- end }} {{- with \$container.resources }} resources: {{- toYaml \$container.resources | nindent 12 }} {{- end }} {{- end }}EOFcat <<EOF > workload-helm/templates/service.yaml{{ if .Values.service }}apiVersion: v1kind: Servicemetadata: name: {{ include "workload.name" . }} labels: {{- include "workload.labels" . | nindent 4 }}spec: type: {{ .Values.service.type }} selector: {{- include "workload.selectorLabels" . | nindent 4 }} {{- with .Values.service.ports }} ports: {{- toYaml . | nindent 4 }} {{- end }}{{- end }}EOF能够失去如下的 Helm chart 工程 ...

Service的底层Kubernetes Service的底层实现能够应用两种网络模式：iptables和ipvs。 在Kubernetes中，Service是一个形象的逻辑概念，用于公开应用程序的网络服务。它将一组Pod封装在一个虚构IP地址前面，能够通过该IP地址和相应的端口号拜访这些Pod。而底层实现Service的网络模式，能够通过kube-proxy来进行设置。 Kubernetes晚期版本中，kube-proxy默认应用iptables实现Service，即通过iptables规定来实现申请的转发和负载平衡。而在Kubernetes 1.11版本之后，新增了对IPVS的反对。IPVS是一种高性能的、基于内核的负载均衡器，能够提供更高的性能和更丰盛的负载平衡算法。 相比之下，iptables在规定较多时可能会影响性能，而IPVS的性能更高，且能够反对多种负载平衡算法，例如RR、LC、WRR等。因而，在高并发、高负载的场景下，应用IPVS作为Service的底层实现是更为适合的抉择。 优缺点Kubernetes Service 底层应用 iptables 和 ipvs 作为负载平衡的实现形式，其实两者都是各有优缺点的，上面好好聊聊： 应用 iptables 作为负载均衡器的长处如下： 简略易用：iptables 是 Linux 中默认的防火墙软件，应用宽泛，熟练掌握 iptables 的管理员能够很容易地配置 Service 的负载平衡。稳定性高：iptables 在 Linux 中曾经通过多年的应用和优化，稳定性失去了很好的保障，能够满足大部分场景下的负载平衡需要。配置灵便：iptables 提供了非常灵活的配置形式，能够依据不同的业务场景和需要进行定制化配置，能够轻松地实现多种转发策略。然而，应用 iptables 作为负载均衡器也存在一些毛病： 性能不够优良：iptables 的性能绝对较差，当集群规模增大时，会带来肯定的性能压力。负载平衡粒度较粗：iptables 的负载平衡粒度较粗，只能对 IP 地址进行负载平衡，无奈对申请的 Header 信息等进行辨认，对于某些须要更精密的负载平衡场景可能无奈满足需要。应用 ipvs 作为负载均衡器的长处如下： 性能优良：ipvs 的性能十分优良，能够反对高并发和大规模的负载平衡。负载平衡粒度细：ipvs 的负载平衡粒度比 iptables 更细，能够对申请的 Header 信息等进行辨认，能够满足更精密的负载平衡场景。然而，应用 ipvs 作为负载均衡器也存在一些毛病： 配置绝对简单：ipvs 的配置比 iptables 更加简单，须要较高的技术水平和教训。稳定性绝对较低：ipvs 的稳定性绝对较低，须要管理员常常进行监控和保护。应用 iptables 和 ipvs 作为 Kubernetes Service 的负载均衡器都有其长处和毛病，具体应用哪种形式须要依据理论场景和需要进行衡量。kube-proxykube-proxy 是一个网络代理，它监督 Kubernetes Service 的变动，而后自动更新本地的网络规定，以实现负载平衡和流量转发性能。 当 Kubernetes 中创立了一个 Service 对象时，kube-proxy 会依据 Service 的定义生成相应的虚构 IP 地址，并为该 IP 地址配置负载平衡规定，以将流量转发到后端 Pod 上。 ...

随着 Kubernetes 中快照控制器的引入，当初能够为反对此性能的 CSI 驱动程序和云提供商创立快照。 API 是通用的且独立于供应商，这对于 Kubernetes 来说是典型的，因而咱们能够摸索它而无需深刻理解特定实现的细节。让咱们认真看看快照，看看它们如何使 Kubernetes 用户受害。 介绍首先，让咱们廓清什么是快照。快照是文件系统在特定工夫点的状态。您能够保留它并在当前应用它来复原该特定状态。创立快照的过程简直是刹时的。创立快照后，对原始文件系统的所有更改都将写入不同的块。 因为快照数据与原始数据存储在同一地位，因而快照不能代替备份。同时，基于快照而不是实时数据的备份更加统一。这是因为在创立快照时保障所有数据都是最新的。 必须装置 snapshot-controller （所有 CSI driver 的通用组件），并且必须在 Kubernetes 集群中定义以下 CRD 能力应用快照性能： VolumeSnapshotClass – 相当于快照的 StorageClass；VolumeSnapshotContent – 相当于快照的 PV；VolumeSnapshot – 相当于快照的 PVC。最重要的是，CSI 驱动程序必须反对快照创立并具备相干的 csi-snapshotter controller。 快照在 Kubernetes 中是如何工作的？他们运作背地的逻辑很简略。有几个实体；VolumeSnapshotClass 形容快照创立的参数，例如 CSI driver。您还能够在那里指定其余设置，例如，快照是否应该是增量的以及它们应该存储在哪里。 创立 VolumeSnapshot 时，您必须指定将为其创立快照的 PersistentVolumeClaim。 拍摄快照时，CSI 驱动程序会在集群中创立一个 VolumeSnapshotContent 资源并设置其参数（通常是资源 ID）。 接下来，快照控制器绑定 VolumeSnapshot 到 VolumeSnapshotContent（就像 PV 和 PVC 一样）。 创立新的 PersistentVolume 时，您能够将先前创立的 VolumeSnapshot 设置为 dataSource 以应用其数据。 配置VolumeSnapshotClass 容许您指定各种 VolumeSnapshot 属性，例如 CSI 驱动程序名称和其余云提供商/数据存储相干参数。上面提供了几个 VolumeSnapshotClass 资源定义示例的链接 ： ...

流水线插件 是基于 Rainbond 插件体系 扩大实现，通过插件化的形式，能够实现对 Rainbond 构建体系的扩大。该插件由社区合作伙伴 拓维信息 参加开发并奉献，底层是基于 GitLab CI/CD 实现。 流水线构建与 Rainbond 源码构建的区别是： Rainbond 源码构建：应用简略，固定的构建模式，用户只需提供源代码，但不是很灵便。流水线构建：自定义构建步骤，应用更加灵便。本文将介绍应用流水线插件部署 RuoYi SpringBoot 我的项目，并实现提交代码后主动构建、主动部署。 装置 GitLab 和 Runner流水线插件是基于 GitLab 实现，所以须要依赖 GitLab 和 GitLab Runner，如果已有则可跳过此步。 通过 Rainbond 开源利用商店部署 GitLab 和 Runner，进入到 平台治理 -> 利用市场 -> 开源利用商店 中别离搜寻 GitLab 和 GitLab-runner，抉择版本进行装置，别离装置到同一个利用内。 部署实现后，拜访 GitLab 默认的域名进行用户注册。而后敞开 GitLab 默认的 AutoDevOps：Admin -> Settings -> CI/CD -> Continuous Integration and Deployment 勾销勾选 Default to Auto DevOps pipeline for all projects。 ...

简介KCL 团队很快乐地发表 KCL v0.4.6-alpha.1 版本当初曾经可用！ 您能够在 KCL v0.4.6-alpha.1 发布页面 或者 KCL 官方网站 取得 KCL 二进制下载链接和更多具体公布信息。 KCL 是一个开源的基于束缚的记录及函数语言，冀望通过成熟的编程语言技术和实际来改良对大量繁冗配置和策略的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简略的逻辑编写，以及更快的自动化集成和良好的生态延展性。 公布内容蕴含数字、字面值、括号等词法谬误复原KCL IDE 插件反对谬误和告警显示，跳转等能力局部编译器报错改善KCL Playground 反对代码分享能力Kubernetes KPT 工具集成方案设计Kubernetes Helm KCL 工具插件计划下一步打算KPM 包管理工具正式公布更多 KCL 编译器语法错误复原反对新版 IDE 插件公布，性能预计晋升 20 倍Helm，KPT 等 Kubernetes 工具 KCL 集成正式公布常见问题及解答详见 KCL 常见问题 其余资源感激所有 KCL 用户在此次版本更新过程中提出的贵重的反馈与倡议。更多其余资源请参考： KCL 网站Kusion 网站KCL Github 仓库Kusion Github 仓库Konfig Github 仓库欢送退出咱们的社区进行交换

前言故事的起因是敌人所在的部门最近基于auth2实现单点登录，他们在测试环境单点登录，运行得好好的，但他们把单点登录上到预公布环境，发现单点登录不好使了。他们有局部零碎是以受权码式接入，发现第一次登录拿到受权码进行换取token时，会提醒受权码生效。而他们测试环境和预公布环境的代码是一样的。 前面敌人和我聊天，我就问敌人两套环境有存在什么不一样的中央，敌人说测试环境是单POD部署，而预公布环境是多POD部署。最初我还从敌人的口中失去一个信息，他们auth2是基于国内开源的sa-token进行实现，刚好我也玩过这个玩意儿，这玩意儿的受权码是基于cookies进行放弃。我就跟敌人说可能是因为你部署了多个pod，pod的会话没放弃住。而后我就跟敌人提供以下计划 会话放弃计划计划一：通过service进行配置在service配置配置形如下内容 apiVersion: v1kind: Servicemetadata: namespace: uat name: uat-ssospec: selector: app: uat-sso ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30666 type: NodePort # 会话放弃3小时 sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800其中要害配置如下 sessionAffinity: ClientIPsessionAffinityConfig: clientIP: timeoutSeconds: 10800通过指定sessionAffinity: ClientIP开启了session放弃。当设置了session放弃之后，k8s会依据拜访的ip来把申请转发给他以前拜访过的pod，这样session就放弃住了。其中timeoutSeconds指的是session放弃的工夫，这个工夫默认是10800秒，也就是三个小时。 不过敌人说他配置了这个之后，貌似没产生作用，因为敌人他们单点登录是通过ingress进行转发，于是就有了第二种计划 计划二：通过ingress配置会话放弃配置形如下 apiVersion: networking.k8s.io/v1kind: Ingressmetadata: annotations: nginx.ingress.kubernetes.io/affinity: cookie nginx.ingress.kubernetes.io/affinity-mode: persistent nginx.ingress.kubernetes.io/session-cookie-name: route name: uat-sso-ingress namespace: uatspec: rules: - host: sso.com http: paths: - backend: service: name: uat-sso port: number: 80 path: / pathType: Prefix tls: - hosts: - sso.com secretName: tls.sso.com其中要害配置如下 ...

️URL: https://www.kubecost.com/ Description: Kubeccost 为应用 Kubernetes 的团队提供实时老本可视化和洞察，帮忙您继续升高云老本。 昨天浏览 Kubectl 插件的时候发现了 Kubecost，一看惊为天人啊，这个性能对于经营团队和 PM 团队领导来说太重要了。间接把监控数据换算成钱，而且明确通知你钱花在哪个 namespace、哪个利用、哪个标签、哪个 deployment下，明确通知你那些钱花得值、哪些钱节约了，有哪些方法能够缩小节约… 真的都是实打实的「降本」性能。 上面具体介绍一下。 亮点：监控和升高云老本Kubeccost 为应用 Kubernetes 的团队提供实时老本可视化和洞察，帮忙您继续升高云老本。 产品性能️ 老本摊派 按 Kubernetes 概念划分老本，包含部署（Deployment）、服务（Service）、命名空间（Namespace）、标签（Label）等等。开销视图能够逾越单个视图中的多个集群或通过单个 API 端点。 对立老本监控 将 Kubernetes 的老本与任何内部云服务或基础设施的收入联合起来，就能够取得一个残缺的图景。能够摊派内部老本，而后归因于任何Kubernetes 概念，以实现综合收入。 ⚖️ 老本优化计划在不就义绩效的前提下承受动静的倡议。优先思考要害基础设施或应用程序更改，以进步资源效率和可靠性。 开销警报和治理 alerts: # Kubecost 产生对于群集数据的警报 # 在命名空间 `kubecost` 的每日估算警报 - type: budget # 反对: 估算, recurringUpdate, 等. threshold: 50 # 估算警报所需 window: daily # 或 1d aggregation: namespace filter: kubecost在老本超支和基础设施中断危险成为实时告诉问题之前，迅速捕获它们。通过集成像 PagerDuty 和 Slack 这样的工具来保留工程工作流。 ...

一、阐明本文介绍基于 Kubernetes(k8s) 环境集成阿里云 公有镜像仓库 来部署一套 Dubbo + Nacos 的微服务零碎，并应用 Kubernetes DNS 以及 port-forward 的形式来买通网络拜访。 k8s环境搭建参考文章《基于minikube疾速搭建kubernetes单节点环境》 中在阿里云镜像仓库构建的镜像来进行部署。基于《基于jib-maven-plugin疾速构建微服务docker镜像》 中在阿里云镜像仓库构建的镜像来进行部署。  二、部署 MySQL创立配置文件 mysql-local.yaml 内容如下： apiVersion: v1kind: ReplicationControllermetadata: name: mysql labels: name: mysqlspec: replicas: 1 selector: name: mysql template: metadata: labels: name: mysql spec: containers: - name: mysql image: nacos/nacos-mysql:5.7 ports: - containerPort: 3306 volumeMounts: - name: mysql-data mountPath: /var/lib/mysql env: - name: MYSQL_ROOT_PASSWORD value: "root" - name: MYSQL_DATABASE value: "nacos_devtest" - name: MYSQL_USER value: "nacos" - name: MYSQL_PASSWORD value: "nacos" volumes: - name: mysql-data hostPath: path: /var/lib/mysql---apiVersion: v1kind: Servicemetadata: name: mysql labels: name: mysqlspec: ports: - port: 3306 targetPort: 3306 selector: name: mysqlReplicationController 简称 RC 能够保障在任意工夫运行 Pod 的正本数量，可能保障 Pod 总是可用的。执行以下命令，部署 MySQL 5.7： ...

前言K8S 性能优化系列文章，本文为第一篇：OS sysctl 性能优化参数最佳实际。 参数一览sysctl 调优参数一览 # Kubernetes Settingsvm.max_map_count = 262144kernel.softlockup_panic = 1kernel.softlockup_all_cpu_backtrace = 1net.ipv4.ip_local_reserved_ports = 30000-32767# Increase the number of connectionsnet.core.somaxconn = 32768# Maximum Socket Receive Buffernet.core.rmem_max = 16777216# Maximum Socket Send Buffernet.core.wmem_max = 16777216# Increase the maximum total buffer-space allocatablenet.ipv4.tcp_wmem = 4096 87380 16777216net.ipv4.tcp_rmem = 4096 87380 16777216# Increase the number of outstanding syn requests allowednet.ipv4.tcp_max_syn_backlog = 8096# For persistent HTTP connectionsnet.ipv4.tcp_slow_start_after_idle = 0# Allow to reuse TIME_WAIT sockets for new connections# when it is safe from protocol viewpointnet.ipv4.tcp_tw_reuse = 1# Max number of packets that can be queued on interface input# If kernel is receiving packets faster than can be processed# this queue increasesnet.core.netdev_max_backlog = 16384# Increase size of file handles and inode cachefs.file-max = 2097152# Max number of inotify instances and watches for a user# Since dockerd runs as a single user, the default instances value of 128 per user is too low# e.g. uses of inotify: nginx ingress controller, kubectl logs -ffs.inotify.max_user_instances = 8192fs.inotify.max_user_watches = 524288# Additional sysctl flags that kubelet expectsvm.overcommit_memory = 1kernel.panic = 10kernel.panic_on_oops = 1# Prevent docker from changing iptables: https://github.com/kubernetes/kubernetes/issues/40182net.ipv4.ip_forward=1如果是 AWS，额定减少如下： ...

前言K8S 性能优化系列文章，本文为第四篇：Kubernetes Node 性能优化参数最佳实际。 系列文章： 《K8S 性能优化 - OS sysctl 调优》《K8S 性能优化 - K8S APIServer 调优》《K8S 性能优化 - 大型集群 CIDR 配置》两个参数管制能够为 K8S Node 调度的最大 pod 数量的两个参数: podsPerCore 和 maxPods。 当两个参数都被设置时，其中较小的值限度了节点上的 pod 数量。超过这些值可导致： CPU 使用率减少。减慢 pod 调度的速度。依据节点中的内存数量，可能呈现内存耗尽的问题。耗尽 IP 地址池。资源适量应用，导致用户应用程序性能变差。⚠️ 重要 在 Kubernetes 中，蕴含单个容器的 pod 理论应用两个容器。第二个容器用来在理论容器启动前设置联网(pause)。因而，运行 10 个 pod 的零碎实际上会运行 20 个容器。 podsPerCore 依据节点中的处理器内核数来设置节点可运行的 pod 数量。例如：在一个有 4 个处理器内核的节点上将 podsPerCore 设为 10 ，则该节点上容许的最大 pod 数量为 40。 kubeletConfig: podsPerCore: 10将 podsPerCore 设置为 0 可禁用这个限度。默认为 0。podsPerCore 不能超过 maxPods。 ...

前言K8S 性能优化系列文章，本文为第二篇：Kubernetes API Server 性能优化参数最佳实际。 系列文章： 《K8S 性能优化 - OS sysctl 调优》参数一览kube-apiserver 举荐优化的参数如下： --default-watch-cache-size：默认值 100；用于 List-Watch 的缓存池；倡议 1000 或更多；--delete-collection-workers：默认值 1；用于晋升 namesapce 清理速度，有利于多租户场景；倡议 10；--event-ttl: 默认值 1h0m0s；用于管制保留 events 的时长；集群 events 较多时倡议 30m，以防止 etcd 增长过快；--max-mutating-requests-inflight: 默认值 200；用于 write 申请的拜访频率限度；倡议 800 或更高；--max-requests-inflight: 默认值 400；用于 read 申请的拜访频率限度；倡议 1600 或更高；--watch-cache-sizes: 零碎依据环境启发式的设定；用于 pods/nodes/endpoints 等外围资源，其余资源参考 default-watch-cache-size 的设定； K8s v1.19 开始，该参数为动静设定，倡议应用该版本。EOF

写在开篇几年前应用过terraform用于治理VMware和OpenStack，并做了一些自动化相干的事件。而到了明天是云原生的时代，最支流、最牛逼的开源容器编排平台莫过于K8S了。就在昨天，忽然又想起了terraform。时隔近3年多了，再次接触它的时候，它的变化很大，反对的provider更多、更强悍了。于是，打算再次对它下手，玩一玩它的Kubernetes provider，体验一下它的：轻松地定义、部署和治理 Kubernetes 上的基础架构和应用程序的快感。Terraform是什么鬼Terraform 是一个开源的基础设施即代码（Infrastructure as Code）工具，能够帮忙用户自动化创立、变更和治理基础架构资源。应用 Terraform，用户能够通过编写简略的申明式语言来形容他们须要的基础架构资源，而后 Terraform 会主动实现创立、更新和删除等操作，从而简化了基础架构治理的过程。 Terraform 反对多种基础架构提供商，例如 Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）、OpenStack、VMware 等，以及多种基础架构资源，例如虚拟机、网络、存储、负载平衡、数据库等。用户能够在一个 Terraform 配置文件中定义他们须要的资源，而后应用 Terraform 命令行工具来执行这些操作。 Terraform 的次要长处包含： 简化基础架构治理 - 应用 Terraform，用户能够通过编写简略的配置文件来治理基础架构资源，从而简化了基础架构治理的过程。自动化基础架构 - 应用 Terraform，用户能够自动化创立、更新和删除基础架构资源，从而进步了生产力和效率。可重复性 - 应用 Terraform，用户能够确保基础架构资源的配置是可反复的，从而缩小了谬误和不一致性。多云反对 - Terraform 反对多种基础架构提供商，从而让用户能够在不同的云环境中应用雷同的工具和流程来治理基础架构资源。记住，Terraform 是一个功能强大的基础设施即代码工具，能够帮忙你自动化创立、变更和治理基础架构资源，从而进步生产力和效率。 Terraform能够对Kubernetes做什么在 Kubernetes 上部署应用程序 - Terraform 能够应用 Kubernetes provider 来定义和治理 Kubernetes 资源，例如部署、服务和 Ingress 等，从而轻松在 Kubernetes 上部署应用程序。治理 Kubernetes 集群 - Terraform 能够应用 Kubernetes provider 治理 Kubernetes 集群中的节点、命名空间、角色和权限等资源，从而简化集群治理工作。在 Kubernetes 上治理长久化存储 - Terraform 能够应用 Kubernetes provider 治理 Kubernetes 中的存储类、卷和 PVC 等资源，从而简化在 Kubernetes 上治理长久化存储的工作。在 Kubernetes 上管理网络 - Terraform 能够应用 Kubernetes provider 治理 Kubernetes 中的网络策略、服务负载平衡和 Ingress 等资源，从而简化在 Kubernetes 上管理网络的工作。在 Kubernetes 上治理配置 - Terraform 能够应用 Kubernetes provider 治理 Kubernetes 中的 ConfigMap 和 Secret 等资源，从而简化在 Kubernetes 上治理配置的工作。综上所述，Terraform 和 Kubernetes 能够联合应用来简化在 Kubernetes 上管理应用程序和基础架构的工作，并进步生产力和效率。 ...

Service存在的意义Kubernetes中的Service是一种网络形象，用于将一组Pod裸露给其余组件，例如其余Pod或内部用户。Service能够作为一个负载均衡器，为一组Pod提供繁多的IP地址和DNS名称，并通过选择器来将流量路由到这些Pod。 Services的存在有以下几个意义： 通明的服务发现：  Kubernetes应用Service作为一种通明的服务发现机制。应用Service能够将Pod暗藏在前面，这样其余组件能够应用Service的DNS名称来拜访它们，而不须要晓得Pod的理论IP地址和端口号。负载平衡：  Service能够将流量路由到一组Pod上，并应用标签选择器将流量平均地调配给这些Pod。这使得能够轻松地进行程度扩大，以满足一直增长的负载。稳固的IP地址：  Kubernetes为每个Service调配一个稳固的IP地址，这个IP地址与Pod的生命周期无关。这意味着能够在Pod启动和进行时保持稳定的服务地址，并且无需手动更改任何配置。内部拜访：  通过将Service类型设置为NodePort或LoadBalancer，能够将Service裸露给内部用户或内部负载均衡器。这使得能够轻松地将Kubernetes集群与内部服务和用户集成。总之，Service是Kubernetes中十分重要的一部分，能够提供通明的服务发现、负载平衡、稳固的IP地址和内部拜访。在理论生产环境中，应用Service是构建牢靠和可扩大应用程序的要害。 Pod、Service、Label的关系在Kubernetes中，Pod是最小的可部署单元，它是由一个或多个容器组成的。Pod提供了一个运行环境，其中蕴含应用程序所需的资源，如存储、网络和命名空间。 Service是Kubernetes中的一种形象，用于定义一组Pod，这些Pod执行雷同的工作，并且能够通过Service的IP地址和端口号进行拜访。Service容许应用程序通过固定的IP和端口号进行拜访，而不用思考后端Pod的IP和端口号。 在Kubernetes中，Pod和Service之间有一种严密的关系。Service应用标签选择器来确定哪些Pod应该成为它的后端。一旦Service抉择了一组Pod，它将为这些Pod调配一个固定的IP和端口号，这些IP和端口号将用于拜访这些Pod。 当Pod被创立或删除时，Service会自动更新它的后端列表。这意味着当Pod被增加到Service的后端时，它们将主动成为Service的一部分，并且能够通过Service的IP和端口号进行拜访。同样地，当Pod被删除时，它们将主动从Service的后端列表中删除，这样拜访它们的申请就不会被发送到曾经不存在的Pod上。 因而，Pod和Service之间的关系是十分严密的，Service为一组Pod提供了一个稳固的网络地址，并且自动更新它的后端列表以确保拜访这些Pod时的高可用性和可靠性。 在Kubernetes中，Pod、Service和标签之间有着亲密的关系。标签（Label）是Kubernetes中的一种机制，它容许你为对象增加任意的元数据，例如版本、环境、用处等等。 Pod能够应用标签进行分类和分组，通过给Pod打上特定的标签，能够不便地对它们进行抉择和治理。同样地，Service也能够应用标签选择器来抉择具备特定标签的Pod作为后端。标签能够被利用于任何Kubernetes对象，包含Pod、Service、ReplicaSet等等。 当创立一个Service时，能够应用标签选择器来指定Service所选取的Pod的标签。例如，能够通过以下形式创立一个Service，它将抉择所有标有app=goweb-demo的Pod作为它的后端： goweb-demo-v1.yaml apiVersion: v1kind: Servicemetadata:  name: goweb-demospec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo在这个例子中，Service应用selector字段来抉择具备app=goweb-demo标签的Pod作为它的后端。这意味着只有那些标记为app=goweb-demo的Pod能力被Service拜访。 标签是Kubernetes中十分重要的一个概念，它使得对Pod和Service的抉择和治理变得更加灵便和高效。通过应用标签，能够轻松地对应用程序的不同版本、环境和用处进行分类和分组，并依据须要创立相应的Pod和Service来满足应用程序的需要。 Service的拜访类型Kubernetes中的Service对象能够指定不同的拜访类型，以便在集群内和集群外提供不同级别的拜访。 上面是Kubernetes中Service的三种拜访类型： ClusterIP：默认的拜访类型，将创立一个虚构IP地址，代表一组后端Pod。只能从集群外部拜访该Service，内部无法访问。NodePort：将在每个Node上公开一个端口，并将该端口重定向到Service。能够通过Node的IP地址和该端口拜访该Service。能够从集群内部拜访该Service，但须要在防火墙中关上该端口。LoadBalancer：将在内部创立一个负载均衡器，并将流量路由到Service。负载均衡器能够将流量路由到多个后端Pod，以进步可用性和性能。须要应用内部负载均衡器的云平台反对，例如AWS ELB或GCP GCLB。另外，还有一种名为ExternalName的拜访类型，能够将Service映射到集群内部的DNS名称，而不是集群外部的Pod。该拜访类型通常用于将Service映射到内部服务，例如数据库或API网关。 能够应用kubectl命令行或YAML文件来指定Service的拜访类型和其余配置。例如，在YAML文件中，能够将Service的类型指定为type: ClusterIP、type: NodePort或type: LoadBalancer，具体取决于须要提供的拜访级别。 实战开撸：案例1筹备Deployment yaml配置文件kubectl create deployment goweb-demo --image=192.168.11.247/web-demo/goweb-demo:20221229v3 --replicas=3 --dry-run=client -o yaml > my-deployment.yaml上述命令将应用名为“192.168.11.247/web-demo/goweb-demo:20221229v3”的镜像创立一个名为“goweb-demo”的Deployment，并设置3个正本。--dry-run=client选项使kubectl只查看配置文件的语法，而不会理论创立Deployment。-o yaml选项指定输入格局为YAML，并将其重定向到my-deployment.yaml文件中。上面是咱们失去的my-deployment.yaml： apiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    app: goweb-demo  name: goweb-demospec:  replicas: 3  selector:    matchLabels:      app: goweb-demo  strategy: {}  template:    metadata:      creationTimestamp: null      labels:        app: goweb-demo    spec:      containers:      - image: 192.168.11.247/web-demo/goweb-demo:20221229v3        name: goweb-demo        resources: {}status: {}编辑my-deployment.yaml文件以更改Deployment的任何其余配置选项。例如，您能够为Deployment指定标签，设置容器端口，配置健康检查等。上面是我调整后的my-deployment.yaml： apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demospec:  replicas: 3  selector:    matchLabels:      app: goweb  template:    metadata:      labels:        app: goweb    spec:      containers:      - name: goweb-container        image: 192.168.11.247/web-demo/goweb-demo:20221229v3创立Deploymenttantianran@test-b-k8s-master:~/goweb-demo$ kubectl apply -f my-deployment.yamldeployment.apps/goweb-demo createdtantianran@test-b-k8s-master:~/goweb-demo$ kubectl get deploymentsNAME         READY   UP-TO-DATE   AVAILABLE   AGEgoweb-demo   3/3     3            3           8m25stantianran@test-b-k8s-master:~/goweb-demo$ tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get podNAME                          READY   STATUS    RESTARTS   AGEgoweb-demo-654c45b968-9wcr8   1/1     Running   0          5sgoweb-demo-654c45b968-jsw8z   1/1     Running   0          5sgoweb-demo-654c45b968-mngq7   1/1     Running   0          5stantianran@test-b-k8s-master:~/goweb-demo$ 筹备Service yaml配置文件 当初应用go语言开发的web demo曾经跑起来了，而且跑了3个pod正本，接下来就要对外提供拜访，我的goweb demo利用对外提供拜访的端口是8090。在命令行下创立一个将容器端口8090映射到Node的端口30080上的Service对象，能够应用以下命令： kubectl create service nodeport goweb --tcp=80:8090 --node-port=30080其中，goweb是Service对象的名称，默认也是用此名称与deployment中定义的label "app: goweb" 保持一致，--tcp=80:8090示意将容器端口8090映射到Service的端口80上，--node-port=30080示意将Service的端口30080映射到Node的端口30080上。 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get svc -o wideNAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE   SELECTORgoweb        NodePort    10.111.227.27   <none>        80:30080/TCP   5s    app=gowebkubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        96d   <none>tantianran@test-b-k8s-master:~/goweb-demo$ 应用--dry-run=client -o yaml失去my-service.yaml 文件，而后应用kubectl apply命令将其利用到集群中 kubectl create service nodeport goweb --tcp=80:8090 --node-port=30080 --dry-run=client -o yaml > my-service.yaml my-service.yaml apiVersion: v1kind: Servicemetadata:  creationTimestamp: null  labels:    app: goweb  name: gowebspec:  ports:  - name: 80-8090    nodePort: 30080    port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb  type: NodePortstatus:  loadBalancer: {}在这个示例中，咱们创立了一个名为“goweb”的服务，它将流量路由到标签为“app=goweb”的Pod上。该服务类型被设置为NodePort，并指定了端口号为30080。服务监听80端口，将流量转发到Pod上的8090端口。 创立servicetantianran@test-b-k8s-master:~/goweb-demo$ kubectl apply -f my-service.yaml service/goweb createdtantianran@test-b-k8s-master:~/goweb-demo$ kubectl get svc -o wideNAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE   SELECTORgoweb        NodePort    10.104.241.81   <none>        80:30080/TCP   7s    app=gowebkubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        96d   <none>tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get epNAME         ENDPOINTS                                                  AGEgoweb        10.244.240.19:8090,10.244.240.38:8090,10.244.240.56:8090   16skubernetes   192.168.11.13:6443                                         96dtantianran@test-b-k8s-master:~/goweb-demo$ 要在集群外拜访该服务，能够应用任何节点的IP地址和NodePort端口号。例如，如果节点的IP地址为192.168.11.14，则能够应用http://192.168.1.14:30080拜访该服务。 实战开撸：案例2在案例1中，都是应用yaml进行创立，并且分享了如何疾速失去一个yaml。那么本案例2，全程在kubectl命令行下进行创立。创立deployment 要创立一个名为 nginx-deployment 的 Deployment 并应用最新版本的 nginx 镜像kubectl create deployment my-deployment001 --image=192.168.11.247/web-demo/goweb-demo:20221229v3 --replicas=3裸露 Deployment 的端口kubectl expose deployment my-deployment001 --port=80 --target-port=8090 --type=NodePort其中，my-deployment001 是你要裸露端口的 Deployment 的名称，80 是你要应用的 Service 的端口，8090 是你要将流量路由到的 Pod 的端口，--type 是 Service 的类型，通常是 ClusterIP、NodePort 或 LoadBalancer。下面的命令中，将创立一个类型为 NodePort 的 Service，并将其裸露在随机调配的端口上。 ...

背景Rainbond 自身具备基于源码构建组件的能力，能够将多种编程语言的代码编译成 Docker 镜像，然而在继续集成的过程中，往往会须要对提交的代码进行动态查看、构建打包以及单元测试。之前因为 Rainbond 并没有 Pipeline 这种可编排的机制，所以用户往往只能通过集成内部的 CI ，如 Jenkins、Gitlab CI 等。这给开发者的应用减少了门槛。 所以为了更无效的帮忙开发人员做代码测试，编译缓存，甚至代码品质剖析等，联合 Rainbond 的插件体系，拓维信息基于 GitLab CI 能力实现了更加灵便，更加多样化的源码构建的性能。 流水线插件性能基于 Rainbond 的插件体系，拓维信息奉献的流水线插件次要性能包含以下五局部： 流水线治理: 开发者应用流水线模块自定义应用服务所须要的流水线，以及流水线的各个阶段 应用服务: 应用服务就是 Gitlab 上某一个我的项目的代码仓库，利用于开发， 治理代码仓库。通常对应Rainbond 中的组件，如果一个仓库下蕴含多个微服务，则可能对应多个 Rainbond 组件 代码治理: 治理代码仓库中各分支与 CI 的继续集成流程，能够查看到对应代码仓库分支的最近提交和继续集成的历史信息。 镜像仓库: 继续集成生成的 image 制品和版本均会在此展现，能够在这里将生成的镜像手动部署到指定环境。 部署历史: 镜像仓库版本部署到 Rainbond 利用下的历史记录，能够从部署详情中跳转到对应组件进行治理。 装置流水线插件曾经公布到利用市场，可通过开源利用商店一键装置。目前该插件应用须要满足以下前提条件： Rainbond v5.12.0 版本有可用的 Gitlab 和 Gitlab RunnerGitlab 和 Gitlab runner 也可通过开源利用商店一键装置。装置流程如下： 在 平台治理-利用市场-开源利用商店 中搜寻 Gitlab 、Gitlab runner 一键装置并进行配置；在 平台治理-利用市场-开源利用商店 中搜寻 Pipeline 一键装置；具体配置和应用参考：Pipeline 应用文档 ...

https://github.com/kubernetes/ingress-nginxIngress 控制器 | Kubernetes 官网网址-->https://kubernetes.io/zh-cn/docs/concepts/services-networking... Nginx Ingress 控制器是官网举荐并保护的Ingress 控制器。 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。与作为 kube-controller-manager 可执行文件的一部分运行的其余类型的控制器不同， Ingress 控制器不是随集群主动启动的。 基于此页面，你可抉择最适宜你的集群的 ingress 控制器实现。Kubernetes 作为一个我的项目，目前反对和保护 AWS、 GCE 和 Nginx Ingress 控制器。Helm 装置官网举荐应用 helm 装置，匹配关系 Helm装置官网文档：https://helm.sh/docs/intro/install/装置 helm v3 版本，间接从 github 下载源码包： 下载[root@master01 ~]# wget https://get.helm.sh/helm-v3.11.1-linux-amd64.tar.gz# 解压[root@master01 ~]# tar -zxvf helm-v3.11.1-linux-amd64.tar.gz# cp到环境变量目录外面即可[root@master01 ~]# cp linux-amd64/helm /usr/local/bin/helm Chart官网给出的办法： helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm repo updatehelm install [RELEASE_NAME] ingress-nginx/ingress-nginx国内应用 gcr 的 image 有问题，提前准备到 aliyun的 registry： registry.cn-hangzhou.aliyuncs.com/tanzu/controller:v1.6.4registry.cn-hangzhou.aliyuncs.com/tanzu/kube-webhook-certgen:v20220916-gd32f8c343registry.cn-hangzhou.aliyuncs.com/tanzu/defaultbackend-amd64:1.5在官网下载Chart 包：ingress-nginx-4.5.2.tgz tar -zxvf ingress-nginx-4.5.2.tgz cd ingress-nginxkubectl create ns ingress-nginxkubectl label node master01 ingress=true #对应上面的nodeSelctor批改value.yaml，须要批改的地位 ...

最近一段时间始终在跟客户探讨Kubernetes和对应的AWS托管服务EKS. 很多时候都被问到EKS这个黑盒子外面到底是怎么做的。本人其实也挺好奇这个问题的，在官网文档上这块的形容的并不是太多，于是翻来翻去找到了这个re:Invent 2019的一个演讲： 听了一下这个演讲小哥的介绍，是EKS团队的Principle Engineer，从EKS这个服务一开始就在了。照例先到Linkedin上八卦一下： 翻了一下工作的经验，始终做研发，来AWS之前是在 Samsung SDS 做k8s的开发。个别能在re:Invent上讲 XXX under the hood 的应该都是比拟有料的，先厚着脸皮申请加个好友先 :) EKS 的介绍从一个非常简单的架构图开始： EKS是一个区域服务（两头那个黄色的图标），客户通过 EKS Endpoint 来与 EKS 服务进行交互。 EKS 会帮客户创立 K8s 集群，这个k8s是与上流社区 100% 代码兼容的，客户能够在这个 K8s 集群上运行本人的利用，这个K8s集群也能够与AWS的其余服务无缝地集成，比如说身份认证，负载平衡等 接着再开展一下： K8s集群相干的有几个使用者，第一是集群的管理员，或是Infra团队，会通过方才提到的 EKS Endpoint 来进行 K8s集群的治理（局部的操作也会通过k8s的 API Server Endpoint来进行）；第二是开发团队，或是CICD的自动化工具，会通过 K8s 的 API Server Endpoint 来进行利用的部署；最初一个是利用的最终使用者，间接通过k8s对外裸露的服务接口来拜访利用（他们也不须要晓得利用是不是部署在K8s下面） 持续开展： 在这里能够看到 EKS Control Plane，也就是 k8s 的 Master ，是托管在EKS治理的VPC外面的。留神到这里写 Single Tenant，也就是单租户，即每个集群有本人的独立的资源，而不与其余的集群共享。这个 Control Plane 是部署在三个可用区的，确保跨可用区的高可用。在上面是 Data Plane，也就是 k8s 的 Node . 这块是部署在客户本人的VPC外面，能够抉择EC2，也能够抉择 Fargate。 ...

写在开篇❝ 本篇分享k8s的污点、污点容忍，感激继续关注我的盆友们。如有考k8s认证需要的盆友，可和我取得联系，理解K8S认证请猛戳：《K8s CKA+CKS认证实战班》2023版 ❞ K8s CKA+CKS认证实战班》2023版：https://mp.weixin.qq.com/s/h1bjcIwy2enVD203o-ntlA 污点和污点容忍什么是污点？ ❝ 节点亲和性是Pod的一种属性，它使 Pod 被吸引到一类特定的节点 （这可能出于一种偏好，也可能是硬性要求）。 污点（Taint） 则相同——它使节点可能排挤一类特定的Pod。也就是说防止pod调度到特定node上，通知默认的pod，我回绝你的调配，是一种被动回绝的行为。 ❞ 什么是污点容忍？ ❝ 是利用于 Pod 上的。容忍度容许调度器调度带有对应污点的 Pod。 容忍度容许调度但并不保障调度。也就是说，容许pod调度到持有Taint的node上，心愿pod可能调配到带污点的节点，减少了污点容忍，那么就会认可这个污点，就「有可能」调配到带污点的节点（如果心愿pod能够被调配到带有污点的节点上，要在pod配置中增加污点容忍字段）。 ❞ 污点和容忍（Toleration）相互配合，能够用来防止Pod被调配到不适合的节点上，每个节点上都能够利用一个或多个污点，这示意对于那些不能容忍这些污点的Pod， 是不会被该节点承受的。 再用大白话了解一下，也就是说，基于节点标签的调配，是站在Pod的角度上，它是通过在pod上增加属性来确定pod是否要调度到指定的node上的。其实，也还能够站在Node的角度上，通过在node上增加污点属性，来防止pod被调配到不适合的节点上。 语法格局节点增加污点的语法格局 kubectl taint node xxxx key=value:[effect]effect（成果）： NoSchedule：不能被调度PreferNoSchedule：尽量不要调度NoExecute：岂但不会调度，还会驱赶Node上已有的pod删除污点的语法格局 kubectl taint node xxxx key=value:[effect]-实战给test-b-k8s-node02节点打上污点，不干涉调度到哪台节点，让k8s按本人的算法进行调度，看看这10个pod会不会调配到带有污点的节点上# 打污点kubectl taint node test-b-k8s-node02 disktype=sas:NoSchedule# 查看node详情的Taints字段tantianran@test-b-k8s-master:~$ kubectl describe node test-b-k8s-node02 | grep TaintTaints:             disktype=sas:NoSchedulegoweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePorttantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-a -o wideNAME                         READY   STATUS    RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATESgoweb-demo-b98869456-84p4b   1/1     Running   0          18s   10.244.240.50   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-cjjj8   1/1     Running   0          18s   10.244.240.13   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-fxgjf   1/1     Running   0          18s   10.244.240.12   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-jfdvl   1/1     Running   0          18s   10.244.240.43   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-k6krp   1/1     Running   0          18s   10.244.240.41   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-kcpsz   1/1     Running   0          18s   10.244.240.6    test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-lrkzc   1/1     Running   0          18s   10.244.240.49   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-nqr2j   1/1     Running   0          18s   10.244.240.33   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-pt5zk   1/1     Running   0          18s   10.244.240.28   test-b-k8s-node01   <none>           <none>goweb-demo-b98869456-s9rt5   1/1     Running   0          18s   10.244.240.42   test-b-k8s-node01   <none>           <none>tantianran@test-b-k8s-master:~/goweb-demo$ ❝ 发现全副都在test-b-k8s-node01节点，test-b-k8s-node01节点有污点，因而回绝承载pod。 ❞ test-b-k8s-node01节点曾经有污点了，再通过nodeSelector强行指派到该节点，看看会不会调配到带有污点的节点上goweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      nodeSelector:        disktype: sas      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort查看pod的创立状况 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-aNAME                          READY   STATUS    RESTARTS   AGEgoweb-demo-54bc765fff-2gb98   0/1     Pending   0          20sgoweb-demo-54bc765fff-67c56   0/1     Pending   0          20sgoweb-demo-54bc765fff-6fdvx   0/1     Pending   0          20sgoweb-demo-54bc765fff-c2bgd   0/1     Pending   0          20sgoweb-demo-54bc765fff-d55mw   0/1     Pending   0          20sgoweb-demo-54bc765fff-dl4x4   0/1     Pending   0          20sgoweb-demo-54bc765fff-g4vb2   0/1     Pending   0          20sgoweb-demo-54bc765fff-htjkp   0/1     Pending   0          20sgoweb-demo-54bc765fff-s76rh   0/1     Pending   0          20sgoweb-demo-54bc765fff-vg6dn   0/1     Pending   0          20stantianran@test-b-k8s-master:~/goweb-demo$ ❝ 难堪的场面很显然了，该节点明明存在污点，又非得往上面指派，因而让所有Pod处于在了Pending的状态，也就是待调配的状态，那如果非要往带有污点的Node上指派pod，怎么办？看上面的例子 ❞ 非要往带有污点的Node上指派pod，保留nodeSelector，间接减少污点容忍，pod是不是必定会调配到带有污点的节点上？测试下便知 goweb-demo.yamlapiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      nodeSelector:        disktype: sas      tolerations:      - key: "disktype"        operator: "Equal"        value: "sas"        effect: "NoSchedule"      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort查看Pod创立状态 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-aNAME                          READY   STATUS    RESTARTS   AGEgoweb-demo-68cf558b74-6qddp   0/1     Pending   0          109sgoweb-demo-68cf558b74-7g6cm   0/1     Pending   0          109sgoweb-demo-68cf558b74-f7g6t   0/1     Pending   0          109sgoweb-demo-68cf558b74-kcs9j   0/1     Pending   0          109sgoweb-demo-68cf558b74-kxssv   0/1     Pending   0          109sgoweb-demo-68cf558b74-pgrvb   0/1     Pending   0          109sgoweb-demo-68cf558b74-ps5dn   0/1     Pending   0          109sgoweb-demo-68cf558b74-rb2w5   0/1     Pending   0          109sgoweb-demo-68cf558b74-tcnj4   0/1     Pending   0          109sgoweb-demo-68cf558b74-txqfs   0/1     Pending   0          109s❝ 在下面的yaml中，tolerations字段为污点容忍，通过测试就能够答复方才的问题：保留nodeSelector，间接减少污点容忍，pod是不是必定会调配到带有污点的节点上？通过测试后，给出的答案是：不是。 ❞ 那怎么办呢？持续测试，当初把nodeSelector去掉，只留下污点容忍，看看pod会不会有可能调配到打了污点的节点上？ goweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      tolerations:      - key: "disktype"        operator: "Equal"        value: "sas"        effect: "NoSchedule"      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort查看pod创立状况 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-a -o wideNAME                          READY   STATUS    RESTARTS   AGE    IP              NODE                NOMINATED NODE   READINESS GATESgoweb-demo-55ff5cd68c-287vw   1/1     Running   0          110s   10.244.222.57   test-b-k8s-node02   <none>           <none>goweb-demo-55ff5cd68c-7s7zb   1/1     Running   0          110s   10.244.222.24   test-b-k8s-node02   <none>           <none>goweb-demo-55ff5cd68c-84jww   1/1     Running   0          110s   10.244.240.24   test-b-k8s-node01   <none>           <none>goweb-demo-55ff5cd68c-b5l9m   1/1     Running   0          110s   10.244.240.15   test-b-k8s-node01   <none>           <none>goweb-demo-55ff5cd68c-c2gfp   1/1     Running   0          110s   10.244.222.3    test-b-k8s-node02   <none>           <none>goweb-demo-55ff5cd68c-hpjn4   1/1     Running   0          110s   10.244.240.62   test-b-k8s-node01   <none>           <none>goweb-demo-55ff5cd68c-j5bvc   1/1     Running   0          110s   10.244.222.43   test-b-k8s-node02   <none>           <none>goweb-demo-55ff5cd68c-r95f6   1/1     Running   0          110s   10.244.240.16   test-b-k8s-node01   <none>           <none>goweb-demo-55ff5cd68c-rhvmw   1/1     Running   0          110s   10.244.240.60   test-b-k8s-node01   <none>           <none>goweb-demo-55ff5cd68c-rl8nh   1/1     Running   0          110s   10.244.222.8    test-b-k8s-node02   <none>           <none>❝ 从下面的调配后果能够看出，有些Pod调配到了打了污点容忍的test-b-k8s-node02节点上。 ❞ 再玩个小例子，让它容忍任何带污点的节点，master默认也是有污点的（二进制搭建的除外），那pod会不会有可能跑master去哦？测试一下便知先看看master的污点状况 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl describe node test-b-k8s-master | grep TaintTaints:             node-role.kubernetes.io/control-plane:NoSchedulegoweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      tolerations:        - effect: "NoSchedule"          operator: "Exists"      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort查看pod创立状况 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-a -o wideNAME                          READY   STATUS             RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATESgoweb-demo-65bbd7b49c-5qb5m   0/1     ImagePullBackOff   0          20s   10.244.82.55    test-b-k8s-master   <none>           <none>goweb-demo-65bbd7b49c-7qqw8   1/1     Running            0          20s   10.244.222.13   test-b-k8s-node02   <none>           <none>goweb-demo-65bbd7b49c-9tflk   1/1     Running            0          20s   10.244.240.27   test-b-k8s-node01   <none>           <none>goweb-demo-65bbd7b49c-dgxhx   1/1     Running            0          20s   10.244.222.44   test-b-k8s-node02   <none>           <none>goweb-demo-65bbd7b49c-fbmn5   1/1     Running            0          20s   10.244.240.1    test-b-k8s-node01   <none>           <none>goweb-demo-65bbd7b49c-h2nnz   1/1     Running            0          20s   10.244.240.39   test-b-k8s-node01   <none>           <none>goweb-demo-65bbd7b49c-kczsp   1/1     Running            0          20s   10.244.240.40   test-b-k8s-node01   <none>           <none>goweb-demo-65bbd7b49c-ms768   1/1     Running            0          20s   10.244.222.45   test-b-k8s-node02   <none>           <none>goweb-demo-65bbd7b49c-pbwht   0/1     ErrImagePull       0          20s   10.244.82.56    test-b-k8s-master   <none>           <none>goweb-demo-65bbd7b49c-zqxlt   1/1     Running            0          20s   10.244.222.18   test-b-k8s-node02   <none>           <none>竟然还真的有2个Pod跑master节点去了（test-b-k8s-master），master节点本地没有对应的image，且harbor服务器也没开机，所以拉取image失败了。这个不是关怀的问题。关怀的问题是，竟然有pod跑master节点去了，是因为k8s的这个机制：如果一个容忍度的key为空且operator为Exists，示意这个容忍度与任意的key、value和effect都匹配，即这个容忍度能容忍任何污点。理解了这个Exists的机制后，就晓得为啥会跑master去了吧？ ❝ 正告：要留神了，master之所以默认会打上污点，是因为master是治理节点、思考到平安的问题，所以master节点是不倡议跑惯例的pod（或者说是不倡议跑业务pod）。 ❞ 打了污点的节点，到底有没有方法能够强行调配到该节点上？咱们试试节点test-b-k8s-node02是打了污点的 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl describe node test-b-k8s-node02 | grep TaintTaints:             disktype=sas:NoSchedulegoweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      nodeName: test-b-k8s-node02      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort❝ 在下面的配置中，留神nodeName字段，nodeName指定节点名称，用于将Pod调度到指定的Node上，它的机制是「不通过调度器」 ❞ 查看pod创立状况 tantianran@test-b-k8s-master:~/goweb-demo$ kubectl get pod -n test-a -o wideNAME                         READY   STATUS    RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATESgoweb-demo-dd446d4b9-2zdnx   1/1     Running   0          13s   10.244.222.39   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-4qbg9   1/1     Running   0          13s   10.244.222.6    test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-67cpl   1/1     Running   0          13s   10.244.222.63   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-fhsgf   1/1     Running   0          13s   10.244.222.53   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-gp9gj   1/1     Running   0          13s   10.244.222.49   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-hzvs2   1/1     Running   0          13s   10.244.222.9    test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-px598   1/1     Running   0          13s   10.244.222.22   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-rkbm4   1/1     Running   0          13s   10.244.222.40   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-vr9mq   1/1     Running   0          13s   10.244.222.17   test-b-k8s-node02   <none>           <none>goweb-demo-dd446d4b9-wnfqc   1/1     Running   0          13s   10.244.222.16   test-b-k8s-node02   <none>           <none>❝ 会发现，所有Pod都调配到了test-b-k8s-node02节点，怎么不会分一些到test-b-k8s-node01节点？起因就是，它的机制是不通过调度器的。nodeName这个字段倡议在生产环境中还是少用，所有Pod都在一个节点上，这就存在单点故障了。其实，测试环境下还是能够用的嘛！ ❞ 最初❝ 对于本篇的分享就到这里，前面还会有更多的小案例分享给大家，欢送继续关注。想要考K8S认证的盆友请猛戳理解：https://mp.weixin.qq.com/s/h1bjcIwy2enVD203o-ntlA 本文转载于（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/qJ8gr4xyuTjXkA6p9Yrp7g

下载先从官网把部署Kubernetes Dashboard的yaml下载到本地。 wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yamlPS：如果因为墙了，本人想方法，总之先下载下来。 部署执行上面的命令进行Kubernetes Dashboard部署 kubectl apply -f ./recommended.yaml执行之后输入以下信息，示意曾经部署胜利 namespace/kubernetes-dashboard createdserviceaccount/kubernetes-dashboard createdservice/kubernetes-dashboard createdsecret/kubernetes-dashboard-certs createdsecret/kubernetes-dashboard-csrf createdsecret/kubernetes-dashboard-key-holder createdconfigmap/kubernetes-dashboard-settings createdrole.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrole.rbac.authorization.k8s.io/kubernetes-dashboard createdrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createddeployment.apps/kubernetes-dashboard createdservice/dashboard-metrics-scraper createddeployment.apps/dashboard-metrics-scraper created查问一下pod和service是否都曾经创立查问kubernetes-dashboard命名空间下全副pod kubectl get pods -n kubernetes-dashboardNAME READY STATUS RESTARTS AGEdashboard-metrics-scraper-64bcc67c9c-6hbv5 1/1 Running 0 4mkubernetes-dashboard-5c8bd6b59-mm7gh 1/1 Running 0 4m查问kubernetes-dashboard命名空间下全副service kubectl get svc -n kubernetes-dashboardNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdashboard-metrics-scraper ClusterIP 10.102.13.19 <none> 8000/TCP 4m22skubernetes-dashboard ClusterIP 10.109.154.224 <none> 443:/TCP 4m22s能够看到service的TYPE是ClusterIP：只对集群外部可见，内部无法访问。NodePort：才可对外部可见。因而然而443端口仍是外部才能够拜访的，咱们机器无法访问，因而须要将443端口映射进去。 映射端口让内部能够拜访执行一下命令，即可随机调配一个30000+的端口映射443即https端口 kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kubernetes-dashboard执行后，咱们再执行kubectl get svc -n kubernetes-dashboard ...

背景2020 年 12 月初，Kubernetes 在其最新的 Changelog 中发表，自 Kubernetes 1.20 之后将弃用 Docker 作为容器运行时。 弃用 Docker 带来的，可能是一系列的扭转，包含不限于： 容器镜像构建工具容器 CLI容器镜像仓库容器运行时专题文章《K8S 1.20 弃用 Docker 评估》会从多方面剖析由此带来的变动和影响，上一篇：《K8S 1.20 弃用 Docker 评估之 Docker 和 OCI 镜像格局的差异》 次要介绍 镜像格局的变动，明天来介绍 Docker CLI 的代替产品及集体举荐。 Docker 命令简介这里通过简略介绍 Docker CLI 的命令，来引出 Docker 作为一个容器的残缺 all-in-one 工具箱，具体包含了这么几大类：容器、镜像及镜像仓库、容器网络的能力。 容器类常用命令重命名：docker rename [CONTAINER_NAME] [NEW_CONTAINER_NAME]运行：docker run [IMAGE] [COMMAND]删除：docker rm [CONTAINER]启动：docker start [CONTAINER]进行：docker stop [CONTAINER]重启：docker restart [CONTAINER]Kill：docker kill [CONTAINER]Attach：docker attach [CONTAINER]运行状态：docker ps日志：docker logs [CONTAINER]Inspect：docker inspect [OBJECT_NAME/ID]Events：docker events [CONTAINER]Top：docker top [CONTAINER]Stats：docker stats [CONTAINER]镜像类常用命令构建：docker build [URL]打 Tag：docker tag登录 DockerHub：docker loginPull：docker pull [IMAGE]Push：docker push [IMAGE]导入镜像：docker import [URL/FILE]从容器创立镜像：docker commit [CONTAINER] [NEW_IMAGE_NAME]删除镜像：docker rmi [IMAGE]加载镜像：docker load [TAR_FILE/STDIN_FILE]保留镜像到 tar 包：docker save [IMAGE] > [TAR_FILE]列出镜像：docke image ls镜像历史：docker history [IMAGE]Docker 配置类命令docker config ...

环境阐明PS：本文档试验过程中并没有对权限做出严格束缚，比方间接在jenkins寄存管理员的kubeconfig文件、间接在jenkins用集群管理员角色对接k8s集群等操作，均有很大危险，须要依据理论状况束缚相应用户的权限。 规划设计：角色地址域名master192.168.10.100node192.168.10.101gitlab192.168.10.110jenkins192.168.10.111jenkins.snow.comharbor192.168.10.112harbor.snow.com试验之前集群曾经搭建结束，搭建教程可参考构建高可用k8s集群，jenkins与gitlab别离应用安装包的形式装置在两台虚拟机上。harbor以容器的形式独自部署在一台虚拟机。 策略设计k8s集群内的pro名称空间模仿生产环境，dev名称空间模仿开发环境，开发环境下的代码只有推送到代码仓库会触发jenkins主动公布到dev名称空间的对应POD，pro名称空间的POD只有管理员手动按选定的tag构建进去的版本才能够公布到k8s环境。 增加kubelet认证，让jenkins能够有操作k8s集群的权限在Harbor仓库别离增加两个新的我的项目，我的项目名别离为pro和dev，用来寄存生产和测试的镜像。为了试验不便将我的项目都配置为了公开模式，如果想要配置为私密模式则须要增加仓库的认证信息，具体参考文章：[docker配置https加密对接k8s]将master节点的.kube文件和kubectl命令发送到jenkins所在的节点 root@master01:~# which kubectl/opt/kube/bin/kubectlroot@master01:~# scp /opt/kube/bin/kubectl 192.168.10.111:/usr/local/bin/kubectlroot@192.168.10.111's password: kubectl 100% 45MB 29.0MB/s 00:01 root@master01:~# scp -r .kube 192.168.10.111:/root/.kuberoot@192.168.10.111's password: config 100% 6241 1.9MB/s 00:00 9f754ca1a0545e7b871b81c83a185054 100% 2460 1.6MB/s 00:00 c4f8f2c14858bcf309490b8356533dde 100% 642 219.8KB/s 00:00 在jenkins验证是否有操作k8s集群的权限 root@jenkins:~# kubectl get noNAME STATUS ROLES AGE VERSION192.168.10.100 Ready master 5d22h v1.22.2192.168.10.101 Ready node 5d22h v1.22.2如果执行get node的时候报错网络超时须要查看.kube/config文件中的server字段是否指定的是apiserver的地址及apiserver的6443端口是否监听在127.0.0.1地址。在jenkins增加拜访k8s集群的凭证登录jenkins后抉择Dashboard->系统管理->凭据->零碎->全局凭据，点击右上角创立一个新的凭据。 类型抉择X.509 Client Certficate，Client Key字段内容填写.kube/config文件中的client-key-data字段数据base64解码后的值。Client Certificate字段填写.kube/config文件中的client-certificate-data字段数据base64解码后的值，Server CA Certificate字段填写.kube/config文件中的certificate-authority-data字段数据base64解码后的值。 增加gitlab认证，让jenkins能够有拉取代码的权限持续依照上一步的操作新增加一个凭证 创立新仓库，别离创立main与dev分支并推送到gitlab。在gitlab新建一个空白我的项目 在master节点应用git命令创立分支并将代码推送到gitlab ...

要点01：软件配置项的起源次要有2块：命令行参数 和 配置文件k8s中的组件个别都是遵循下面的模式咱们以kube-scheduler为例命令参数举例 ：能够看到--xxx=xxx的传参，当然所有参数都是有默认值的，如果你不传就走默认/usr/local/bin/kube-scheduler --log-dir=/var/log/k8s --logtostderr=false --alsologtostderr=true --config=/etc/k8s/kube-scheduler.yaml --kube-api-qps=500 --kube-api-burst=500 --authentication-kubeconfig=/etc/k8s/scheduler.conf --authorization-kubeconfig=/etc/k8s/scheduler.conf --kubeconfig=/etc/k8s/scheduler.conf --leader-elect=true --v=2下面的命令行参数中能够看到--config=xxx.yaml指定了 配置文件的门路比方咱们能够查看 这个配置文件的内容 ：发现根本就是官网的默认配置cat /etc/k8s/kube-scheduler.yamlapiVersion: kubescheduler.config.k8s.io/v1beta1kind: KubeSchedulerConfigurationclientConnection: kubeconfig: "/etc/k8s/scheduler.conf"leaderElection: leaderElect: truemetricsBindAddress: 0.0.0.0:10251要点02：k8s组件提供了一个利用运行时查看失效配置的接口思考为何要提供？次要起因有上面几点 来自命令行和配置文件的配置2块可能有些笼罩的中央配置我的项目太多了在没有配置热更新的状况下：查看变更是否失效： 配置文件曾经更改，但遗记是利用重启前还是重启后改的了所以考究的我的项目外面都会留有一个http接口间接将以后利用内存中失效的配置我的项目打印进去，不便排查问题所以咱们前面写golang的我的项目也能够仿照这个接口要点03 : 如何申请scheduler的配置接口k8s组件对应查看配置的接口就是configz拜访组件接口须要鉴权，咱们能够通过sa来实现如何在1.24集群中创立rbacapiVersion: rbac.authorization.k8s.io/v1 # api的versionkind: ClusterRole # 类型metadata: name: prometheusrules:- apiGroups: [""] resources: # 资源 - nodes - nodes/metrics - 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: prometheussubjects: # 对象- kind: ServiceAccount name: prometheus namespace: kube-system---apiVersion: v1kind: Secretmetadata: namespace: kube-system name: prometheus annotations: kubernetes.io/service-account.name: prometheustype: kubernetes.io/service-account-token获取token命令root@k8s-master01:~# TOKEN=$(kubectl -n kube-system get secret prometheus -o jsonpath='{.data.token}'| base64 --decode )root@k8s-master01:~# echo $TOKENeyJhbGciOiJSUzI1NiIsImtpZCI6ImFVMS1mYlhobWIxcF92djBwbUIxZDhTVlFWd0VNa3VpNDlmOUhqcG9qSlkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJwcm9tZXRoZXVzIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InByb21ldGhldXMiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI2OTg2NWUwYy0yOGE4LTQ3YTEtYWEzYy03NThmNDlkYjA1YWUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06cHJvbWV0aGV1cyJ9.SlORtZtVvLptYWE3zvblaOMxHNMBrHVTTHra7fO1RrwxdK3Bzc42ETLvkzVfQmAQlWrq5yiB4HiKFLe4qY2KVwK3qLDS_sWADLI16Sv8-O1Dt0oOQ0UZD0VOSGY0XEq2EGUxgxnx_JWllgEuMd0rjxtAtyjFh9wjCo_07lFCj44BffGGFp6Kovd8Dl_CJKpORakaJW-haIvTmTlbFPbRKojRTyKvtNCVn0zIXsz8Esp7z9XZmtUvZmHqNlY7bAFtGM9qLWUY_PkM1C0lQ2ZDKASdhZpx6LJr1Wo4WSNILCVfECT0sd6TnFHbgd1NwBc0kcTct5VbST76AJwUpG5esA在http申请中把下面的TOKEN 作为beare-token传过来就能够了申请的curl命令如下(在kube-scheduler部署的节点上执行，通常是master)curl -k -s https://localhost:10259/configz --header "Authorization: Bearer $TOKEN" |python -m json.tool要点04 依据返回的json配置段来剖析插件开启的状况json数据如下{ "componentconfig": { "AlgorithmSource": { "Policy": null, "Provider": "DefaultProvider" }, "ClientConnection": { "AcceptContentTypes": "", "Burst": 100, "ContentType": "application/vnd.kubernetes.protobuf", "Kubeconfig": "/etc/k8s/scheduler.conf", "QPS": 50 }, "EnableContentionProfiling": true, "EnableProfiling": true, "Extenders": null, "HealthzBindAddress": "0.0.0.0:10251", "LeaderElection": { "LeaderElect": true, "LeaseDuration": "15s", "RenewDeadline": "10s", "ResourceLock": "leases", "ResourceName": "kube-scheduler", "ResourceNamespace": "kube-system", "RetryPeriod": "2s" }, "MetricsBindAddress": "0.0.0.0:10251", "Parallelism": 16, "PercentageOfNodesToScore": 0, "PodInitialBackoffSeconds": 1, "PodMaxBackoffSeconds": 10, "Profiles": [ { "PluginConfig": [ { "Args": { "MinCandidateNodesAbsolute": 100, "MinCandidateNodesPercentage": 10 }, "Name": "DefaultPreemption" }, { "Args": { "HardPodAffinityWeight": 1 }, "Name": "InterPodAffinity" }, { "Args": { "AddedAffinity": null }, "Name": "NodeAffinity" }, { "Args": { "IgnoredResourceGroups": null, "IgnoredResources": null }, "Name": "NodeResourcesFit" }, { "Args": { "Resources": [ { "Name": "cpu", "Weight": 1 }, { "Name": "memory", "Weight": 1 } ] }, "Name": "NodeResourcesLeastAllocated" }, { "Args": { "DefaultConstraints": null, "DefaultingType": "System" }, "Name": "PodTopologySpread" }, { "Args": { "BindTimeoutSeconds": 600 }, "Name": "VolumeBinding" } ], "Plugins": { "Bind": { "Disabled": null, "Enabled": [ { "Name": "DefaultBinder", "Weight": 0 } ] }, "Filter": { "Disabled": null, "Enabled": [ { "Name": "NodeUnschedulable", "Weight": 0 }, { "Name": "NodeName", "Weight": 0 }, { "Name": "TaintToleration", "Weight": 0 }, { "Name": "NodeAffinity", "Weight": 0 }, { "Name": "NodePorts", "Weight": 0 }, { "Name": "NodeResourcesFit", "Weight": 0 }, { "Name": "VolumeRestrictions", "Weight": 0 }, { "Name": "EBSLimits", "Weight": 0 }, { "Name": "GCEPDLimits", "Weight": 0 }, { "Name": "NodeVolumeLimits", "Weight": 0 }, { "Name": "AzureDiskLimits", "Weight": 0 }, { "Name": "VolumeBinding", "Weight": 0 }, { "Name": "VolumeZone", "Weight": 0 }, { "Name": "PodTopologySpread", "Weight": 0 }, { "Name": "InterPodAffinity", "Weight": 0 } ] }, "Permit": { "Disabled": null, "Enabled": null }, "PostBind": { "Disabled": null, "Enabled": null }, "PostFilter": { "Disabled": null, "Enabled": [ { "Name": "DefaultPreemption", "Weight": 0 } ] }, "PreBind": { "Disabled": null, "Enabled": [ { "Name": "VolumeBinding", "Weight": 0 } ] }, "PreFilter": { "Disabled": null, "Enabled": [ { "Name": "NodeResourcesFit", "Weight": 0 }, { "Name": "NodePorts", "Weight": 0 }, { "Name": "PodTopologySpread", "Weight": 0 }, { "Name": "InterPodAffinity", "Weight": 0 }, { "Name": "VolumeBinding", "Weight": 0 } ] }, "PreScore": { "Disabled": null, "Enabled": [ { "Name": "InterPodAffinity", "Weight": 0 }, { "Name": "PodTopologySpread", "Weight": 0 }, { "Name": "TaintToleration", "Weight": 0 } ] }, "QueueSort": { "Disabled": null, "Enabled": [ { "Name": "PrioritySort", "Weight": 0 } ] }, "Reserve": { "Disabled": null, "Enabled": [ { "Name": "VolumeBinding", "Weight": 0 } ] }, "Score": { "Disabled": null, "Enabled": [ { "Name": "NodeResourcesBalancedAllocation", "Weight": 1 }, { "Name": "ImageLocality", "Weight": 1 }, { "Name": "InterPodAffinity", "Weight": 1 }, { "Name": "NodeResourcesLeastAllocated", "Weight": 1 }, { "Name": "NodeAffinity", "Weight": 1 }, { "Name": "NodePreferAvoidPods", "Weight": 10000 }, { "Name": "PodTopologySpread", "Weight": 2 }, { "Name": "TaintToleration", "Weight": 1 } ] } }, "SchedulerName": "default-scheduler" } ] }}前置常识 k8s的调度框架 scheduler framework文档地位这张架构图肯定要烂熟于心 咱们发现在 componentconfig.Profiles其实次要分两块：Plugins段代表调度框架每个扩大点的插件开启和禁用的状况： ...

对于小规模集群，因为数据量不大，kube-state-metrics能够应用deploy部署1个replica，失常提供metrics的采集和拉取。 对于大规模集群，因为pod/deploy等资源对象较多，仅通过一个kube-state-metrics实例来提供metrics还是十分吃力的，可能会导致pod宕机，频繁重启。 这种状况下，kube-state-metrics提供了分片机制，也就是部署多个kube-state-metrics Pod，让每个Pod负责一部分数据的采集。 一. 手动分片kube-state-metrics的启动参数中，提供了shard参数： # kube-state-metrics -hkube-state-metrics is a simple service that listens to the Kubernetes API server and generates metrics about the state of the objects.Usage: kube-state-metrics [flags] kube-state-metrics [command]Available Commands: completion Generate completion script for kube-state-metrics. help Help about any command version Print version information.Flags: --shard int32 The instances shard nominal (zero indexed) within the total number of shards. (default 0) --total-shards int The total number of shards. Sharding is disabled when total shards is set to 1. (default 1) ...分片是通过对kubernetes资源对象的uid计算md5，而后 % total_shards 失去shard，每个kube-state-metrics仅负责采集本人的shard。 ...

一、阐明本文介绍基于 Maven 插件 jib-maven-plugin 实现疾速构建 Spring Boot 程序镜像，并推送到近程仓库中，且 无需装置 Docker 环境 。 Jib 是 Google 开发的一个无需 Docker 守护过程，也无需深刻把握 Docker 最佳实际的状况下，为 Java 应用程序构建 Docker 和 OCI 镜像，以 Maven 和 Gradle 插件模式提供。   二、插件应用下图为插件的配置样例，构建后的镜像公布到阿里云仓库中（收费）： 阿里云仓库配置以及用户名明码须要依照本人注册的信息进行批改 注册地址：https://cr.console.aliyun.com/ 插件具体的配置可查看：https://github.com/GoogleCont... 配置中减少了 execution 进行触发，当 Maven 执行 package 命令时会主动构建并公布镜像： 登录阿里云容器镜像服务，即可查看咱们公布的镜像：   三、总结对于 Java 程序来说应用 jib-maven-plugin 插件来构建镜像还是十分不便的。 与传统的 dockerfile 构建镜像的形式比照： 构建形式dockerfileJibdocker环境须要无需dockerfile文件须要无需构建复杂度较简单很不便灵便度高绝对较高  PS：怎么通过 Jib 在构建镜像的时候实现 dockerfile 中的相似 RUN 之类的命令，如装置一个程序运行时所须要的字体？ 答：不反对，然而解决形式也很简略，只需先基于 dockerfile 这种形式构建一个装置好所需字体的根底镜像，而后在 Jib 中通过 from 依赖这个镜像来构建微服务的镜像即可。 ...

Loki 是一个由Grafana Labs 开发的开源日志聚合零碎，旨在为云原生架构提供高效的日志解决解决方案。 Loki 通过应用相似 Prometheus 的标签索引机制来存储和查问日志数据，这使得它可能疾速地进行分布式查问和聚合，而不须要将所有数据都从存储中加载到内存中。Loki还应用了压缩和切割日志数据的办法来缩小存储空间的占用，从而更好地适应云原生环境下的高速增长的日志数据量。 Loki的架构由以下几个次要组件组成： Promtail: 负责采集应用程序和零碎的日志数据，并将其发送到 Loki 的集群中。 Loki: 负责存储日志数据，提供 HTTP API 的日志查问，以及数据过滤和筛选。 Grafana: 负责 UI 展现日志数据。 Loki vs ELKLoki 和 ELK（Elasticsearch, Logstash, Kibana）都是罕用的日志解决零碎，它们各自具备一些长处。上面是 Loki 绝对于 ELK 的几个长处： 存储效率更高：Loki 应用了压缩和切割日志数据的办法来缩小存储空间的占用，相比之下，ELK 须要保护一个大的索引，须要更多的存储空间。查问速度更快：Loki 应用相似 Prometheus 的标签索引机制存储和查问日志数据，这使得它可能疾速地进行分布式查问和聚合，而不须要将所有数据都从存储中加载到内存中。而ELK须要将数据从存储中加载到内存中进行查问，查问速度绝对较慢。部署和治理更容易：Loki 是一个轻量级的日志聚合零碎，相比之下，ELK 须要部署和治理多个组件，须要更多的资源和人力老本。装置和配置 Loki前提参阅 Rainbond 疾速装置 文档进行装置。 装置 LokiLoki 利用已公布到开源利用商店，可通过开源利用商店一键装置。 在 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 Loki 并装置。 装置实现后，该利用内蕴含 Loki Grafana 组件： 同时还有 k8s资源，其中包含 promtail 的 Daemonset 以及 SA 等资源。 ...

https://www.bilibili.com/video/BV1PE411T7F2/?spm_id_from=333.999.0.0&vd_source=5a0ac7fdc99ad21b5796cfcad3fe7c61

前言K8s是一个弱小的平台，但它的网络比较复杂，波及很多概念，例如Pod网络，Service网络，Cluster IPs，NodePort，LoadBalancer和Ingress等等，这么多概念足以让老手望而却步。然而，只有深刻了解K8s网络，能力为了解和用好K8s打下坚实基础。为了帮忙大家了解，模拟TCP/IP协定栈，我把K8s的网络合成为四个形象层，从0到3，除了第0层，每一层都是构建于前一层之上，如下图所示： 第0层Node节点网络比拟好了解，也就是保障K8s节点(物理或虚拟机)之间可能失常IP寻址和互通的网络，这个个别由底层(私有云或数据中心)网络基础设施反对。第0层咱们假设曾经存在，所以不开展。第1到3层网络，我将分三篇文章，别离进行分析，本文是第一篇Pod网络。 留神，本文旨在帮忙大家建设K8s网络的概念模型，而不是对底层技术的准确形容。理论咱们学技术以利用为主，重要的是疾速建设起直观易懂的概念模型，可能领导咱们失常利用即可，当然了解肯定的技术细节也是有帮忙的。另外，本文假设读者对根本的网络技术，ip地址空间和容器技术等有肯定的理解。 Pod网络概念模型Pod相当于是K8s云平台中的虚拟机，它是K8s的根本调度单位。所谓Pod网络，就是可能保障K8s集群中的所有Pods(包含同一节点上的，也包含不同节点上的Pods)，逻辑上看起来都在同一个平面网络内，可能互相做IP寻址和通信的网络，下图是Pod网络的简化概念模型： Pod网络构建于Node节点网络之上，它又是下层Service网络的根底。为了进一步了解Pod网络，我将对同一节点上的Pod之间的网络，以及不同节点上的Pod之间网络，别离进行分析。 同一节点上的Pod网络后面提到，Pod相当于是K8s云平台中的虚拟机，理论一个Pod中能够住一个或者多个(大多数场景住一个)利用容器，这些容器共享Pod的网络栈和其它资源如Volume。那么什么是共享网络栈？同一节点上的Pod之间如何寻址和互通？我以下图样例来解释： 上图节点上展现了Pod网络所依赖的3个网络设备，eth0是节点主机上的网卡，这个是反对该节点流量出入的设施，也是反对集群节点间IP寻址和互通的设施。docker0是一个虚构网桥，能够简略了解为一个虚构交换机，它是反对该节点上的Pod之间进行IP寻址和互通的设施。veth0则是Pod1的虚构网卡，是反对该Pod内容器互通和对外拜访的虚构设施。docker0网桥和veth0网卡，都是linux反对和创立的虚构网络设备。 上图Pod1外部住了3个容器，它们都共享一个虚构网卡veth0。外部的这些容器能够通过localhost互相拜访，然而它们不能在同一端口上同时开启服务，否则会有端口抵触，这就是共享网络栈的意思。Pod1中还有一个比拟非凡的叫pause的容器，这个容器运行的惟一目标是为Pod建设共享的veth0网络接口。如果你SSH到K8s集群中一个有Pod运行的节点下来，而后运行docker ps，能够看到通过pause命令运行的容器。 Pod的IP是由docker0网桥调配的，例如上图docker0网桥的IP是172.17.0.1，它给第一个Pod1调配IP为172.17.0.2。如果该节点上再启一个Pod2，那么相应的调配IP为172.17.0.3，如果再启动Pod可顺次类推。因为这些Pods都连在同一个网桥上，在同一个网段内，它们能够进行IP寻址和互通，如下图所示： 从上图咱们能够看到，节点内Pod网络在172.17.0.0/24这个地址空间内，而节点主机在10.100.0.0/24这个地址空间内，也就是说Pod网络和节点网络不在同一个网络内，那么不同节点间的Pod该如何IP寻址和互通呢？下一节咱们来剖析这个问题。 不同节点间的Pod网络当初假如咱们有两个节点主机，host1(10.100.0.2)和host2(10.100.0.3)，它们在10.100.0.0/24这个地址空间内。host1上有一个PodX(172.17.0.2)，host2上有一个PodY(172.17.1.3)，Pod网络在172.17.0.0/16这个地址空间内。留神，Pod网络的地址，是由K8s对立治理和调配的，保障集群内Pod的IP地址惟一。咱们发现节点网络和Pod网络不在同一个网络地址空间内，那么host1上的PodX该如何与host2上的PodY进行互通？ 实际上不同节点间的Pod网络互通，有很多技术实现计划，底层的技术细节也很简单。为了简化形容，我把这些计划大体分为两类，一类是路由计划，另外一类是笼罩(Overlay)网络计划。 如果底层的网络是你能够管制的，比如说企业外部自建的数据中心，并且你和运维团队的关系比拟好，能够采纳路由计划，如下图所示： 这个计划简略了解，就是通过路由设施为K8s集群的Pod网络独自划分网段，并配置路由器反对Pod网络的转发。例如上图中，对于指标为172.17.1.0/24这个范畴内的包，转发到10.100.0.3这个主机上，同样，对于指标为172.17.0.0/24这个范畴内的包，转发到10.100.0.2这个主机上。当主机的eth0接口接管到来自Pod网络的包，就会向内部网桥转发，这样不同节点间的Pod就能够互相IP寻址和通信。这种计划依赖于底层的网络设备，然而不引入额定性能开销。 如果底层的网络是你无法控制的，比如说私有云网络，或者企业的运维团队不反对路由计划，能够采纳笼罩(Overlay)网络计划，如下图所示： 所谓笼罩网络，就是在现有网络之上再建设一个虚构网络，实现技术有很多，例如flannel/weavenet等等，这些计划大都采纳隧道封包技术。简略了解，Pod网络的数据包，在出节点之前，会先被封装成节点网络的数据包，当数据包达到指标节点，包内的Pod网络数据包会被解封进去，再转发给节点外部的Pod网络。这种计划对底层网络没有特地依赖，然而封包解包会引入额定性能开销。 CNI简介思考到Pod网络实现技术泛滥，为了简化集成，K8s反对CNI(Container Network Interface)规范，不同的Pod网络技术能够通过CNI插件模式和K8s进行集成。节点上的Kubelet通过CNI标准接口操作Pod网路，例如增加或删除网络接口等，它不须要关怀Pod网络的具体实现细节。 总结K8s的网络能够形象成四层网络，第0层节点网络，第1层Pod网络，第2层Service网络，第3层内部接入网络。除了第0层，每一层都构建于上一层之上。一个节点内的Pod网络依赖于虚构网桥和虚构网卡等linux虚构设施，保障同一节点上的Pod之间能够失常IP寻址和互通。一个Pod内容器共享该Pod的网络栈，这个网络栈由pause容器创立。不同节点间的Pod网络，能够采纳路由计划实现，也能够采纳笼罩网络计划。路由计划依赖于底层网络设备，但没有额定性能开销，笼罩网络计划不依赖于底层网络，但有额定封包解包开销。CNI是一个Pod网络集成规范，简化K8s和不同Pod网络实现技术的集成。有了Pod网络，K8s集群内的所有Pods在逻辑上都能够看作在一个平面网络内，能够失常IP寻址和互通。然而Pod仅仅是K8s云平台中的虚拟机形象，最终，咱们须要在K8s集群中运行的是利用或者说服务(Service)，而一个Service背地个别由多个Pods组成集群，这时候就引入了服务发现(Service Discovery)和负载平衡(Load Balancing)等问题，这是波波的下一篇《Kubernetes网络三部曲～Service网络》要分析的内容，敬请期待。————————————————版权申明：本文为CSDN博主「架构师波波」的原创文章，遵循CC 4.0 BY-SA版权协定，转载请附上原文出处链接及本申明。原文链接：https://blog.csdn.net/yang751...

一、阐明本文次要介绍在 Centos7 环境下基于 Minikube 来疾速部署 Kubernetes 单节点集群环境，并在浏览器上拜访部署在 k8s 上的 dashboard 服务。   二、Minikube 介绍Minikube 是一个基于go语言开发，易于在本地运行 Kubernetes 的工具，可在你的笔记本电脑上的虚拟机内轻松创立单机版 Kubernetes 集群，对硬件资源没有太高的要求，非常适合 测试 和 本地开发。 官网文档：https://minikube.sigs.k8s.io/...架构图： 运作原理： 从 Minikube 的架构中能够看出 master 节点与其它节点合为一体，而整体则通过宿主机上的 kubectl 进行治理，这样能够更加 节俭资源。 简略来说就是，用户应用 Minikube CLI 治理虚拟机上的 Kubernetes 环境，比方：启动，进行，删除，获取状态等。一旦 Minikube 虚拟机启动，用户就能够应用相熟的 Kubectl CLI 在 Kubernetes 集群上执行操作。   三、Minikube装置3.1. 零碎要求 CUP：2核以上内存：2GB以上硬盘：须要20G网络：能连因特网(须要下载安装包)，容器：须要先装置Docker或其余容器。  3.2. 装置前筹备3.2.1. 装置 Docker装置步骤参考：https://www.runoob.com/docker... docker 的最低倡议版本为 20.10.0 以上配置阿里云加速器：https://cr.console.aliyun.com... 启动 docker： systemctl start dockersystemctl enable docker.service  3.2.2. 创立新用户操作 minikube 须要一个具备 root 权限的用户(非root)须要将该用户增加进入 docker 用户组 ...

前言为了不便用户装置istio和操作相应的manifest，社区将本来的纯helm装置模式演变成现在的cli和operator模式(https://docs.google.com/docum...)。同时为了保障后向兼容和良好的代码复用，cli复用operator提供的命令行api，operator命令行基于helm的chart渲染进行实现。根本的模式构造如下图所示：因而，本文从istioctl提供的install和manifest指令登程，依照istioctl->operator->helm的方向进行剖析，重点形容operator中cmd的实现流程。 Installistioctl命令行参数与实例此节可参考https://istio.io/latest/docs/...官网文档。 代码入口istioctl实质上是利用cobra编写的命令行程序，在/istio/istioctl/cmd/root.go中将InstallCmd退出RootCmd中，而InstallCmd由operator实现。 installCmd := mesh.InstallCmd(loggingOptions)hideInheritedFlags(installCmd, FlagNamespace, FlagIstioNamespace, FlagCharts)rootCmd.AddCommand(installCmd)operator代码流程与重要函数整体构造如下图所示。接下来，以istioctl install --set installPackagePath=/istio/manifests --set profile=empty -f test0.yaml -f test1.yaml为例，剖析各个函数。其中test0.yaml和test1.yaml的内容如下图所示。 # test0.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec: profile: minimal hub: docker.io/istio tag: 1.1.4 components: pilot: enabled: true# test1.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec: hub: docker.io/istio tag: 1.1.5 components: pilot: enabled: trueParseYAMLFilesParseYAMLFiles从左到右读取并笼罩-f标记所传入的IstioOperator yaml，并提取出其中的profile字段。因而提取出的profile为minimal，test0.yaml和test1.yaml的初步处理结果temp0.yaml如下所示。 # temp0.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec: profile: minimal hub: docker.io/istio tag: 1.1.5 components: pilot: enabled: trueReadYaml(And)ProfileReadYamlProfile依据--set profile=empty对ParseYAMLFiles返回的profile后果进行笼罩，因而最终的profile为empty。 GetProfileYAMLGetProfileYAML从--set installPackagePath=/istio/manifests指定的目录读取empty yaml，因为istio所提供的所有内置profile都基于default profile，因而利用empty yaml去笼罩default profile，最终失去temp1.yaml。 #empty yaml# The empty profile has everything disabled# This is useful as a base for custom user configurationapiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec: components: base: enabled: false pilot: enabled: false ingressGateways: - name: istio-ingressgateway enabled: false#default yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatormetadata: namespace: istio-systemspec: hub: gcr.io/istio-testing tag: latest # You may override parts of meshconfig by uncommenting the following lines. meshConfig: defaultConfig: proxyMetadata: {} enablePrometheusMerge: true # Opt-out of global http2 upgrades. # Destination rule is used to opt-in. # h2_upgrade_policy: DO_NOT_UPGRADE # Traffic management feature components: base: enabled: true pilot: enabled: true # Istio Gateway feature ingressGateways: - name: istio-ingressgateway enabled: true egressGateways: - name: istio-egressgateway enabled: false # Istio CNI feature cni: enabled: false # Remote and config cluster configuration for an external istiod istiodRemote: enabled: false # Global values passed through to helm global.yaml. # Please keep this in sync with manifests/charts/global.yaml values: defaultRevision: "" global: istioNamespace: istio-system istiod: enableAnalysis: false logging: level: "default:info" logAsJson: false pilotCertProvider: istiod jwtPolicy: third-party-jwt proxy: image: proxyv2 clusterDomain: "cluster.local" resources: requests: cpu: 100m memory: 128Mi limits: cpu: 2000m memory: 1024Mi logLevel: warning componentLogLevel: "misc:error" privileged: false enableCoreDump: false statusPort: 15020 readinessInitialDelaySeconds: 1 readinessPeriodSeconds: 2 readinessFailureThreshold: 30 includeIPRanges: "*" excludeIPRanges: "" excludeOutboundPorts: "" excludeInboundPorts: "" autoInject: enabled tracer: "zipkin" proxy_init: image: proxyv2 resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 10m memory: 10Mi # Specify image pull policy if default behavior isn't desired. # Default behavior: latest images will be Always else IfNotPresent. imagePullPolicy: "" operatorManageWebhooks: false tracer: lightstep: {} zipkin: {} datadog: {} stackdriver: {} imagePullSecrets: [] oneNamespace: false defaultNodeSelector: {} configValidation: true multiCluster: enabled: false clusterName: "" omitSidecarInjectorConfigMap: false network: "" defaultResources: requests: cpu: 10m defaultPodDisruptionBudget: enabled: true priorityClassName: "" useMCP: false sds: token: aud: istio-ca sts: servicePort: 0 meshNetworks: {} mountMtlsCerts: false base: enableCRDTemplates: false validationURL: "" pilot: autoscaleEnabled: true autoscaleMin: 1 autoscaleMax: 5 replicaCount: 1 image: pilot traceSampling: 1.0 env: {} cpu: targetAverageUtilization: 80 nodeSelector: {} keepaliveMaxServerConnectionAge: 30m enableProtocolSniffingForOutbound: true enableProtocolSniffingForInbound: true deploymentLabels: podLabels: {} configMap: true telemetry: enabled: true v2: enabled: true metadataExchange: wasmEnabled: false prometheus: wasmEnabled: false enabled: true stackdriver: enabled: false logging: false monitoring: false topology: false configOverride: {} istiodRemote: injectionURL: "" gateways: istio-egressgateway: env: {} autoscaleEnabled: true type: ClusterIP name: istio-egressgateway secretVolumes: - name: egressgateway-certs secretName: istio-egressgateway-certs mountPath: /etc/istio/egressgateway-certs - name: egressgateway-ca-certs secretName: istio-egressgateway-ca-certs mountPath: /etc/istio/egressgateway-ca-certs istio-ingressgateway: autoscaleEnabled: true type: LoadBalancer name: istio-ingressgateway env: {} secretVolumes: - name: ingressgateway-certs secretName: istio-ingressgateway-certs mountPath: /etc/istio/ingressgateway-certs - name: ingressgateway-ca-certs secretName: istio-ingressgateway-ca-certs mountPath: /etc/istio/ingressgateway-ca-certs#temp1.yamlapiVersion: install.istio.io/v1alpha1kind: IstioOperatormetadata: namespace: istio-systemspec: components: base: enabled: false cni: enabled: false egressGateways: - enabled: false name: istio-egressgateway ingressGateways: - enabled: false name: istio-ingressgateway istiodRemote: enabled: false pilot: enabled: false hub: gcr.io/istio-testing meshConfig: defaultConfig: proxyMetadata: {} enablePrometheusMerge: true tag: latest values: base: enableCRDTemplates: false validationURL: "" defaultRevision: "" gateways: istio-egressgateway: autoscaleEnabled: true env: {} name: istio-egressgateway secretVolumes: - mountPath: /etc/istio/egressgateway-certs name: egressgateway-certs secretName: istio-egressgateway-certs - mountPath: /etc/istio/egressgateway-ca-certs name: egressgateway-ca-certs secretName: istio-egressgateway-ca-certs type: ClusterIP istio-ingressgateway: autoscaleEnabled: true env: {} name: istio-ingressgateway secretVolumes: - mountPath: /etc/istio/ingressgateway-certs name: ingressgateway-certs secretName: istio-ingressgateway-certs - mountPath: /etc/istio/ingressgateway-ca-certs name: ingressgateway-ca-certs secretName: istio-ingressgateway-ca-certs type: LoadBalancer global: configValidation: true defaultNodeSelector: {} defaultPodDisruptionBudget: enabled: true defaultResources: requests: cpu: 10m imagePullPolicy: "" imagePullSecrets: [] istioNamespace: istio-system istiod: enableAnalysis: false jwtPolicy: third-party-jwt logAsJson: false logging: level: default:info meshNetworks: {} mountMtlsCerts: false multiCluster: clusterName: "" enabled: false network: "" omitSidecarInjectorConfigMap: false oneNamespace: false operatorManageWebhooks: false pilotCertProvider: istiod priorityClassName: "" proxy: autoInject: enabled clusterDomain: cluster.local componentLogLevel: misc:error enableCoreDump: false excludeIPRanges: "" excludeInboundPorts: "" excludeOutboundPorts: "" image: proxyv2 includeIPRanges: '*' logLevel: warning privileged: false readinessFailureThreshold: 30 readinessInitialDelaySeconds: 1 readinessPeriodSeconds: 2 resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 100m memory: 128Mi statusPort: 15020 tracer: zipkin proxy_init: image: proxyv2 resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 10m memory: 10Mi sds: token: aud: istio-ca sts: servicePort: 0 tracer: datadog: {} lightstep: {} stackdriver: {} zipkin: {} useMCP: false istiodRemote: injectionURL: "" pilot: autoscaleEnabled: true autoscaleMax: 5 autoscaleMin: 1 configMap: true cpu: targetAverageUtilization: 80 deploymentLabels: null enableProtocolSniffingForInbound: true enableProtocolSniffingForOutbound: true env: {} image: pilot keepaliveMaxServerConnectionAge: 30m nodeSelector: {} podLabels: {} replicaCount: 1 traceSampling: 1 telemetry: enabled: true v2: enabled: true metadataExchange: wasmEnabled: false prometheus: enabled: true wasmEnabled: false stackdriver: configOverride: {} enabled: false logging: false monitoring: false topology: falseOverlayIOPOverlayIOP将ReadYaml(And)Profile所失去的temp0.yaml笼罩于temp1.yaml之上，失去final.yaml ...

ingress-nginx controller组件裸露了/metrics接口，prometheus能够拉取它的指标。 本文重点关注其外部指标的获取办法。 一. 创立ingress1. 创立deployapiVersion: apps/v1kind: Deploymentmetadata: labels: app: nginx name: nginx-deployspec: replicas: 2 ##2正本 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.14 imagePullPolicy: IfNotPresent name: nginx restartPolicy: Always2. 创立serviceapiVersion: v1kind: Servicemetadata: labels: app: nginx-svc name: nginx-svcspec: ports: - name: http port: 80 protocol: TCP targetPort: 80 selector: app: nginx sessionAffinity: None type: ClusterIP3. 创立ingressapiVersion: networking.k8s.io/v1 kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: "nginx" name: nginx-ingressspec: rules: - host: example.com http: paths: - backend: service: name: nginx-svc port: number: 80 path: / pathType: ImplementationSpecific拜访http://example.com:20004/，controller监听在hostNetwork的20004端口 ...

背景：紧接AWS简略搭建应用EKS一，eks集群简略搭建实现。须要搭建有状态服务必然就用到了storageclass 存储类，这里用ebs记录以下 AWS简略搭建应用EKS二存储类选型：参照官网文档：https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#the-storageclass-resource 对于eks的存储类：参照：存储类集体这里习惯用EBS块存储！ 应用 AWS CLI 创立 Amazon EBS CSI 插件 IAM 角色参照：https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/csi-iam-role.html 查看集群的 OIDC 提供商 URL查看集群的 OIDC 提供商 URL，将 my-cluster 替换为您的集群名称。如果命令的输入为 None，请查看先决条件：这里采纳了AWS CLI形式增加： aws eks describe-cluster \ --name my-cluster \ --query "cluster.identity.oidc.issuer" \ --output text输入内容如下： https://oidc.eks.cn-north-1.amazonaws.com.cn/id/xxxxxxxxx留神： url中的 加粗黑体的关键词 https://oidc.eks.cn-north-1.amazonaws.com.cn/id/xxxxxxxxx 创立 IAM 角色生成aws-ebs-csi-driver-trust-policy.json将以下内容复制到名为 _aws-ebs-csi-driver-trust-policy_.json 的文件中。请将 111122223333 替换为您的账户 ID，将 _region-code_ 替换为您的 AWS 区域，并将 EXAMPLED539D4633E53DE1B71EXAMPLE 替换为上一步骤中返回的值。如果您的集群位于 AWS GovCloud（美国东部）或 AWS GovCloud（美国西部）AWS 区域，则将 arn:aws: 替换为 arn:aws-us-gov: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com", "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa" } } } ]}因为实例在中国区我的json内容如下：留神箭头指向的关键词的替换！ ...

k8s的组件有哪些，作用别离是什么k8s次要由master节点和node节点形成。master节点负责管理集群，node节点是容器利用真正运行的中央。master节点蕴含的组件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。node节点蕴含的组件有：kubelet、kube-proxy、container-runtime。 kube-api-server：以下简称api-server，api-server是k8s最重要的外围组件之一，它是k8s集群治理的对立拜访入口，提供了RESTful API接口, 实现了认证、受权和准入管制等平安性能；api-server还是其余组件之间的数据交互和通信的枢纽，其余组件彼此之间并不会间接通信，其余组件对资源对象的增、删、改、查和监听操作都是交由api-server解决后，api-server再提交给etcd数据库做长久化存储，只有api-server能力间接操作etcd数据库，其余组件都不能间接操作etcd数据库，其余组件都是通过api-server间接的读取，写入数据到etcd。 kube-controller-manager：以下简称controller-manager，controller-manager是k8s中各种控制器的的管理者，是k8s集群外部的治理控制中心，也是k8s自动化性能的外围；controller-manager外部蕴含replication controller、node controller、deployment controller、endpoint controller等各种资源对象的控制器，每种控制器都负责一种特定资源的管制流程，而controller-manager正是这些controller的外围管理者。 kube-scheduler：以下简称scheduler，scheduler负责集群资源调度，其作用是将待调度的pod通过一系列简单的调度算法计算出最合适的node节点，而后将pod绑定到指标节点上。shceduler会依据pod的信息，全副节点信息列表，过滤掉不符合要求的节点，过滤出一批候选节点，而后给候选节点打分，选分最高的就是最佳节点，scheduler就会把指标pod安置到该节点。 Etcd：etcd是一个分布式的键值对存储数据库，次要是用于保留k8s集群状态数据，比方，pod，service等资源对象的信息；etcd能够是单个也能够有多个，多个就是etcd数据库集群，etcd通常部署奇数个实例，在大规模集群中，etcd有5个或7个节点就足够了；另外阐明一点，etcd实质上能够不与master节点部署在一起，只有master节点能通过网络连接etcd数据库即可。 kubelet：每个node节点上都有一个kubelet服务过程，kubelet作为连贯master和各node之间的桥梁，负责保护pod和容器的生命周期，当监听到master下发到本节点的工作时，比方创立、更新、终止pod等工作，kubelet 即通过管制docker来创立、更新、销毁容器；每个kubelet过程都会在api-server上注册本节点本身的信息，用于定期向master汇报本节点资源的应用状况。 kube-proxy：kube-proxy运行在node节点上，在Node节点上实现Pod网络代理，保护网络规定和四层负载平衡工作，kube-proxy会监听api-server中从而获取service和endpoint的变动状况，创立并保护路由规定以提供服务IP和负载平衡性能。简略了解此过程是Service的通明代理兼负载均衡器，其外围性能是将到某个Service的拜访申请转发到后端的多个Pod实例上。 container-runtime：容器运行时环境，即运行容器所须要的一系列程序，目前k8s反对的容器运行时有很多，如docker、rkt或其余，比拟受欢迎的是docker，然而新版的k8s曾经发表弃用docker。 kubelet的性能、作用是什么？（重点，常常会问）答：kubelet部署在每个node节点上的，它次要有2个性能：1、节点治理。kubelet启动时会向api-server进行注册，而后会定时的向api-server汇报本节点信息状态，资源应用状态等，这样master就可能晓得node节点的资源残余，节点是否失联等等相干的信息了。master晓得了整个集群所有节点的资源状况，这对于 pod 的调度和失常运行至关重要。2、pod治理。kubelet负责保护node节点上pod的生命周期，当kubelet监听到master的下发到本人节点的工作时，比方要创立、更新、删除一个pod，kubelet 就会通过CRI（容器运行时接口）插件来调用不同的容器运行时来创立、更新、删除容器；常见的容器运行时有docker、containerd、rkt等等这些容器运行时，咱们最相熟的就是docker了，但在新版本的k8s曾经弃用docker了，k8s1.24版本中曾经应用containerd作为容器运行时了。3、容器健康检查。pod中能够定义启动探针、存活探针、就绪探针等3种，咱们最罕用的就是存活探针、就绪探针，kubelet 会定期调用容器中的探针来检测容器是否存活，是否就绪，如果是存活探针，则会依据探测后果对查看失败的容器进行相应的重启策略；4、Metrics Server资源监控。在node节点上部署Metrics Server用于监控node节点、pod的CPU、内存、文件系统、网络应用等资源应用状况，而kubelet则通过Metrics Server获取所在节点及容器的上的数据。 参考：这https://blog.csdn.net/MssGuo/... 版权申明：本文为CSDN博主「MssGuo」的原创文章，遵循CC 4.0 BY-SA版权协定，转载请附上原文出处链接及本申明。原文链接：https://blog.csdn.net/MssGuo/... pod创立过程用户通过kubectl或其它API客户端提交pod spec给API Server。API Server尝试着将pod对象的相干信息存入etcd中，带写入操作执行实现后，API Server会立刻返回确认信息至客户端。Scheduler通过其watcher检测到API Server创立了新的pod对象，于是为该pod对象筛选一个工作节点并将后果信息更新至API Server。调度后果信息有API Server更新至etcd存储系统，并同步给Scheduler。相应节点的kubelet检测到由调度器绑定于本节点的pod后会读取其配置信息，并由本地容器运行时创立相应的容器启动pod对象后将后果回存至API Server。API Server将kubelet发来的pod状态信息存入etcd零碎，并将确认信息发送至相应的kubelet。 容器设计模式单容器模式是指将应用程序封装为利用容器运行。该模式须要遵循简略和繁多准则，每个容器仅承载一种工作负载。 单节点多容器模式单节点多容器模式是指扩容器的设计模式，其目标是在单个主机之上同时运行多个共生关系的容器，因此容器管理系统须要将它们作为一个原子单位进行同一调度。kubernetes编排零碎设计的pod概念就是这个设计模式的实现之一。 若多个容器间存在强耦合关系，它们具备完全相同的生命周期，或者必须运行于同一节点之上时，通常应该将它们置于同一个pod中，较常见的状况是为主容器并行运行一个助理治理过程。单节点多容器模式的常见实现有Sidercar（边车）、适配器（Adapter）、大使（Ambassador）、初始化（Initializer）容器模式等。 Sidecar模式Sidecar模式是多容器零碎设计的最罕用模式，它由一个主应用程序以及一个辅助容器（Sidecar）组成，该辅助容器用于为主容器提供辅助服务以加强主容器性能，是主应用程序必不可少的一部分，但却不肯定非得存在于应用程序自身外部。 最常见的sidecar容器时日志记录服务、数据同步服务、配置服务和代理服务等。对于主容器利用的每个实例，Sidecar的实例都被部署并托管在它旁边，主容器与sidecar容器具备雷同的生命周期，毕竟主容器运行时，运行sidecar容器并无实际意义，只管齐全能够将sidecar容器集成到主容器外部，然而应用不同的容器来运行解决不同性能还是存在较多劣势； 辅助利用的运行时环境和编译语言与主应用程序无关，因此无需为每种为每种编程语言别离开发一个辅助工具；二者可基于IPC、lo接口或共享存储进行数据交换，不存在显著的通信提早；容器镜像时公布的根本单位，将主利用与辅助利用划分为两个容器使得可由不同团队开发和保护，从而变得不便及高效，独自测试及集成测试也变得可能；容器限度了故障边界，使得零碎整体能够优雅降级，例如sidecar容器异样时主容器仍可提供服务；容器时部署的根本单元，每个功能模块均可独立部署及回滚。https://blog.51cto.com/wanggu... 参考文档

原文作者：Amir Rawdat of F5 原文链接：应用 NGINX 在 Kubernetes 中实现多租户和命名空间隔离 转载起源：NGINX 官方网站NGINX惟一中文官网社区 ，尽在 nginx.org.cn 随着企业规模的不断扩大，Kubernetes 中的开发和经营工作流程也变得更加简单。与每个团队都领有本人的集群相比，各个团队之间共享 Kubernetes 集群和集群中资源的做法通常更经济高效、更平安。然而，如果团队无奈以安全可靠的形式共享资源或者配置遭黑客利用，则可能会对部署的利用零碎造成重大侵害。 网络和资源级别的多租户实际和命名空间隔离有助于团队平安地共享 Kubernetes 资源。您还能够依照单租户独占的形式隔离利用，从而显著放大攻打的影响范畴。这种办法有助于进步弹性，因为只有特定团队领有的局部利用可能会受到侵害，而提供其余性能的零碎则完整无缺。 NGINX Ingress Controller 反对多种多租户模式，但最常见的次要是下列的两种模式： 基础架构服务提供商模式通常指应用隔离的 NGINX Ingress Controller，通过物理基础架构隔离来实现多租户；企业模式指应用共享的 NGINX Ingress Controller 部署，通过命名空间隔离来实现多租户。咱们将在本节深入探讨企业模式；无关运行多个 NGINX Ingress Controllers 的更多信息，请参阅咱们的文档。 应用 NGINX Ingress Controller 进行委派NGINX Ingress Controller 既反对规范 Kubernetes Ingress 资源，也反对自定义 NGINX Ingress 资源，可提供更简单的流量治理并配置管制工作委派给多个团队。自定义资源为VirtualServer、 VirtualServerRoute、GlobalConfiguration、TransportServer及Policy。 借助 NGINX Ingress Controller，集群管理员可应用 VirtualServer 资源来配置 Ingress 域名（主机名）规定，将内部流量路由到后端利用，也可应用 VirtualServerRoute 资源将特定 URL 的治理委派给利用所有者和 DevOps 团队。 在 Kubernetes 集群中实现多租户时，有两种模型可供您抉择齐全自助服务和受限自助服务。 施行齐全自助服务在齐全自助服务模型中，管理员不参加 NGINX Ingress Controller 所监控的 Ingress 资源的日常更改。他们只负责部署 NGINX Ingress Controller 及如何将部署的 KubernetesService裸露给内部。之后，开发人员在指定的命名空间内部署利用，而无需管理员参加。开发人员负责管理 TLS 密钥，定义域名的负载平衡配置，并通过创立 VirtualServer 或规范的Ingress资源裸露其利用。 ...

背景：海内服务合作方服务器部署在新加坡AWS,而后就顺便应用了一下AWS下面的各项服务。最近要给合作方写交付文档，就顺便写一下相干服务的简略应用，并没有太深刻，因为所有环境搭建根本都是速成流程，小公司说上就上，没有工夫深入研究积攒，且次要服务环境都运行在国外腾讯云and阿里云。上面是一些流程的演示！留神：演示流程搭建在aws北京区，故很多arn:aws-cn会，请留神各项区别！以下操作区域都默认为北京。在集体各项操作中请确认操作区域！ 从VPC开始注： 如果已有VPC并且vpc合乎应用需要能够疏忽这一步。 对于VPCaws官网文档：https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html也能够依照国内两个云商的文档了解：VPC Virtual Private Cloud(Virtual Private Cloud)户基于xxxx创立的自定义公有网络, 不同的专有网络之间二层逻辑隔离，用户能够在本人创立的专有网络内创立和治理云产品实例，比方ECS、SLB、RDS等。借用国内两家云商的官网文档，大同小异！ 登录aws控制台登陆aws控制台，点击左上角Services 搜寻VPC并进入VPC控制台点击Service-All services 搜寻 vpc 。点击进入vpc控制台。 创立VPCVPC控制台面版点击创立VPC：VPC设置这里抉择VPC等还是很不便的间接抉择VPC等，设置自定义VPC名称，ipv4 cidr块能够自定义设置，这里就默认10.0.0.0/16，如果有须要多VPC网络互通，避免地址段抵触，进行更具体的划分，能够应用子网划分工具更好的划分设计网络。IPV6 cidr块放弃默认未启用。可用区AZ这里设置为3,毕竟多可用区能够更好的容灾高可用。子网设置这里没有启动公有子网private网络，设置了3个public子网跟AZ的数量是统一的创立，期待VPC创立实现，查看VPC 重要揭示VPC控制台找到三个对应子网subset操作编辑子网设置：启动主动调配IP设置，否则EC2无奈主动生成绑定公网IP，须要手动创立并绑定EC2！留神：是三个public子网都要设置一下，否则无奈启用主动调配公网IP.当然也能够用private私网，这里演示都是以public子网演示 创立EKS服务EKS -Amazon Elastic Kubernetes Service 跟国内的tke ack一样 都是托管的kubernetes服务参照：创立 AWS EKS 集群 创立EKS相干IAM 受权创立 EKS Cluster Role留神：以下操作能够用一个普通用户操作然而要有角色 策略的相干权限在 AWS 控制台，抉择“IAM”，进入 IAM 界面，抉择右边的“角色”，而后在左边点击“创立角色”：依照下图红色箭头进行相干操作，进入 抉择可信实体页面，顺次抉择“AWS 服务”， “EKS”，“EKS - Cluster”后，点击“下一步”：在增加 权限页面，“AmazonEKSClusterPolicy”曾经主动增加，所以能够间接点击“下一步”增加 角色 名称“EksClusterRole”后，其余默认，点击“创立角色”：创立实现点击角色- EksClusterRole”，查看已绑定AmazonEKSClusterPolicy权限策略：阐明：此 policy 为 EKS 集群，提供运行必要的权限，比方操作 EC2，主动扩大等等。角色名称能够自定义名称！ 创立 EKS Node Role办法根本与创立 Cluser Role 基本相同，依照下图选项操作：在增加权限页面中，顺次搜寻勾选以下三个 policy，而后点击“下一步” AmazonEC2ContainerRegistryReadOnlyAmazonEKSWorkerNodePolicyAmazonEKS_CNI_Policy输出角色名称EKSnoderole创立角色：创立实现点击角色- EKSnoderole”，查看已绑定的权限策略如下：留神AmazonEBSCSIDriverPolicy 我也加了进来，EBS绑定目测会须要到的 创立eks集群进入eks治理控制台All services 搜寻EKS关键词,点击进入EKS治理控制台： ...

云上大数据的 Kubernetes 技术路线以后，大数据与机器学习畛域颇为关注存储与计算拆散架构，逐步向云原生演进。以Spark 为例，云下或自有服务器能够抉择 Hadoop 调度反对 Spark，云上的 Spark 则会思考如何充沛享有公共云的弹性资源、运维管控和存储服务等，并且业界也涌现了不少 Spark on Kubernetes 的优良实际。 大数据云原生化面临的挑战存储和计算拆散的架构，同时又带来挑战，例如：怎么构建以阿里云对象存储 OSS 为底座的 HDFS 文件系统？须要齐全兼容现有的 HDFS，还要实现在性能对标 HDFS的同时降低成本；计算引擎 shuffle 数据存算拆散，又要思考如何解决 ACK 混合异构机型的反对问题，以及业界十分关注如何反对 Spark 动静资源。 引入 Kubernetes 之后， 如何调度优化性能瓶颈？性能对标 Yarn、实现多级队列治理。还有，如何借助 K8s，编排组织各种业务的波峰波谷，实现错峰调度？等等。 通过阿里云容器服务 ACK 运行开源大数据工作，将以集群为核心的视角切换成以作业为核心视角，还能够实现在线业务、AI、大数据对立接入 ACK 集群，错峰调度，离线在线混部，晋升机器利用率。并且，实现了运维入口、运维工具链、监控体系的三重对立。此外，还反对多版本，如同时运行 Spark2.x 和 Spark 3.x 工作。 EMR on ACK 的架构与劣势12月，阿里云 EMR 2.0 正式公布，从平台体验、数据开发、资源状态、剖析场景等方面实现全面翻新。其中在资源状态侧，EMR 能够部署在阿里云容器服务 ACK 平台， 缩小对底层集群资源的运维投入，以便于用户更加专一大数据工作自身。 EMR on ACK 为用户提供了全新的构建大数据平台的形式，用户能够将开源大数据服务部署在阿里云容器服务（ACK）上。利用 ACK 在服务部署和对高性能可伸缩的容器利用治理的能力劣势，用户只须要专一在大数据作业自身。用户能够便捷地将 Spark、Presto、Flink 作业执行在 ACK 集群上，100%兼容开源，性能优于开源。 EMR on ACK 架构如下 轻量化管控，对接已有数据平台通过数据开发集群/调度平台提交到不同的执行平台错峰调度，依据业务顶峰低峰策略调整云原生数据湖架构，ACK 弹性扩缩容能力强ACK 治理异构机型集群，灵活性好EMR on ACK 具备以下劣势Remote Shuffle Service 提供两头 shuffle 数据的存储计算拆散计划能够使计算节点无需本地盘和云盘反对关上 Spark 动静资源性能，Spark-25299终极计划JindoFS 针对 OSS 存储提供湖减速解决方案Block 模式1TB TPCDS 场景下有15%以上的性能晋升调度层面反对 Scheduler Framework V2调度性能比社区晋升3x以上提供多级队列治理引擎能力加强10TB TPCDS Benchmark 场景下，EMR Spark比社区有3x性能晋升Hudi、DeltaLake 比社区性能性能加强残缺的错峰调度计划国内出名广告营销服务商汇量科技已应用 EMR 产品4年。在业务快速增长的大好形势下，汇量科技面临越来越多的困扰：如数据起源简单、数据量大、数据维度多、实时经营业务秒级数据新鲜度需要等业务需要；本次降级后，汇量科技在素材平台、热力引擎等业务的大数据平台搭建上，数据同步和及查问效率有数倍晋升，零碎稳定性显著晋升，未再呈现之前cpu、mem、io负载低等状况。 ...

二进制装置Kubernetes（k8s） v1.26.1 IPv4/IPv6双栈 可脱离互联网https://github.com/cby-chen/Kubernetes 开源不易，帮忙点个star，谢谢了 介绍kubernetes（k8s）二进制高可用装置部署，反对IPv4+IPv6双栈。 我应用IPV6的目标是在公网进行拜访，所以我配置了IPV6动态地址。 若您没有IPV6环境，或者不想应用IPv6，不对主机进行配置IPv6地址即可。 不配置IPV6，不影响后续，不过集群仍旧是反对IPv6的。为前期留有扩大可能性。 若不要IPv6 ，不给网卡配置IPv6即可，不要对IPv6相干配置删除或操作，否则会出问题。 强烈建议在Github上查看文档 ！！！！！！Github出问题会更新文档，并且后续尽可能第一工夫更新新版本文档 ！！！手动我的项目地址：https://github.com/cby-chen/K...1.环境主机名称IP地址阐明软件 192.168.1.60外网节点下载各种所需安装包Master013.7.191.61master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxMaster023.7.191.62master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxMaster033.7.191.63master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalived、nginxNode013.7.191.64node节点kubelet、kube-proxy、nfs-client、nginxNode023.7.191.65node节点kubelet、kube-proxy、nfs-client、nginx 3.7.191.66VIP 软件版本kernel5.4.231CentOS 8v8、 v7、Ubuntukube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxyv1.26.1etcdv3.5.7containerdv1.6.16dockerv20.10.23cfsslv1.6.3cniv1.2.0crictlv1.26.0haproxyv1.8.27keepalivedv2.1.5网段 物理主机：192.168.1.0/24 service：10.96.0.0/12 pod：172.16.0.0/12 安装包曾经整顿好：https://github.com/cby-chen/K... 1.1.k8s根底零碎环境配置1.2.配置IPssh root@3.7.191.245 "nmcli con mod eth0 ipv4.addresses 3.7.191.61/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@3.7.191.247 "nmcli con mod eth0 ipv4.addresses 3.7.191.62/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@3.7.191.244 "nmcli con mod eth0 ipv4.addresses 3.7.191.63/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@3.7.191.241 "nmcli con mod eth0 ipv4.addresses 3.7.191.64/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"ssh root@3.7.191.246 "nmcli con mod eth0 ipv4.addresses 3.7.191.65/24; nmcli con mod eth0 ipv4.gateway 3.7.191.1; nmcli con mod eth0 ipv4.method manual; nmcli con mod eth0 ipv4.dns "8.8.8.8"; nmcli con up eth0"# 没有IPv6抉择不配置即可ssh root@3.7.191.61 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::10; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@3.7.191.62 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::20; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@3.7.191.63 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::30; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@3.7.191.64 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::40; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"ssh root@3.7.191.65 "nmcli con mod eth0 ipv6.addresses fc00:43f4:1eea:1::50; nmcli con mod eth0 ipv6.gateway fc00:43f4:1eea:1::1; nmcli con mod eth0 ipv6.method manual; nmcli con mod eth0 ipv6.dns "2400:3200::1"; nmcli con up eth0"# 查看网卡配置[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=EthernetPROXY_METHOD=noneBROWSER_ONLY=noBOOTPROTO=noneDEFROUTE=yesIPV4_FAILURE_FATAL=noIPV6INIT=yesIPV6_AUTOCONF=noIPV6_DEFROUTE=yesIPV6_FAILURE_FATAL=noIPV6_ADDR_GEN_MODE=stable-privacyNAME=eth0UUID=424fd260-c480-4899-97e6-6fc9722031e8DEVICE=eth0ONBOOT=yesIPADDR=3.7.191.61PREFIX=24GATEWAY=192.168.8.1DNS1=8.8.8.8IPV6ADDR=fc00:43f4:1eea:1::10/128IPV6_DEFAULTGW=fc00:43f4:1eea:1::1DNS2=2400:3200::1[root@localhost ~]# 1.3.设置主机名hostnamectl set-hostname k8s-master01hostnamectl set-hostname k8s-master02hostnamectl set-hostname k8s-master03hostnamectl set-hostname k8s-node01hostnamectl set-hostname k8s-node021.4.配置yum源# 对于 Ubuntused -i 's/cn.archive.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list# 对于 CentOS 7sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.tuna.tsinghua.edu.cn|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于 CentOS 8sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org/$contentdir|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于公有仓库sed -e 's|^mirrorlist=|#mirrorlist=|g' -e 's|^#baseurl=http://mirror.centos.org/\$contentdir|baseurl=http://192.168.1.123/centos|g' -i.bak /etc/yum.repos.d/CentOS-*.repo1.5.装置一些必备工具# 对于 Ubuntuapt update && apt upgrade -y && apt install -y wget psmisc vim net-tools nfs-kernel-server telnet lvm2 git tar curl# 对于 CentOS 7yum update -y && yum -y install wget psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git tar curl# 对于 CentOS 8yum update -y && yum -y install wget psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git network-scripts tar curl1.5.1 下载离线所需文件在互联网服务器上安装一个截然不同的零碎进行下载所需包 ...

背景：数据库根本为myql,数量不是很多，过来始终默认开启了防火墙模式通过公司固定IP,近程拜访操作mysql。疫情起因，一些小伙伴不喜爱近程通过公司的网络去连贯mysql，频繁增加防火墙操作。并且对数据库的操作及其不标准，没有拜访操作的日志，也没有各种审核。尽管每次操作数据库前会对数据库进行备份。然而这样的平安操作隐患还是很重大的。在此背景下发现还是须要一款mysql审计平台，规范化数据库的操作。长年混迹于github的我搜寻关键词 mysql 审计找到了 Yearning，当然了能够更不便的在gitee的仓库去看！向下滑README.md找到官网or Install 装置及应用日志（貌似其实都跳转到官网了）跳转到官网页面点击指南有二进制包 and docker kubernetes的装置形式，集体是习惯all in kubernetes就抉择kubernetes的装置形式了！ Kubernetes搭建Yearning注：参照官网文档操作：https://next.yearning.io/guide/cloud.html。 前提：mysql 版本必须为5.7及以上版本(8.0及以上请将sql_mode 设置为空)并已当时自行装置结束且创立 Yearning 库,字符集应为 UTF8mb4 (仅 Yearning 所需 mysql 版本)咱的数据库间接用的腾讯云的cdb,创立了数据库，并实现了受权！ 创立Namespace创立一个独自的命名空间搭建yearning,当然了也能够在其余已有的命名空间搭建。齐全能够依据集体需要爱好 kubectl create ns yearning创立Secret注：这里手贱点开了，来自知乎的连贯，依照知乎的文档跑了一遍，顺便给大家加深一下印象 对应配置应用base64加密echo -n 'addr' | base64 #数据库地址包含端口echo -n 'user' | base64 #数据库用户名echo -n 'pass' | base64 #数据库明码echo -n 'data' | base64 #yearning对应数据库名创立secret.yaml并创立secret密钥cat secret apiVersion: v1kind: Secretmetadata: name: db-conf namespace: yearningtype: Opaque # 应用的是generic类型data: # 这里配置的是数据库的相干信息，应用base64加密输出： # echo -n 'xxxx' | base64 addr: xxxxxxxxxxxxxx= user: exxxxxx= pass: xxxxxxx== data: xxxxxx=kubectl apply -f secret.yamlkubectl get secret -n yearning ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 BuildKit v0.11 公布BuildKit 我以前有很多篇文章中都有介绍过了。它是 Docker 的下一代构建引擎，目前在 Docker Desktop 中曾经默认启用，在 Docker 的下一个版本 v23.0 中也会默认启用，对 Docker 中构建引擎感兴趣的小伙伴能够查看我之前的 《万字长文：彻底搞懂容器镜像构建 | MoeLove》。 同时它也能够作为独立的镜像构建工具应用，很多人在将 Kubernetes 集群中的容器运行时从 Docker 替换为 containerd 后，想要寻找新的镜像构建工具，我举荐能够尝试下 BuildKit。 BuildKit 的倒退还是很不错的，目前曾经有 6.3K 的 star。本次公布的 v0.11 中有很多值得关注的内容。 内置的 Dockerfile 前端降级到了 v1.5能够为构建后果生成 SBOM ，以便看到其相干的依赖；能够为构建后果设置 OCI annotations 了，并将其导出为 images;新的 Build History API 容许监听构建开始和实现，以及构建过程的事件；新的 remote cache: Azure Blob Storage 和 S3;反对了 Nydus 格局；更多对于此版本的变更能够查看其 ReleaseNote OPA v0.48.0 公布Open Policy Agent 我在之前的文章 《Open Policy Agent (OPA) 入门实际 | MoeLove》进行过介绍，感兴趣的小伙伴能够看看。 ...

构造 简介最开始容器我的项目有很多公司在做像 Google 和其余厂商,然而就 docker 的容器我的项目最终成活下来, docker 自从对立了容器畛域,然而因为过垄断, docker 迫于压力由Google , CoreOS , Redhat成立一个中立基金,，docker当年的被拆分出了几个标准化的模块 docker-client ,dockerd,containerd,docker-shim,runc 等,本人的容器运行时LibContainer捐出，改名为RunC. 并制订了一套镜像和容器的规范和标准( OCI ).因为 OCI 的成立.让其余公司能够不依赖与 docker 来实现本人的docker 运行时。 docker-cli: docker的前端，提供docker 命令，如docker run 、docker build等dockerd(docker daemon)：docker的服务端，其实就是docker-client的后盾containerd：容器服务，这也是docker的外围组件，负责容器的增删改等操作，这里containerd之所以作为一个独自的服务，而没有和dockerd集成到一块，是为了让其余的我的项目能够定义本人的客户端，比方kubernetes通过CRI客户端来拜访containerdrunc：是一个命令行工具端，他依据oci（凋谢容器组织）的规范来创立和运行容器，containerd会调用runc命令来运行镜像。 container咱们外围的是 container, 最新k8s 绕过dockerd 间接调用 container 缩小了一层, container 次要负责的是拉取和解压镜像, 上传和制作镜像是由 dockerd来负责的. 所以docker 的 container 与 k8s 的 container 是同一个.所以实践上,只有满足 OCI 的标准.无论是什么工具编译的镜像都能被 container 拉取、编译与运行。containerd是一个工业级别规范的容器运行时，它强调简略性、健壮性和可移植性，简直囊括了单机运行一个容器运行时所须要的所有：执行、散发、监控、网络、构建、日志等。次要作用是：1）、治理容器的生命周期（从创立容器到销毁容器）2）、拉取/推送容器镜像3）、存储管理（治理镜像及容器数据的存储）4）、调用runC运行容器（与runC等容器运行时交互）5）、治理容器网络接口及网络dockerd理论实在调用的还是containerd的api接口，containerd是dockerd和runC之间的一个两头交换组件。 docker 镜像和 containerd 镜像通用。但组织形式和寄存目录不同，导致docker与ctr命令不通用，各自治理本人的镜像和容器。此外k8s还有客户端命令crictl，用法与docker基本相同，可crictl -h查看用法。 参考资料 docker 与 k8s 的爱恨情仇k8s 弃用docker--Docker、containerd的关系K8s 集群内 containerd 、 docker 的区别CRI (container runtime interface)

1. 应用yaml文件创建资源对象❝ 每种资源的apiVersion和kind可通过 kubectl api-resources 命令进行查看 ❞ tantianran@test-b-k8s-master:~$ kubectl api-resources | grep Deploymentdeployments                       deploy       apps/v1                                true         Deploymenttantianran@test-b-k8s-master:~$ goweb-demo.yaml apiVersion: v1kind: Namespacemetadata:  name: test-a---apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 10  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3---apiVersion: v1kind: Servicemetadata:  name: goweb-demo  namespace: test-aspec:  ports:  - port: 80    protocol: TCP    targetPort: 8090  selector:    app: goweb-demo  type: NodePort❝ 对于标签的次要作用：标记、过滤、关联(次要体现在deployment、pod、service，3者标签保持一致)，可设定多个标签，倡议设定至多2个标签，一个为我的项目标签，一个为利用标签。 ❞ 对于创立、更新和删除的命令# 只用于创立kubectl create -f xxx.yaml# 创立和更新（须要yaml文件里的字段反对更新，并不是所有字段都反对更新）kubectl apply -f xxx.yaml# 卸载kubectl delete -f xxx.yaml2. 编写yaml的套路分享套路1：能够间接手写，但容易出错套路2：参考官网示例，而后改成本人的套路3：通过命令行来获取，也是有2个形式，一是利用尝试运行（--dry-run）的机制再配合-o来输入一个yaml文件），二是通过get来失去yaml文件，失去yaml文件后再自行批改上面演示通过create来失去yaml # 在kubectl级别上进行验证kubectl create deployment web1 --image=nginx --replicas=5 --dry-run=client# 指的是提交到apiserver进行验证kubectl create deployment web1 --image=nginx --replicas=5 --dry-run=server# 上面来一个deployment的例子，失去其余资源的yaml也是这个套路tantianran@test-b-k8s-master:~$ kubectl create deployment web1 --image=nginx --replicas=5 --dry-run=client -o yamlapiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    app: web1  name: web1spec:  replicas: 5  selector:    matchLabels:      app: web1  strategy: {}  template:    metadata:      creationTimestamp: null      labels:        app: web1    spec:      containers:      - image: nginx        name: nginx        resources: {}status: {}# 还能够配合重定向输入到yaml文件kubectl create deployment web1 --image=nginx --replicas=5 --dry-run=client -o yaml > test.yaml上面演示通过get命令来失去yaml文件，应用-o来指定yaml的格局输入，其余资源也是这个套路 kubectl get pods -n test-a -o yaml编写yaml的时候，字段名太多记不住或者想不起来怎么办？能够应用explain来查看字段层级 # 找第一级kubectl explain deployment# 找第二级kubectl explain deployment.spec# 再比方查pod相干的kubectl explain pods.spec.containers3. 利用生命周期治理❝ deployment是最罕用的k8s工作负载控制器（Workload Controllers），是k8s的一个抽象概念，用于更高级档次对象，部署和治理Pod，卡控制器还有DaemonSet、StatefulSet等。 ❞ 3.1 Deployment「Deployment次要性能：」 治理Pod和ReplicaSet具备上线部署、正本设定、滚动降级、回滚等性能「Deployment利用场景：」 网站、API、微服务 「Pod与控制器的关系图：」 「利用生命周期治理流程：」 3.2 利用部署的根本流程❝ 部署->降级->回滚->删除 ❞ 3.2.1 部署# 举荐的形式kubectl apply -f xxx.yaml# 或者kubectl create deployment web --image=nginx --replicas=3在本示例中，部署的是我本人应用go语言写的一个很简略的web demo 拜访一下看看 3.2.2 降级❝ 所谓的降级，其实就是更新镜像，且有3种形式，主动触发滚动降级 ❞ # 形式1：间接批改yaml文件中的镜像，而后applykubectl apply -f xxx.yaml# 形式2：应用命令设置deployment应用的镜像kubectl set image deployment/web nginx=nginx1.17# 应用零碎编辑器关上进行编辑kubectl edit deployment「公布形式有3种：」 滚动公布、蓝绿公布、灰度公布（金丝雀、A/B测试、冒烟测试。灰度公布是最简单的形式，公布的形式是为了防止上线后呈现的问题。） 「K8S默认是滚动降级：」 滚动公布是指每次只降级一个或多个服务，降级实现后退出生产环境，一直执行这个过程，直到集群中的全副旧版本升级新版本。 「滚动降级在k8s中的实现：」 它是通过1个Deployment和2个ReplicaSet来实现的，滚动更新一次只降级一小部分pod，胜利后，再降级一部分pod，最终实现所有Pod降级，整个过程始终有Pod在运行，从而保障了业务的连续性。 「ReplicaSet：」 正本集，次要保护Pod正本数量，一直比照以后Pod数量于冀望Pod数量。「ReplicaSet用处：」 Deployment每次公布都会创立一个RS（ReplicaSet的缩写）作为记录，用于实现滚动降级和回滚 能够查看deployment的详情，详情里其实是记录了降级的过程 kubectl get deployment -n test-akubectl describe deployment goweb-demo -n test-a查看ReplicaSet（RS）记录（首次的部署和后续降级都会新创建一个RS，降级多少次就会创立多少个） tantianran@test-b-k8s-master:~$ kubectl get rs -n test-aNAME                    DESIRED   CURRENT   READY   AGEgoweb-demo-6fbb74fdbb   0         0         0       41mgoweb-demo-7b6649f789   20        20        20      32m # 此处DESIRED和CURRENT以及READY字段有值的话，示意是以后正在应用的RSgoweb-demo-8665796599   0         0         0       24h# 查看正在应用的RS的详情kubectl describe rs goweb-demo-7b6649f789 -n test-a❝ 留神：降级后，旧的RS会被保留，次要用于前面回滚应用，且每次只能有一个RS在应用。 ❞ 「当新版的镜像曾经做好须要滚动更新的时候，那就要批改deployment中指定的镜像，批改的形式有2种：应用命令和间接批改yaml文件」形式1：应用命令 # 命令格局kubectl set image deployment <DeploymentName> <ContainerName>=<Image> -n <Namespace># 例子# step 1：获取deploymentkubectl get deployment -n test-a# step 2：查看deployment详情kubectl describe deployment goweb-demo -n test-a...Pod Template:  Labels:  app=goweb-demo  Containers:   goweb-demo: # 容器名字    Image:        192.168.11.247/web-demo/goweb-demo:20221229v3 # 镜像    Port:         <none>    Host Port:    <none>    Environment:  <none>    Mounts:       <none>  Volumes:        <none>...# step 3：设置deployment的镜像kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v3 -n test-a形式2：间接批改yaml（举荐） apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo # deployment名称  namespace: test-aspec:  replicas: 50 # 正本  selector:    matchLabels:      app: goweb-demo  template:    metadata:      labels:        app: goweb-demo    spec:      containers:      - name: goweb-demo        image: 192.168.11.247/web-demo/goweb-demo:20221229v3 # 镜像「程度扩缩容，也就是批改正本的数量，也有2种形式，命令和批改yaml文件」形式1：命令 kubectl scale deployment goweb-demo --replicas=5 -n test-a形式2：批改yaml文件中的replicas参数，再apply apiVersion: apps/v1kind: Deploymentmetadata:  name: goweb-demo  namespace: test-aspec:  replicas: 5 #批改正本数量......3.2.3 回滚❝ 当利用公布失败，须要回滚时。 ❞ 查看发过有哪些版本 # 查看历史kubectl rollout history deployment -n test-adeployment.apps/goweb-demo REVISION  CHANGE-CAUSE4         <none>6         <none>8         <none>9         <none># 通过命令批改deployment的镜像进行降级时，前面加--record参数，再查看历史后就会记录这条命令kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v2 -n test-a --recordFlag --record has been deprecated, --record will be removed in the futuredeployment.apps/goweb-demo image updated# 下面加了--record参数，再查看历史，能够看到记录的这条命令kubectl rollout history deployment -n test-adeployment.apps/goweb-demo REVISION  CHANGE-CAUSE4         <none>6         <none>9         <none>10        kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v2 --namespace=test-a --record=true # 就是这里查看版本号和RS的对应关系，以及和镜像的对应关系 # 查看RStantianran@test-b-k8s-master:~$ kubectl get rs -n test-aNAME                    DESIRED   CURRENT   READY   AGEgoweb-demo-6fbb74fdbb   0         0         0       5h15mgoweb-demo-7b6649f789   0         0         0       5h6mgoweb-demo-8665796599   0         0         0       29hgoweb-demo-b98869456    5         5         5       4h22m # 以后应用的RS# 查看以后应用的RS详情tantianran@test-b-k8s-master:~$ kubectl describe rs goweb-demo-b98869456 -n test-a...Annotations:    deployment.kubernetes.io/desired-replicas: 5                deployment.kubernetes.io/max-replicas: 7                deployment.kubernetes.io/revision: 11 # 这个11就是以后版本号                deployment.kubernetes.io/revision-history: 7,9 # 历史版本                kubernetes.io/change-cause:                  kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v3 --namespace=test-a --record=trueControlled By:  Deployment/goweb-demoReplicas:       5 current / 5 desiredPods Status:    5 Running / 0 Waiting / 0 Succeeded / 0 FailedPod Template:  Labels:  app=goweb-demo           pod-template-hash=b98869456  Containers:   goweb-demo:    Image:        192.168.11.247/web-demo/goweb-demo:20221229v3 # 应用的镜像    Port:         <none>    Host Port:    <none>...# 查看历史版本tantianran@test-b-k8s-master:~$ kubectl rollout history deployment -n test-adeployment.apps/goweb-demo REVISION  CHANGE-CAUSE4         <none>6         <none>10        kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v2 --namespace=test-a --record=true11        kubectl set image deployment goweb-demo goweb-demo=192.168.11.247/web-demo/goweb-demo:20221229v3 --namespace=test-a --record=true # 这个REVISION是11通过过滤来获取到公布版本和对应的镜像 # 过滤revision和Imagetantianran@test-b-k8s-master:~$ kubectl describe $(kubectl get rs -o name -n test-a | grep "goweb-") -n test-a | grep -E "revision:|Image:"                deployment.kubernetes.io/revision: 4    Image:        192.168.11.247/web-demo/goweb-demo:20221229v1                deployment.kubernetes.io/revision: 10    Image:        192.168.11.247/web-demo/goweb-demo:20221229v2                deployment.kubernetes.io/revision: 6    Image:        192.168.11.247/web-demo/goweb-demo:20221228v1                deployment.kubernetes.io/revision: 11    Image:        192.168.11.247/web-demo/goweb-demo:20221229v3tantianran@test-b-k8s-master:~$ # 过滤更具体的，过滤revision、Image、Name、Replicastantianran@test-b-k8s-master:~$ kubectl describe $(kubectl get rs -o name -n test-a | grep "goweb-") -n test-a | grep -E "revision:|Image:|Name:|Replicas:"Name:           goweb-demo-6fbb74fdbb                deployment.kubernetes.io/revision: 4Replicas:       0 current / 0 desired    Image:        192.168.11.247/web-demo/goweb-demo:20221229v1Name:           goweb-demo-7b6649f789                deployment.kubernetes.io/revision: 10Replicas:       0 current / 0 desired    Image:        192.168.11.247/web-demo/goweb-demo:20221229v2Name:           goweb-demo-8665796599                deployment.kubernetes.io/revision: 6Replicas:       0 current / 0 desired    Image:        192.168.11.247/web-demo/goweb-demo:20221228v1Name:           goweb-demo-b98869456                deployment.kubernetes.io/revision: 11Replicas:       5 current / 5 desired    Image:        192.168.11.247/web-demo/goweb-demo:20221229v3只回滚到上一个版本 tantianran@test-b-k8s-master:~$ kubectl rollout undo deployment goweb-demo -n test-adeployment.apps/goweb-demo rolled back回滚到指定的历史版本 # 查看以后正在应用哪个版本tantianran@test-b-k8s-master:~$ kubectl describe $(kubectl get rs -o name -n test-a | grep "goweb-") -n test-a | grep -E "revision:|Replicas:"                deployment.kubernetes.io/revision: 4Replicas:       0 current / 0 desired                deployment.kubernetes.io/revision: 14 # 以后正在应用的版本，版本号14，且正本是5Replicas:       5 current / 5 desired # 正本数量                deployment.kubernetes.io/revision: 6Replicas:       0 current / 0 desired                deployment.kubernetes.io/revision: 13Replicas:       0 current / 0 desired# 假如要回滚到最后的版本，也就是版本号是4tantianran@test-b-k8s-master:~$ kubectl rollout undo deployment goweb-demo --to-revision=4 -n test-adeployment.apps/goweb-demo rolled backtantianran@test-b-k8s-master:~$ 3.2.4 删除（当我的项目须要下线时）# 如果该我的项目是间接编写yaml的，可这样删除（下线）kubectl delete -f goweb-demo.yaml# 如果该项目标命名空间、deployment、service是用命令的，那就须要手动删除下线kubectl delete deployment goweb-demo -n test-akubectl delete svc goweb-demo -n test-akubectl delete ns test-a最初❝ ...

️URL: https://crossplane.io/ Description: 将云基础架构和服务组成自定义平台 API 简介在 11 月的 KCD 上海现场，听了一场阿里云的工程师对于他们本人的多云基础架构管理工具的介绍，前边的引言局部有介绍到 Terraform，还有另一款竞品就是 Crossplane，而且示意 Crossplane 在通用性 API 等方面做得比 Terraform 更好，阿里云的也参考了其架构和实现。就让我很感兴趣，同时在 2019 年应用 OpenShift 4 的时候也在其 OperatorHub 里有发现 Crossplane，过后感觉其 Logo 很有辨识度便始终有印象。所以这次抽了个周末专门体验了一下，看它是否当得起这个题目。开始~ Crossplane（跨立体，意思是能够逾越多个 私有云平台） 是一个开源的 Kubernetes 插件，它容许平台团队组装来自多个供应商的基础设施，并向应用程序团队公开更高级别的自助服务 api，而不须要编写任何代码。 愿景为更凋谢的云提供能源 构建 Crossplane 是为了帮忙组织构建他们的云，就像云供应商构建他们的云一样——通过一个管制立体。Crossplane 是一个 CNCF 我的项目，它扩大了 Kubernetes API 来治理和组合基础设施。操作人员能够在 Crossplane 生成的自定义 API 线后封装策略、权限和其余防护措施，而应用程序开发人员无需成为基础设施专家就能够从 API 自助服务。 对标产品Terraform 价值以下是它的价值所在： 应用 kubectl 提供和治理云基础设施和服务 Crossplane 扩大您的 Kubernetes 集群，为您提供任何基础设施或托管服务的 crd。将这些细粒度资源组合成更高级别的形象，这些形象能够应用您喜爱的工具，也能够和曾经集成到集群中的现有流程进行版本治理、治理、部署和应用。 在 Crossplane 中，每个人都有本人的基础设施 Crossplane 反对来自所有次要云提供商的基础设施，社区也在一直开发新的提供商。目前反对以下支流私有云供应商： 为你的应用程序提供简化的基础架构形象 在 CRDs Crossplane 提供的根底上构建您本人的外部基础架构形象。您的自定义 api 能够蕴含策略护栏，暗藏基础设施的复杂性，并确保应用程序能够平安地应用它。 ...

作者：京东物流 杨建民一、微服务架构起源单体架构：能够了解为次要业务逻辑模块（咱们编写的代码模块，不包含独立的中间件）运行在一个过程中的利用，最典型的是运行在一个Tomcat容器中，位于一个过程里。单体架构益处是技术门槛低、编程工作量少、开发简略快捷、调试不便、环境容易搭建、容易公布部署及降级，开发运维等总体老本很低、见效快。其毛病也显著： （1）单体利用零碎比拟收缩与臃肿，耦合度高，导致进行可继续开发和运维很艰难。 （2）单体利用难以承载迅速增长的用户申请和需要。 基于Spring Framework的单体利用架构图 分布式架构核心思想是把一个繁多过程的零碎拆分为性能上相互协作又能独立部署在多个服务器上的一组过程，这样一来，零碎能够依据理论业务须要，通过以下两种形式实现某些独立组件的扩容，晋升吞吐量。 程度扩大：通过减少服务器数量进行扩容垂直扩大：给零碎中的某些非凡业务调配更好的机器，提供更多资源，从而晋升这些业务的零碎负载和吞吐分布式架构是将一个宏大的单体利用拆分成多个独立运行的过程，这些过程能通过某种形式实现近程调用，因而，分布式架构要解决的第一个核心技术问题就是独立过程之间的近程通信。该问题的最早答案就是RPC技术（Remote Procedure Call），一种典型的微服务架构平台的构造示意图如下： 大家比拟熟知的微服务架构框架有Dubbo与Spring Cloud，之后比拟胜利的微服务架构根本都和容器技术挂钩了，其中最胜利的、影响最大的当属Kubernetes平台了，与之类似的还有Docker公司推出的Docker Swarm(在2017年底，Docker Swarm也反对Kubernetes了)。 对于微服务架构的劣势因为文章篇幅无限，不再开展，但任何技术都存在两面性，微服务架构具备肯定的复杂性，如开发者必须把握某种RPC技术，并且必须通过写代码来解决RPC速度过慢或者调用失败等简单问题。为了解决微服务带来的编程复杂性问题，一种新的架构设计思维呈现了，这就是Service Mesh，Service Mesh定义是：一个用于解决服务于服务之间通信（调用）的简单的基础架构设施。从实质上看，Service Mesh是一组网络代理程序组成的服务网络，这些代理会与用户程序部署在一起，充当服务代理，这种代理起初在Google的Istio产品架构中称为“Sidecar”，其实就是采纳了代理模式的思维去解决代码入侵及反复编码的问题，。下图给出了Service Mesh最简略的架构图。Servie Mesh同样不是本次的配角，感兴趣的小伙伴可自行学习。 二、初识k8s官网原文是：K8s is an abbreviation derived by replacing the 8 letters “ubernete” with 8.k8s全称kubernetes，名字来源于希腊语，意思为“舵手”或“领航员”，它是第一代容器技术的微服务架构（第二代是Servie Mesh）。 Kubernetes最后源于谷歌外部的Borg，提供了面向利用的容器集群部署和管理系统。Kubernetes 的指标旨在打消编排物理/虚构计算，网络和存储基础设施的累赘，并使应用程序运营商和开发人员齐全将重点放在以容器为核心的原语上进行自助经营。Kubernetes 也提供稳固、兼容的根底（平台），用于构建定制化的workflows 和更高级的自动化工作。 Kubernetes 具备欠缺的集群治理能力，包含多层次的平安防护和准入机制、多租户利用撑持能力、通明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动降级和在线扩容、可扩大的资源主动调度机制、多粒度的资源配额治理能力。 Kubernetes 还提供欠缺的管理工具，涵盖开发、部署测试、运维监控等各个环节。 2.1 k8s架构与组件 Kubernetes次要由以下几个外围组件组成： etcd保留了整个集群的状态；apiserver提供了资源操作的惟一入口，并提供认证、受权、访问控制、API注册和发现等机制；controller manager负责保护集群的状态，比方故障检测、主动扩大、滚动更新等；scheduler负责资源的调度，依照预约的调度策略将Pod调度到相应的机器上；kubelet负责保护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的治理；Container runtime负责镜像治理以及Pod和容器的真正运行（CRI）；kube-proxy负责为Service提供cluster外部的服务发现和负载平衡；2.2 k8s设计理念API设计准则API对象是k8s集群中的治理操作单元。k8s集群零碎每反对一项新性能，引入一项新技术，肯定会新引入对应的API对象，反对对该性能的治理操作。例如正本集Replica Set对应的API对象是RS。 k8s采纳申明式操作，由用户定义yaml，k8s的API负责创立。每个对象都有3大类属性：元数据metadata、标准spec和状态status。元数据是用来标识API对象的，每个对象都至多有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户能够用标签env来标识辨别不同的服务部署环境，别离用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。标准形容了用户冀望k8s集群中的分布式系统达到的现实状态（Desired State），例如用户能够通过复制控制器Replication Controller设置冀望的Pod正本数为3；status形容了零碎理论以后达到的状态（Status），例如零碎以后理论的Pod正本数为2；那么复制控制器以后的程序逻辑就是主动启动新的Pod，争取达到正本数为3。 apiVersion: apps/v1beta1kind: Deploymentmetadata: name: nginx-deploymentspec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80apiVersion - 创建对象的Kubernetes API 版本kind - 要创立什么样的对象？metadata- 具备惟一标示对象的数据，包含 name（字符串）、UID和Namespace（可选项）应用上述.yaml文件创建Deployment，是通过在kubectl中应用kubectl create命令来实现。将该.yaml文件作为参数传递。如下例子： ...

SKS 是什么？SKS 全称 SMTX Kubernetes Service ， 是 SmartX 公司退出的容器 IAAS 平台，如下图所示，在基于 SMTX OS 的平台上，能够通过 SKS 创立 Kubernetes Cluster 并进行治理。 SKS 的装置和治理依赖 管理工具CloudTower。 SKS 装置配套视频：https://www.bilibili.com/video/BV1pd4y1L77D/?vd_source=33b17c80f501bc5db46f7dcb22fc96cb 装置 CloudTower现阶段 CloudTower 反对 SKS 的版本还是测试版，次要包含 CloudTower 安装文件、SKS 部署文件、镜像仓库部署文件和节点相干文件。其中节点相干文件即 VM-Kubernetes Node 装置模板，相似于Tanzu 的[photon-ova](https://wp-content.vmware.com/v2/latest/ob-20611023-photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable/photon-ova.ovf)，也是基于不同Kubernetes 版本的。 系统配置配置等级CloudTower 治理能⼒CloudTower 所在的虚拟机占⽤的系统资源低配10 个集群/100 台主机/1000 个虚拟机4 核 vCPU/8 GiB 内存/100 GiB 存储空间⾼配100 个集群/1000 台主机/10000 个虚拟机8 核 vCPU/16 GiB 内存/400 GiB 存储空间选用高配，CloudTower 基于 CentOS，装置过程也相似，不同的是挂载装置 ISO 文件启动后，VM 会主动装置。 虚拟机 Guest OS 的默认⽤⼾名 smartx，初始密码 HC!r0cks，进入零碎后执行以下命令实现装置，在此之前确保 IP 地址配置胜利： ...

Kucernetes,很多人叫它“K8s”。第一次接触到这个概念，是要旁边的数据专家博士写一个shell用于给所有部署在k8s上的服务的deployment文件增加一条annotations，这条annotation是增加另一种存储log的路径。 Kucernetes Doc

重启策略 Always：当容器终止退出，总是重启容器，默认策略OnFailure：当容器异样退出（退出状态码非0）时，才重启容器Never：当容器终止退出，从不重启容器查看pod的重启策略 # 查看pod，以yaml格局输入kubectl get pods test-pod1 -o yaml# 找到restartPolicy字段，就是重启策略restartPolicy: Always健康检查有以下3种类型： 健康检查是查看容器外面的服务是否失常livenessProbe（存活探测）：如果查看失败，将杀死容器，依据pod的restartPolicy来操作。readinessProbe（就绪探测）：如果查看失败，k8s会把Pod从service endpoints中剔除startupProbe（启动探测）：查看胜利才由存活查看接手，用于爱护慢启动容器反对以下三种查看办法： httpGet：发动HTTP申请，返回200-400范畴状态码为胜利。exec：执行Shell命令返回状态码是0为胜利。tcpSocket：发动TCP Socket建设胜利。案例实战 livenessProbe（存活探针）：应用exec的形式（执行Shell命令返回状态码是0则为胜利）apiVersion: v1kind: Namespacemetadata: name: test-a---apiVersion: apps/v1kind: Deploymentmetadata: name: goweb-demo namespace: test-aspec: replicas: 10 selector: matchLabels: app: goweb-demo template: metadata: labels: app: goweb-demo spec: containers: - name: goweb-demo image: 192.168.11.247/web-demo/goweb-demo:20221229v3 livenessProbe: exec: command: - ls - /opt/goweb-demo/runserver initialDelaySeconds: 5 periodSeconds: 5---apiVersion: v1kind: Servicemetadata: name: goweb-demo namespace: test-aspec: ports: - port: 80 protocol: TCP targetPort: 8090 selector: app: goweb-demo type: NodePortperiodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测，initialDelaySeconds 字段通知 kubelet 在执行第一次探测前应该期待 5 秒，kubelet 在容器内执行命令 ls /opt/goweb-demo/runserver 来进行探测。 如果命令执行胜利并且返回值为 0，kubelet 就会认为这个容器是衰弱存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。验证存活查看的成果 ...

很多小伙伴在学习 mall 电商我的项目时，都会在部署上折腾许久，尽管目前曾经提供了很多种部署形式，比方 在 Linux 上部署 mall 、应用 Docker 或 DockerCompose 部署 mall ，但对于正在学习的咱们都显得比较复杂，须要了解并学习这些容器技术。而本文将应用 Rainbond 部署 mall 电商我的项目，通过 Rainbond 部署 mall 商城我的项目十分不便、简略，让咱们专一于代码，Rainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，轻松的在 Kubernetes 上部署利用并体验 Kubernetes 带来的能力。 本文介绍在 Rainbond 上的两种部署 mall 电商我的项目的形式： 通过 Rainbond 开源利用商店疾速部署 mall从 0 开始部署 mall 我的项目所有服务前提装置可用的 Rainbond 环境，Linux、Mac、Win上均可装置，参阅 Rainbond 疾速装置 通过利用商店疾速部署 mallmall 电商我的项目已公布到 Rainbond 开源利用商店，能够通过开源利用商店一键部署，在 平台治理 -> 利用市场 -> 开源利用商店 中搜寻 mall 并装置。 此时 Rainbond 会主动构建、启动 mall 所有服务，只需期待即可，部署实现后拓扑图如下： 拜访 mall-admin-web 前端我的项目验证部署，默认用户明码：admin / macro123 ...

IOMESH Installation官网文档： Introduction · Documentation 同步发表于集体网站：www.etaon.top 试验拓扑图：也能够再测试的时候是应用一个端口，官网倡议将IOMESH的端口分可，即下图10.234.1.0/24网段： 试验应用裸机，配置如下： 配件型号规格数量备注CPUIntel(R) Xeon(R) Silver 4214R  @ 2.40GHz2节点1、3 Intel(R) Xeon(R) Gold 6226R  @ 2.90GHz1节点2内存256 GB3节点1、2、3SSD1.6 TB NVMe SSD2*3节点1/节点2/节点3HDD2.4 TB SAS4*3节点1/节点2/节点3DOM盘M.2 240GB2节点1/节点2/节点3千兆网卡I3502节点1/节点2/节点3存储网卡10/25G2节点1/节点2/节点3部署IOMesh 至多须要一块 cache disk以及一块 partition disk装置步骤：创立Kubernetes集群采纳Kubernetes 1.24 版本，Runtime为containerd。装置参考Install Kubernetes 1.24 - 路无止境！ (etaon.top) 装置前筹备在所有worker节点执行以下操作。 装置 open-iscsi，ubuntu曾经装置。apt install open-iscsi -y编辑iscsi配置文件sudo sed -i 's/^node.startup = automatic$/node.startup = manual/' /etc/iscsi/iscsid.conf确保 iscsi_tcp 模块已被加载sudo modprobe iscsi_tcpsudo bash -c 'echo iscsi_tcp > /etc/modprobe.d/iscsi-tcp.conf'启动 iscsid 服务systemctl enable --now iscsid离线装置 IOMesh装置文档： ...

这是 Kubernetes 网络学习的第五篇笔记，也是之前打算中的最初一篇。 深刻摸索 Kubernetes 网络模型和网络通信认识一下容器网络接口 CNI源码剖析：从 kubelet、容器运行时看 CNI 的应用从 Flannel 学习 Kubernetes VXLAN 网络Cilium CNI 与 eBPF（本篇）...开始之前说点题外话，间隔上一篇 Flannel CNI 的公布曾经快一个月了。这篇本想趁着势头在去年底实现的，正好在一个月内实现打算的所有内容。但上篇公布后不久，我中招了花了一个多周的工夫才复原。然而，复原后的状态让我有点懵，总感觉很难集中精力，很容易精神涣散。可能靠近网上流传的“脑雾”吧，而且 Cilium 也有点相似一团迷雾。再叠加网络常识的有余，eBPF 也未从涉足，学习的过程中断断续续，我已经一度狐疑这篇会不会流产。 文章中未免会有问题，如果有发现问题或者倡议，望不吝赐教。 背景去年已经写过一篇文章 《应用 Cilium 加强 Kubernetes 网络安全》 接触过 Cilium，借助 Cilium 的网络策略从网络层面对 pod 间的通信进行限度。但过后我未曾深刻其实现原理，对 Kubernetes 网络和 CNI 的理解也不够深刻。这次咱们通过理论的环境来探寻 Cilium 的网络。 这篇文章应用的 Cilium 版本是 v1.12.3，操作系统是 Ubuntu 20.04，内核版本是 5.4.0-91-generic。 Cilium 简介Cilium 是一个开源软件，用于提供、爱护和察看容器工作负载（云原生）之间的网络连接，由革命性的内核技术 eBPF 推动。 eBPF 是什么？Linux 内核始终是实现监控/可观测性、网络和平安性能的现实中央。 不过很多状况下这并非易事，因为这些工作须要批改内核源码或加载内核模块， 最终实现模式是在已有的层层形象之上叠加新的形象。 eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs）， 而无需批改内核源码或者加载内核模块。 将 Linux 内核变成可编程之后，就能基于现有的（而非减少新的）形象层来打造更加智能、 性能更加丰盛的基础设施软件，而不会减少零碎的复杂度，也不会就义执行效率和安全性。 Linux 的内核在网络栈上提供了一组 BPF 钩子，通过这些钩子能够触发 BPF 程序的执行。Cilium datapah 应用这些钩子加载 BPF 程序，创立出更高级的网络结构。 ...

应用 subPath有时，在单个 Pod 中共享卷以供多方应用是很有用的。 volumeMounts.subPath 属性可用于指定所援用的卷内的子门路，而不是其根门路。 上面是一个应用同一共享卷的、内含 LAMP 栈（Linux Apache Mysql PHP）的 Pod 的示例。 HTML 内容被映射到卷的 html 文件夹，数据库将被存储在卷的 mysql 文件夹中： apiVersion: v1kind: Podmetadata: name: my-lamp-sitespec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "rootpasswd" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php:7.0-apache volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persistentVolumeClaim: claimName: my-lamp-site-data对下面的配置进行阐明: volumeMounts 上面的name, 就是调配给这个pod的volume的名字site-data, mysql和php的html别离应用了它的子门路: mysql 和htmlvolumes 对于site-data这个volume, 是通过PVC的模式提供的, PVC的name为: my-lamp-site-data应用带有扩大环境变量的 subPathFEATURE STATE: Kubernetes v1.15 feature-state-beta.txt ...

参考：k8s中hpa应用问题记录HorizontalPodAutoscaler 演练 应用 AverageValue 就是绝对值，应用 Utilization 就是百分比，所以，改成 AverageValue 吧 顺便说一下，文档：Pod 程度主动扩缩 写的真是，只字不提 AverageValue，搞得我认为不存在 AverageValue，只能 Utilization

对于 ACNS龙蜥云原生套件 OpenAnolis Cloud Native Suite（ACNS）是由龙蜥社区云原生 SIG 推出的基于 Kubernetes 发行版本为根底而集成的套件能力，能够提供一键式部署，开箱即用，以及丰盛的云原生根底能力，次要包含： Kubernetes 基于 ACK-D , 作为开源的发行版以及 ACK 的上游，ACK-D 通过大规模的生产的验证，保障了组件的稳定性、可靠性；同时在网络插件上反对 Calico、Hybirdnet，可同时反对网络的 Overlay 与 Underlay，除了 Overlay 满足容器网络的同时，能够部署成 Underlay 模式是使得 POD IP 间接被内部拜访，同时提供比拟好的性能；存储插件上反对本地存储 Open-Local、利用 LVM 提供了灵便的本地磁盘能力，以及共享存储 Minio。Runtime 同时反对 runC、runD 和 Kata，以及 runE (将来版本)，满足各种对共享、隔离以及平安场景下应用。镜像治理上提供了开箱即用的 Nydus + Dragonfly，应用 Nydus 能够在集群外部使镜像按需加载，能够大大提高集群的动静弹性的能力；Dragonfly 则是提供镜像在集群的 P2P 的能力，这两个能力次要面向 Kubernetes 集群提供 Serverless服务，以及动静弹性的场景，AI大数据镜像数据集群内散发的场景等。对于 RainbondRainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，反对治理多个Kubernetes集群，和治理企业应用全生命周期。 ACNS 与 Rainbond 联合龙蜥云原生套件 ACNS提供一键部署集群的能力，Rainbond 提供一键部署利用的能力，Rainbond 与龙蜥云原生套件 ACNS 联合提供一站式的云原生体验： 基础设施：Anolis OS 是 OpenAnolis 社区推出的齐全开源、中立、凋谢的发行版，它反对多计算架构，也面向云端场景优化，兼容 CentOS 软件生态。容器层：龙蜥 ACNS 提供了通过大规模生产验证的 ACK-D 集群，同时也提供了 Kata 平安运行时、Dragonfly 文件散发、Nydus 镜像减速。应用层：Rainbond 提供了利用开发、利用市场、微服务架构、利用交付、利用运维等开箱即用的能力。 ...

先来看看 kubectl top 子命令的 help 信息 ╰─➤ kubectl top --help Display Resource (CPU/Memory) usage. The top command allows you to see the resource consumption for nodes or pods. This command requires Metrics Server to be correctly configured and working on the server.Available Commands: node Display resource (CPU/memory) usage of nodes pod Display resource (CPU/memory) usage of podsUsage: kubectl top [flags] [options]Use "kubectl <command> --help" for more information about a given command.Use "kubectl options" for a list of global command-line options (applies to all commands).通过 kubectl 查看 node 的 CPU、内存使用率 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 这是 2023 年的第一篇『K8S 生态周报』，在上个月的月中之后我因为阳了就进行更新了，始终在涵养身材。生病相干的内容我在上一篇文章 张晋涛：我的 2022 总结 | MoeLove有做介绍。愿大家都留神身材，放弃衰弱。 这篇中的内容同样也蕴含了近一个月中值得关注的内容。 containerd v1.6.15 公布只管 containerd 的 1.7.0-beta.2 也曾经于近期公布，但正式版公布还须要一段时间。当初 containerd 应用最多的还是 v1.6 和 v1.5 这两个次要版本，这次公布的 v1.6.15 中有一个十分要害的变更，是 #7845 - CRI: Fix no CNI info for pod sandbox on restart by dcantah 我次要也是想聊一下这个，从 v1.6.9 开始的最近几个 containerd 版本中都受到了此问题影响。 简略来说就是 containerd 重启后，Sandbox IP 没能保留，最终导致 kubelet 将会重启 Pod （如果重启 kubelet）。 具体景象如下，在 Node 上通过 crictl 工具查看任意未应用 HostNetwork 的 Pod 的 .status.network 字段，能够看到如下后果： ...

明天聊啥昨晚在京东上试着搜寻关键字“Kubernetes Operator 开发进阶”，看到我的书终于上架了，悲喜交集。 （没有老泪纵横。你认为是我没有眼眶潮湿？不，我说的是我没有老！） 这本书破费了我大概半年的心血。半年，没有周末，没有假期。去年的元旦和大年初一都没有劳动，每天三小时，赶稿子。 明天，严肃认真地介绍下这本书吧！ 庄重！庄重。庄重，算了，庄重不起来。还是轻易唠唠吧。 咱就唠这么几个角度： 本书读者举荐序举荐语本书简介本书前言封面由来目录概览历史故事送书流动没错，是要送书的，如果这是你惟一关怀的“点”，那就间接翻到结尾吧！ 本书读者本书适宜这么几类读者： 显示器太低，又不能伸缩，须要一本书垫一垫的；喜爱吃泡面，然而没有锅，须要一本书盖一盖的；……总结：本书用来垫显示器和盖泡面那是一绝！ （不配图了，我不吃泡面，我的显示器也能够伸缩，哇咔咔） 《江城》（豆瓣9.1分）的作者彼得·海斯勒在书中写到这样一段话： 至于《江城》，我也感觉糟糕透顶。这本书仿佛一文不值 ——不过小孩子的写作水平而已。我齐全莫衷一是，也想不起我在书里表白了什么样的观点。起初我才晓得，很多作家在实现了高强度的写作之后，都有过相似的解体体验，就好似十月怀胎的妈妈们一朝分娩，接着蒙受产后抑郁的折磨。此刻我其实也是“心田奔溃”的，我感觉我这本《Kubernetes Operator 开发进阶》一文不值。 爱因斯坦在不同的角度有过相似的表述： 用一个大圆圈代表我所学的常识，然而圆圈之外有那么多空白，对我来说意味着无知，而且圆圈越大，它的圆周就越大，它与外界空白的接触面也就越大。所以在写这本书的过程中，我其实也在经验着这样的心路历程： “我感觉我懂一些货色了，能够写一本书。” -> “我才懂一点皮毛，谁给我的勇气写这本书？” 所以在这里我不想去说这本书能够帮忙哪些人学到多少常识达到什么境地之类的话。 哎，还是盖泡面吧。 举荐序可能邀请到邓洪超和任晶磊两位大咖给本书作序，太侥幸了！ 看看他们是怎么说的吧~ 举荐序1 - 邓洪超邓洪超：Operator 机制开创作者之一，CNCF 利用交付畛域联席主席通过作者多年的实际积攒和长期的精心筹备，这本书终于和大家见面了。我有幸作为本书的首批读者，同时也是最早参加研发Operator技术的工程师，心田是非常冲动的：我不仅见证了这项技术被利用到越来越多的事实场景中，同时也看到这部分常识通过书籍等模式记录下来，造福更多的开发者。 说起Operator的历史，一开始它是为了解决如何在Kubernetes上部署有状态利用而创造的。Kubernetes晚期设计上只可能部署无状态利用，而对于有状态利用像etcd、MySQL、Kafka等并没有优雅的部署计划。起初咱们通过 Operator这一套机制，让治理有状态利用变得跟无状态利用一样简略。不仅如此，Operator的外围价值在于可能扩大 Kubernetes API，这也让越来越多的工作负载得以运行在Kubernetes上。在阿里落地Kubernetes的过程中，就通过 Operator机制将大规模服务部署胜利，并诞生了OpenKruise我的项目。 本书我认为十分值得大家一读，次要有以下几点举荐理由： 首先，本书内容通俗易懂，有助于初学者疾速学习相干常识，并且从开发者角度登程，每一个概念退出了相应的代码实例来辅助了解。 其次，本书提供了大量的实例操作，不仅能够间接进步读者开发技能，还可能帮忙解决在实际生产中常常遇到的各种关键问题。书中这些内容具备很高的借鉴和推广意义。 另外，本书解说有些内容时间接深刻解析代码实现，让读者彻底了解其中原理。这对于有肯定根底（如 client-go）的专业人士学习Kubernetes的各种细节和实际操作非常无利。 最初，本书系统性地讲述了Operator整个机制的原理和生态，而不是繁多地解读某个工具或者服务。咱们能够看到，以Kubernetes为根底的整套云原生技术被越来越多的企业所采纳。这外面的每一项技术（如Operator、Helm、Kustomize 等）都不是孤立无关的。相同，串联好一整套云原生技术，站在新技术改革的肩膀上，能力施展出不可预估的价值！ 举荐序2 - 任晶磊任晶磊：思码逸创始人兼CEO，清华大学计算机系博士咱们有幸经验了几代虚拟化技术的演进和整合，见证了云原生技术的星火燎原。记得还在校园的时候，我跑去中关村的一家小公司实习，天天啃Xen的源代码。那一年，陈海波传授的团队发表了国内第一篇SOSP论文，做嵌套的虚拟化技术CloudVisor；同年，UC Berkeley的AMPLab在NSDI上发表了Mesos论文，起初衍生出Mesosphere和其上的容器编排零碎Marathon。时隔不久，Google开源了Kubernetes，并在EuroSys上公开了其外部容器管理系统Borg和Omega的设计，它们堪称Kubernetes的前身。 在近十年强烈的市场竞争中，Kubernetes怀才不遇，事实上占据了比Mesos+Marathon更加劣势的位置。Kubernetes最终取得了更宽泛的社区和用户，这与它简洁的设计、弱小的可扩展性、优良的开发者体验密不可分。而这些Kubernetes的胜利因素有一个重要的基石，就是它的Operator模式。Operator扩大了Kubernetes可利用和服务的场景，同时为开发者参加和扩大这些新场景提供了有效途径。 胡涛将他在GitHub和博客上连载的Kubernetes源码剖析文章裁减降级为此书，零碎介绍了Operator开发的常识。从设计到源码，从实例到我的项目，此书是国内这方面少有的原理与实际相结合的佳作。置信它能帮忙国内开发者一瞥Kubernetes的精华，学习和把握Operator技术，既晋升对云原生和容器零碎的了解，又满足理论零碎开发和运维的须要。胡涛的工作既立足Kubernetes在开发者社区中疾速扩大的关键点，同时也为Kubernetes社区和生态添砖加瓦。 在思码逸，胡涛正在和咱们一起打造DevOps工具链管理器DevStream，并已胜利捐献给CNCF，持续推动云原生技术的倒退。与胡涛共事，我深知他语言风趣，经常思如涌泉，期待读者可能享受他在此书中飞腾的文字。 举荐语没错，除了举荐序之外，还有张磊，宋净超，王泽锋，周鹏飞和郑东旭五位重磅大咖写了举荐语，荣幸之至！ 举荐语1 - 张磊张磊：CNCF TOC 成员Operator机制是云原生生态的一项要害翻新，也是扩大、运维和二次编程Kubernetes我的项目的必备技能。本书对Operator机制进行了深刻的源码级分析和解说，是一本不可多得的技术读物。 举荐语2 - 宋净超宋净超：Tetrate 布道师，云原生社区创始人Kubernetes Operator就好比云原生利用的发动机引擎，这本书将为你揭开引擎盖，直击Operator细节，带你玩转云原生利用！ 举荐语3 - 王泽锋王泽锋：华为云云原生开源负责人，Kubernetes资深维护者，CNCF大使，KubeEdge、Volcano、Karmada我的项目创始人随着云原生技术的遍及，其关键技术Kubernetes曾经无处不在。而Operator概念的提出，Kubebuilder、 controller-runtime等我的项目的衰亡，开启了全民定制Kubernetes的时代。本书从Operator模式、Kubernetes API机制、client-go工作原理等维度零碎介绍了如何高质量地开发一个Operator利用，值得每个云原生的开发者浏览和学习。 举荐语4 - 周鹏飞周鹏飞：微软 Azure 产品经理，CNCF大使Kubernetes是云原生时代的分布式操作系统，Kubernetes Operator可能帮忙云原生开发者在此操作系统之上灵便开发和扩大新的API与利用。本书来自于胡涛多年的云原生开源我的项目参加教训和工业界实践经验的总结，为读者深入浅出地介绍了Operator相干的概念实践、源码解析和工具实操等。本书联合了大量的流程图与示例代码，帮忙开发者疾速了解和上手 Kubernetes Operator开发，是目前市面上较为稀缺的Kubernetes开发工具类实战宝典。 ...

随着 k8s 社区日渐壮大， k8s 也日渐壮大并稳固。以下是依据社区现状，对 k8s 2023 年一些倒退方向的瞻望: 升高复杂度。以 k3s 为代表的 k8s 简化计划将持续倒退。2022 年 k8s 已由 3 月一版本的迭代周期变成了4月一版本的迭代，也从侧面反馈了其性能日趋完善和简单。轻量化容器。随着 serverless 的进一步推广， overhead 更小的容器化计划需要日益加强，是否会呈现 k8s on webassemble 或 k8s on firecracker?两级调度器。更简单的调度器来适应更多离线工作集群、机器学习集群、混部集群no etcd。最终一致性存储计划来适应更大规模集群、边缘集群针对超算核心、numa 设施等更多反对