k8s

rancher会自动在ingress 的annotations 里面加入 field.cattle.io/xx注解

Kubernetes 社区版是基于 Nginx 的扩展版 OpenResty 及诸多第三方模块构建的，其基于 OpenResty 的 Lua 嵌入式编程能力，扩展了 Nginx 的功能，并基于 balancer_by_lua 模块实现了 Pod 变化的动态变更功能。

Error: error installing: deployments.extensions is forbidden: User “system:node:mildevkub020” cannot create resource “deployments” in API group “extensions” in the namespace “kube-system”

Docker push 报错：received unexpected HTTP status: 500 Internal Server Error

设置合适的资源requests和limits对充分利用Kubernetes集群资源来说十分重要。如果requests设置得太高，集群节点利用率就会比较低，这样就白白浪费了金钱。如果设置得太低，应用就会处于CPU饥饿状态，甚至很容易被OOM Killer杀死。所以如何才能找到requests和limits的最佳配置呢？

k0s 可以认为是一个下游的 Kubernetes 发行版，与原生 Kubernetes 相比，k0s 并未阉割大量 Kubernetes 功能；k0s 主要阉割部分基本上只有树内 Cloud provider，其他的都与原生 Kubernetes 相同。

使用 Sidecar 模式部署服务网格时，无需在节点上运行代理，但是集群中将运行多个相同的 Sidecar 副本。在 Kubernetes 的 Pod 中，在原有的应用容器旁边运行一个 Sidecar 容器，可以理解为两个容器共享存储、网络等资源，可以广义的将这个注入了 Sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源。

https://github.com/Yelp/dumb-init

如果你使用的是 Go，则可以使用 dockertest，一个可以管理和编排 Go 测试文件中的容器的库。

istio 的 Sidecar 有两种模式：

QKE（QingCloud KubeSphere Engine），KubeSphere 是一款基于 Kubernetes 构建的企业级容器平台，QKE 在 QingCloud 上一键交付生产可用的原生托管 Kubernetes 集群，同时，借助 KubeSphere 容器平台的全栈能力，可统一管理跨云、跨基础设施的 Kubernetes 集群，通过极简的人机交互实现 CI / CD、微服务、以及集群运维管理，帮助用户更敏捷地构建云原生应用并统一管理应用的全生命周期。

https://github.com/vercel/fun ocal serverless function λ development runtime. // example/index.js exports.handler = function(event, context, callback) { callback(null, { hello: ‘world’ }); };

正常运行一段时间的POD，突然有一天运行报错了，错误是没有操作目录的权限，查其原因，原来是镜像被更新了，镜像添加了操作用户，而被操作的目录（NFS目录）并不具备普通用户操作的权限。

作者：识趣 链接：https://www.orchome.com/10621 来源：OrcHome 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

在Kubernetes支持多种类型的卷，而Pod可以同时使用各种类型和任意数量的存储卷。在Pod中通过指定下面的字段来使用存储卷：

Histogram 由 _bucket{le=""}，

有一种方法可以通过使用pseudo-tty和detach选项（docker run命令上的-td选项）来保持容器在Docker容器上运行，不会关闭。 例如, $ sudo docker run -td ubuntu:latest

nsenter是一个命令行工具，用来进入到进程的linux namespace中。

输出pod中一个容器的日志。如果pod只包含一个容器则可以省略容器名。

Binding: 已弃用。用于记录一个object和另一个object的绑定关系。实际上主要用于将pod和node关系，所以在1.7版本后已经改为在pods.bindings中记录了。 ComponentStatus: 是一个全局的list（即不受命名空间影响），记录了k8s中所有的组件的的相关信息，比如创建时间，现在状态等。 Configmap: 是一种用于记录pod本身或其内部配置信息的API资源，可以认为是通过API形式存储的配置文件。 Endpoints: 用于记录每个service的pod的真实物理ip和port的对应关系，包括service是TCP还是UDP等。 Event: 用于记录集群中的事件，可以认为类似于日志里的一条记录。 LimitRange: 用于记录各个命名空间中的pod或container对每种资源的使用限制，一般被包含在pod的定义中。 Namespace: 是一个全局的list，保存集群中所有的命名空间。 Node: 是一个全局的list，详细记录了每个节点的name, labels, PodCIDR, host IP, hostname, 总资源（cpu，内存），可分配资源，各心跳状态（网络，内存，硬盘，PID数量，kubelet等），kubelet的物理port，各k8s组件image信息，node环境信息（os, CRI version, kubeProxy version, kubelet version等）。 PersistentVolumeClaim: 记录用户对持久化存储的要求。 PersistentVolume: 是一个全局的object，记录了所有的持久化存储设备的信息（类似于node） Pod: 是对于使用k8s的开发者而言最重要的资源，其中包含ownerReference (Node, Demonset等），containers相关信息（image，启动命令，probe，资源信息，存储信息，结束时行，是否接受service注入环境变量为等），网络设置（dns设置，port设置等），集群调度相关信息（优先级，tolerations，affinity，重启规则等），pod状态（hostIP，podIP，启动时间等） PodTemplate: 一般是被包含在其它资源中的一部分，比如Jobs, DaemonSets, Replication Controllers。其初始化刚被创建的pod的k8s相关的信息，一般是label等。 Replication Controller: 是系统内建的最常用的controller，用来保证Pod的实际运行数量满足定义。如果不足则负责创建，如果过多则通知一些pod terminate。 ResourceQuota: 用于记录和限制某个namespace的中的总的资源消耗，一般用于多用户下利用namespace对资源进行限制。 Secrets: 实际上将文件内容通过base64编码后存在etcd中。在Pod中container启动时可以将secretes作为文件挂载在某一路径下，如此避免重要信息存储在image中。 ServiceAccout: 用于授权集群内的pod访问apiServer。 Service: 非常重要且常见的资源，用于对外提供统一的Service IP和port，将流量负载均衡调整至集群中多个pod。重要的配置有：cluster IP，port，selector（选择转发流量的目的pod），sessionAffinity等。这里提供的负载均衡是L3 TCP的。 MutatingWebhookConfiguration: 不明（内部object） ValidatingWebhookConfiguration: 不明（内部object） CustomerResourceDefinitions: 自定义资源也是非常重要的一种资源，是各种k8s插件能够存在的基础。比如当要实现Clico之类的自定义插件时，首先需要考虑的就是apiServer如何能够处理相关的请求信息。自定义资源的定义便是apiServer处理资源的依据。这个话题比较复杂，在这里不详细讨论。 APIService: 定义API服务的资源。一个API请求有两种形式，/apis/GROUP/VERSION/这种不被包含在namespace中的（即全局的）和/apis/GROUP/VERSION/namespaces/NAMESPACE/这种被包含在namespace中的。当一个请求到达apiServer后，必然需要有相应的代码去处理它。每一对GROUP和VERSION确定一种API，响应每一种API请求的代码被抽象为一种服务（service）。想象一下自定义资源的相关API请求到达apiServer后如何被处理呢？相关的service也是自定义的并且运行在master中，k8s正是根据APIService来正确地将请求与正确的service关联。在这里可以定义service名称，安全设置，优先级等。 ControllerRevision: 是一个beta功能，用于Controller保存自己的历史状态便于更新和回滚。 Daemenset: 常见的Pod set种类，用于控制每种pod状态（数量，计算资源使用，probe等）在定义的范围内，且在每node上最多有一个。 Replicaset: 常见的Pod set种类但现在基本上不直接使用，用于控制每种pod的状态（数量，计算资源使用，probe等）在定义的范围内。一个Replicasets中的各个pod都应是等同的、可互换的，即对外表现完全相同。就好比所有的氢原子（1质子0中子）都是不可区分的。 Deployment: 最常见的Pod set种类，可以拥有Replicasets和Pod。用于控制拥有的资源的状态（数量，计算资源使用，probe等）在定义的范围内。 StatefulSet: 常见的Pod set种类。和Deployment的区别之处是它控制的pod不是可互换的而是在整个生命周期有不变的标签。这样，每个pod可以有自己的DNS名，存储等。即使pod被删除后这些信息也会被恢复。 TokenReview: 不明，似乎和apiServer的Webhook的token授权相关。 LocalSubjectAccessReview: 不明（内部object），和一个命名空间对用户/组的授权检查相关。 SelfSubjectAccessReview: 不明（内部object），和当前用户检查自己是否有权限对一个命名空间进行操作相关。 SelfSubjectRulesReivew: 不明（内部object），含有当前用户在一个命名空间内能进行的操作的列表。和apiServer的授权安全模式相关 SubjectAccessReviews: 不明（内部object），和用户/组的授权检查相关，并不限定于某个命名空间。 HorizontalPodAutoScaler: 控制Pod set（比如Deployment）的pod数量的资源。可以根据pod的CPU、内存、自定义数据动态调节pod数量。在这里可以找到相关的例子。 CronJob: 定时运行Job pod的资源。 Job: 常见的Pod set种类，会创建一定数量的pod，仅当特定数量的pod成功结束后这个Job才算成功结束。创建的pod在结束后不会被重启。 CertificateSigningRequests: 可以认为是一个接口，便于Pod等资源申请获得一个X.509证书。这个证书应该被controller approve或者被手动approve，之后被合适的对象签名。具体可以参考这里。 Lease: 是一个在1.13版本中加入的资源类型，用于Node向master通知自己的心跳信息。之前的版本中kebulet是通过更新NodeStatus通知master心跳，后来发现NodeStatus太大了而心跳信息更新频繁，导致master压力较大，于是增加了Lease这种资源。 EndpointSlice: 是含有一个service的Endpoint的部分信息的资源。原因和Lease类似，对于含有较多信息的service（比如有很多pod分布在多个node上）一个endpoint object可能会比较大而且被频繁访问，所以这种情况下会有多个endpointSlice被创建减轻master的压力。 Event: 描述一个集群内的事件的资源，含有message，event，reason，报告来源等详细的信息。 Ingresse (APIGroup=extensions): 将被deprecated。 Ingresse (APIGroup=http://networking.k8s.io): 可以简单理解为是定义loadbalancer的资源。其中含有一系列规则，定义了不同url的对应后端，SSL termination等。为什么这个新的API会取代前面那个APIGroup=extensions的Ingress API呢？我查了很多地方没有找到具体的文字解释，但是可以推测是Ingress正式成为k8s的网络模块的一部分，对应的server（代码）从extensions迁移到http://networking.k8s.io。 NetworkPolicy: 定义了那些网络流量可以去哪些pod的资源。一个NetworkPolicy可以指定一组pods，定义只有满足了特定条件（比如源/目的IP，port，pod名等）的网络流量可以被相应的pod收发。 RuntimeClass: 这是2019年讨论加入的新API资源。文档说明其目的是将容器运行时（Container Runtime）环境的属性暴露给k8s的控制层，便于在一个集群或节点中支持多种容器运行时环境。这样便于未来创建更具有兼容性的k8s集群。 PodDisruptionBudget: 这一个API资源使用户可以对一组pod定义“k8s可以容忍的实际running状态的pod数量与预期的差距”。考虑这样一个情景：一集群中某个service后一共有5个相同pod处理其流量，要求至少有一半的pod是可用的，但其中3个pod由于调度运行在node A上。如果出现node A突然故障等情况导致服务不可用，暂时没有好的办法处理这种不可避免地意外情况（或者需要让调度算法知道这些pod应该被尽量均匀分布在个节点上，但目前k8s没有功能强制这种调度）。但除此之外还有很多可以避免的意外情况，比如在集群维护或者其它事件的处理过程中，集群管理员可能drain node A，导致三个pod同时被结束从而影响业务。针对这种可避免的意外，若一组pod的数量因为可避免的k8s操作将会低于可容忍程度（在PodDisruptionBudget中定义），那么这个命令会被阻止并返回失败。 PodSecurityPolicy: 定义了一个pod在集群中被创建/运行/更新时需要满足的条件。 ClusterRole: 定义了集群中policy rule的一些常见集合，比如system-node等，用于控制账户权限。 ClusterRoleBinding: 定义了某个账户/组对ClusterRole的引用，用于赋权。 Roles: 和前面ClusterRole类似，但是顾名思义ClusterRole是和集群账户相关，Role则被用于其它的账户（比如controller使用的service account） RoleBindings: 定义了某个账户/组对Role的引用，用于赋权。 PriorityClass: 定义了pod优先级名称和对应值的映射。比如system-cluster-critical对应的优先级为2000000000。值越大代表优先级越高，那么当集群资源不足等情况发生必须终止一些pod时，优先级小的pod会先被终止。为什么不直接用数值代表优先级呢？因为这样子很容易出现确定随意性。比如开发人员A开发了一个非常重要的pod，于是在代码中将其优先级的值设置为9999。但是集群集群管理员B可能认为9999是一个小数字，他创建的随便一个pod的优先级都是999999+。于是需要PriorityClass来进行优先级的统一管理和比较。 CSIDriver: 定义了集群中容器存储驱动的API资源。CSI代表的是Container Storage Interface，即容器存储接口。k8s应该可以利用各种各样的存储服务，各家云厂商的活开源的。k8s如何知道怎么去用这些存储服务呢？那么就是通过这个CSIDriver资源找到相应的驱动。 CSINode: 前面CSIDriver产生的节点相关的信息便存在CSINode中。 StorageClass: 定义了可以存在的存储类型的API资源。 Volumeattachments: 定义了对一个node分配/回收存储空间的请求的API资源。 NetworkSets: 接下来的都是Calico自定义API资源，就不一一分析了，都与网络协议/安全/管理相关。 NetworkPolicies: Calico自定义API资源 IPPools: Calico自定义API资源 IPAMHandles: Calico自定义API资源 IPAMConfigs: Calico自定义API资源 IPAMBlocks: Calico自定义API资源 HostEndpoints: Calico自定义API资源 GlobalNetworkSets: Calico自定义API资源 GlobalNetworkPolicies: Calico自定义API资源 FelixConfiguration: Calico自定义API资源 ClusterInformation: Calico自定义API资源 BlockAffinity: Calico自定义API资源 BGPPeer: Calico自定义API资源 BGPConfiguration: Calico自定义API资源 https://zhuanlan.zhihu.com/p/115903242

KubeVela 是一个简单易用且高度可扩展的应用管理平台与核心引擎。KubeVela 是基于 Kubernetes 与 Open Application Model（OAM） 技术构建的。

1.k8s中内存表示法 内存：MI

APIExtensionServer：主要处理 CustomResourceDefinition（CRD）和 CustomResource（CR）的 REST 请求，也是 Delegation 的最后一环，如果对应 CR 不能被处理的话则会返回 404。 Aggregator 和 APIExtensionsServer 对应两种主要扩展 APIServer 资源的方式，即分别是 AA 和 CRD。

我们希望在执行 kubectl create -f kafka-source.yaml 之后，在 kubernetes 里会启动一个 pod，这个 pod 会做下面的事情：

FreeBSD 下的虚拟技术 bhyve (The BSD Hypervisor) 包含在了 FreeBSD 10.0 发行版中。而这个 xhyve 是基于 bhyve 的 Mac OS X 移植版本

当你创建新的 CustomResourceDefinition（CRD）时，Kubernetes API 服务器会为你所 指定的每一个版本生成一个 RESTful 的 资源路径。CRD 可以是名字空间作用域的，也可以 是集群作用域的，取决于 CRD 的 scope 字段设置。

HTTP协议重定向 HTTP重定向：服务器无法处理浏览器发送过来的请求（request），服务器告诉浏览器跳转到可以处理请求的url上。（浏览器会自动访问该URL地址，以至于用户无法分辨是否重定向了。） 重定向的返回码3XX说明。Location响应首部包含了内容的新地址或是优选地址的URL。

Kubernetes在1.8的版本中引入了一种类似于CPU，内存的新的资源模式：ephemeral-storage，并且在1.10的版本在kubelet中默认打开了这个特性。

虽然编译器（compiler）和质量器（linter）可以很好地检测代码拉取请求中的错误，但Kubernetes配置文件缺少良好的验证。现有的解决方案是运行kubectl apply –dry-run，但这会运行本地（local）干运行而不与服务器通信：它没有服务器验证，也没有通过验证许可控制器（validating admission controller）。例如，自定义资源名称仅在服务器上验证，因此本地干运行无济于事。

当需要从集群外部访问k8s里的服务的时候，方式有四种：ClusterIP（默认）、NodePort、LoadBalancer、ExternalName 。

只有点到第一级集群菜单才会出现集群节点的信息列表 点击集群下的项目就会列出当前集群下的项目所占用的所有工作负载

无状态服务（Stateless Service）：该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的，比如前面我们讲解的 WordPress 实例，我们是不是可以同时启动多个实例，但是我们访问任意一个实例得到的结果都是一样的吧？因为他唯一需要持久化的数据是存储在MySQL数据库中的，所以我们可以说 WordPress 这个应用是无状态服务，但是 MySQL 数据库就不是了，因为他需要把数据持久化到本地。 有状态服务（Stateful Service）：就和上面的概念是对立的了，该服务运行的实例需要在本地存储持久化数据，比如上面的 MySQL 数据库，你现在运行在节点 A，那么他的数据就存储在节点 A 上面的，如果这个时候你把该服务迁移到节点 B 去的话，那么就没有之前的数据了，因为他需要去对应的数据目录里面恢复数据，而此时没有任何数据。 无状态服务利用我们前面的 Deployment 可以很好的进行编排，对应有状态服务，需要考虑的细节就要多很多了，容器化应用程序最困难的任务之一，就是设计有状态分布式组件的部署体系结构。由于无状态组件没有预定义的启动顺序、集群要求、点对点 TCP 连接、唯一的网络标识符、正常的启动和终止要求等，因此可以很容易地进行容器化。诸如数据库，大数据分析系统，分布式 key/value 存储、消息中间件需要有复杂的分布式体系结构，都可能会用到上述功能。为此，Kubernetes 引入了 StatefulSet 这种资源对象来支持这种复杂的需求。StatefulSet 类似于 ReplicaSet，但是它可以处理 Pod 的启动顺序，为保留每个 Pod 的状态设置唯一标识，具有以下几个功能特性：

k0s 可以认为是一个下游的 Kubernetes 发行版，与原生 Kubernetes 相比，k0s 并未阉割大量 Kubernetes 功能；k0s 主要阉割部分基本上只有树内 Cloud provider，其他的都与原生 Kubernetes 相同。

https://www.qikqiak.com/post/gitlab-ci-k8s-cluster-feature/

https://github.com/ubuntu/microk8s

ingress-nginx 的目标是构造配置文件（nginx.conf），主要用途是在配置文件有任何变更后都需要重新加载 NGINX。不过需要特别注意的是，在只有 upstream 配置变更的时候我们不需要重新加载 Nginx（即当你部署的应用 Endpoints 变更时）。我们使用 lua-nginx-module 达到这个目的

https://github.com/kubernetes/ingress-nginx/ Name-based vs. IP-based Virtual Hosts IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host. With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address. https://blog.csdn.net/u010620626/article/details/46054713 https://kubernetes.io/docs/concepts/services-networking/ingress/ Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

将这些Kubernetes批注添加到特定的Ingress对象以自定义其行为

第一步，创建账号密码文件 这里需要使用到密码文件生成工具htpasswd htpasswd -c auth user1 New password:

HPA（Horizontal Pod Autoscaler）是kubernetes（以下简称k8s）的一种资源对象，能够根据某些指标对在statefulSet、replicaController、replicaSet等集合中的pod数量进行动态伸缩，使运行在上面的服务对指标的变化有一定的自适应能力。 HPA目前支持四种类型的指标，分别是Resource、Object、External、Pods。其中在稳定版本autoscaling/v1中只支持对CPU指标的动态伸缩，在测试版本autoscaling/v2beta2中支持memory和自定义指标的动态伸缩，并以annotation的方式工作在autoscaling/v1版本中。

K8S不支持长连接的负载均衡，所以负载可能不是很均衡。如果你在使用HTTP/2，gRPC, RSockets, AMQP 或者任何长连接场景，你需要考虑客户端负载均衡。

https://github.com/knative/serving

将 Docker Compose 文件转换为 Kubernetes 资源 Kompose 是什么？它是个转换工具，可将 compose（即 Docker Compose）所组装的所有内容 转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。

https://github.com/kubernetes/kubernetes/issues/19231

RBAC基于角色的访问控制–全拼Role-Based Access Control ​ Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权 ​ 在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。 ​ 在RABC API中，通过如下的步骤进行授权： 1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则； 2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。 Role与ClusterRole 一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。 Role:角色可以由命名空间内的Role对象定义,一个Role对象只能用于授予对某一单一命名空间中资源的访问权限 ClusterRole:整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。 简介 role: 1、允许的操作，如get,list等 ​ 2、允许操作的对象，如pod,svc等 ​ rolebinding: ​ 将哪个用户绑定到哪个role或clusterrole上 ​ clusterrole：(集群角色) clusterrolebinding:(绑定到集群) 3、如果使用rolebinding绑定到clusterrole上，表示绑定的用户只能用于当前namespace的权限

requests：资源请求，表示需要多少资源。 limits： 资源限制，表示最多可以使用多少资源。

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 协议 https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md https://github.com/grpc-ecosystem/grpc-health-probe/ https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto

Rancher ingress控制器利用Rancher中现有的负载均衡功能，将Kubernetes ingress的内容转换到Rancher的负载均衡器。

CoreDNS作为CNCF中托管的一个域名发现的项目，原生集成Kubernetes，它的目标是成为云原生的DNS服务器和服务发现的参考解决方案。所以，CoreDNS走的也是Traefik的路子，降维打击SkyDNS。 https://www.jianshu.com/p/144d683bbf26

ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。

docker 一般用的都是apline镜像，不支持yum等工具，但是支持apk，用apk安装git 和ssh ，然后就可以开始拉代码做压测环境了

https://github.com/kubernetes/client-go k8s-client 是对k8s api的一个封装，应用k8s-client 我们可以实现kubectl 所有功能。

https://www.cnblogs.com/zhangboyu/p/7452725.html

CoreDNS的作用：在K8S里，我们想要通过name来访问服务的方式就是在Deployment上面添加一层Service，这样我们就可以通过Service name来访问服务了，那其中的原理就是和CoreDNS有关，它将Service name解析成Cluster IP，

curl -is –cacert ca.pem –key admin-key.pem https://localhost:6443/api

https://github.com/mpriscella/k8s-actions https://github.com/balchua/microk8s-actions

https://github.com/lensapp/lens/releases/tag/v4.1.4

Chart 目录结构 examples/ Chart.yaml # Yaml文件，用于描述Chart的基本信息，包括名称版本等 LICENSE # [可选] 协议 README.md # [可选] 当前Chart的介绍 values.yaml # Chart的默认配置文件 requirements.yaml # [可选] 用于存放当前Chart依赖的其它Chart的说明文件 charts/ # [可选]: 该目录中放置当前Chart依赖的其它Chart templates/ # [可选]: 部署文件模版目录，模版使用的值来自values.yaml和由Tiller提供的值 templates/NOTES.txt # [可选]: 放置Chart的使用指南 templates 目录 templates目录中存放了Kubernetes部署文件的模版。

1、首先添加docker官方的国内镜像 sudo tee /etc/docker/daemon.json «-‘EOF’ { “registry-mirrors”: [“https://registry.docker-cn.co”] } EOF 2、gcr.io镜像 根据开源项目：

The v1.16 release will stop serving the following deprecated API versions in favor of newer and more stable API versions:

Travis CI 之类的工具，应该对 Actions 很熟悉了：它们为你提供了一个可以测试你应用程序的环境 - 一般是以服务器的形式，你的代码在一个目录中被 checkout 出来，当代码推送到你的 Github 仓库上，一个环境会被启动，然后检出代码，在环境上执行指定的一些任务，如果有任何一个任务失败了，则你的 CI 任务就会失败。当然这不仅仅可以用于自动化测试，我们也可以用于编译应用程序，然后将相关制品上传到 S3 等服务上，或者向你的 QA 团队发送一封电子邮件，让他们知道哪些测试通过或失败了。 CI 环境中安装 Kubernetes 集群不是很好的一个方案：

一、Ingress-Nginx工作原理

kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready master 11h v1.19.7

mac 上暂时没有kubeadm 工具，该工具主要用于集群创建和集群管理

curl -o ingress-nginx.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-0.32.0/deploy/static/provider/cloud/deploy.yaml

https://github.com/AliyunContainerService/k8s-for-docker-desktop

我们有 3 个 service，service-front 通过入口暴露给外网。service-front 的后端服务是 service-middle，service-middle 的后端是 service-back。通信是通过 K8s service 完成的。

https://github.com/telepresenceio/telepresence

kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT […[LOCAL_PORT_N:]REMOTE_PORT_N]

https://kubernetes.io/zh/docs/tasks/administer-cluster/kubeadm/

性能分析是一项较为复杂的任务，大多数探查器有两个主要问题：

https://github.com/derailed/k9s 设置 k9s 配置文件 安装好 k9s 应用后，从帮助命令开始总是很好的起点。

k0s 号称是一款简易、稳定且经过认证的 Kubernetes 发行版，它提供了构建 Kubernetes 集群所需的所有内容，预先配置了所有所需的功能，使得构建 Kubernetes 集群只需复制一个可执行文件到每个主机并运行它即可。

https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

rm -rf ~/.kube rm -rf ~/Library/Group\ Containers/group.com.docker/pki

https://github.com/kong/kubernetes-ingress-controller

https://www.rancher.cn/

https://minikube.sigs.k8s.io/docs/start/

https://github.com/rootsongjc/kubernetes-handbook https://github.com/gotok8s/gotok8s https://github.com/gotok8s/gotok8s#helm https://github.com/gotok8s/gotok8s#%E9%83%A8%E7%BD%B2-kubernetes-dashboard https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster https://github.com/servicemesher/istio-handbook/pulse

K8S提供了ingress特性，而可实现ingress的软件有nginx、haproxy、traefix等，本文描述如何将API网关服务Kong作为ingress来暴露集群提供的服务。 本文采用Helm方式安装，否则可用原始YAMLs文件方式安装，如：

安装k8s大致有2种方式，minikube和Docker Desktop

https://mp.weixin.qq.com/s/Pfj1GXM8vLxft3SoTkAFTQ

Declarative（声明式设计）指的是这么一种软件设计理念和做法：我们向一个工具描述我们想要让一个事物达到的目标状态，由这个工具自己内部去figure out如何令这个事物达到目标状态。

https://mp.weixin.qq.com/s/u5aEQhZTDtLrVdC8AO_ogQ

Tekton组件：提供从源码到镜像的通用构建能力。 Serving组件：管理Serverless工作负载，可以和事件结合并且提供了基于请求驱动的自动扩缩的能力，而且在没有服务需要处理的时候可以缩容到零个实例。 Eventing组件：提供了事件的接入、触发等一整套事件管理的能力。 https://help.aliyun.com/document_detail/121509.html

iptables -t nat -L –line-numbers

Tekton 是一个功能强大且灵活的 Kubernetes 原生框架，用于创建 CI/CD 系统。通过抽象出底层实现细节，允许开发者跨多云环境或本地系统进行构建、测试与部署。

https://zhuanlan.zhihu.com/p/65914436 Serverless 简介 根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。(serverless-overview)

https://gocn.vip/topics/10604 硬件软件化的核心在于硬件功能中越来越多的部分由软件来呈现，从而在迭代效率、成本等方面获得显著优势。以软件定义存储（Software Defined Storage，SDS）为例，SDS 是位于物理存储和数据请求之间的一个软件层，允许用户操控数据的存储方式和存储位置。通过硬件与软件解耦，SDS 可运行于行业标准系统或者 X86 系统上，意味着用户可以无差别的使用任何标准的商用服务器来满足不断增长的存储需求。硬件与软件解耦也让 SDS 能够横向扩展，消除容量规划，成本管理等方面的复杂性。

https://mp.weixin.qq.com/s/6lON6TLYVRy31R26fRDQXw 作为云原生服务网格领域的热门开源项目，Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。

https://gocn.vip/topics/10419 首先一起来看一下需求来源。大家应该都有过这样的经验，就是用一个容器镜像来启动一个 container。要启动这个容器，其实有很多需要配套的问题待解决：

https://mp.weixin.qq.com/s/woQkOCGxwmkGb2b0-VPBsw 谷歌Kubernetes Engine(GKE)是一个用于在谷歌云平台中部署容器化应用程序的托管、可生产的环境。GKE于2015年上线，是第一个基于谷歌在容器中运营Gmail、YouTube等服务12年多经验的托管容器平台之一。为了完全消除对安装，管理，和操作Kubernetes集群的需要，GKE允许客户快速安装和运行Kubernetes。

https://gocn.vip/topics/10358 一、为什么需要 Pod 容器的基本概念 我们知道 Pod 是 Kubernetes 项目里面一个非常重要的概念，也是非常重要的一个原子调度单位，但是为什么我们会需要这样一个概念呢？在使用容器 Docker 的时候，也没有这个说法。其实，如果想要理解 Pod，首先要理解容器，所以来回顾一下容器的概念：

https://gocn.vip/topics/10295 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书，文章从基础概念入手，介绍了什么是服务网格及 Istio，针对 2020 服务网格的三大发展趋势，体系化、全方位地介绍了 Istio 服务网格的相关知识。 stio 是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。

https://mp.weixin.qq.com/s/2NLxYk5P3So9TzxtSyUD4A kubernetes网络性能问题

1 k3s 简介–5 less than K8s k3s[1] 是 rancher®开源的一个 Kubernetes 发行版，从名字上就可以看出 k3s 相对 k8s 做了很多裁剪和优化，二进制程序不足 50MB，占用资源更少，只需要 512MB 内存即可运行。

https://banzaicloud.com/blog/generating-go-code/ https://gocn.vip/topics/10174 Deployment 本质上其实只是一种部署策略，在了解其实现之前，先简单介绍一下部署系统里面常见的概念，Deployment 里面的各种参数和设计其实也都是围绕着这些展开的

https://mp.weixin.qq.com/s/C3gaDJ6YQYTR3SifpPrqNw Kubernetes已经成为在服务中编排容器和服务的实际方法。但是我们如何让集群外部的服务访问集群内部的内容呢？Kubernetes附带了Ingress API对象，用于管理对集群内服务的外部访问。

https://developer.aliyun.com/article/718735 https://developer.aliyun.com/article/727594 https://developer.aliyun.com/article/747821 https://gocn.vip/topics/10019 Kubernetes 日志采集难点 在 Kubernetes 中，日志采集相比传统虚拟机、物理机方式要复杂很多，最根本的原因是 Kubernetes 把底层异常屏蔽，提供更加细粒度的资源调度，向上提供稳定、动态的环境。因此日志采集面对的是更加丰富、动态的环境，需要考虑的点也更加的多。

我们通过 kubectl describe [资源] 命令，可以在看到 Event 输出，并且经常依赖 event 进行问题定位，从 event 中可以分析整个 POD 的运行轨迹，为服务的客观测性提供数据来源，由此可见，event 在 Kubernetes 中起着举足轻重的作用。

https://gocn.vip/topics/9932 https://edu.aliyun.com/roadmap/cloudnative https://developer.aliyun.com/article/721151 一、Kubernetes 基本网络模型 本文来介绍一下 Kubernetes 对网络模型的一些想法。大家知道 Kubernetes 对于网络具体实现方案，没有什么限制，也没有给出特别好的参考案例。Kubernetes 对一个容器网络是否合格做出了限制，也就是 Kubernetes 的容器网络模型。可以把它归结为约法三章和四大目标。

为两个部分：

先看下consumer端发起调用时的链路流程：

Replication Controller（RC） 应用托管在K8S后，K8S需要保证应用能够持续运行，这是RC的工作内容。

k8s的部署架构 kubernetes中有两类资源，分别是master和nodes，master和nodes上跑的服务如下图，

Pod、Service、Volume 和 Namespace 是 Kubernetes 集群中四大基本对象，它们能够表示系统中部署的应用、工作负载、网络和磁盘资源，共同定义了集群的状态。Kubernetes 中很多其他的资源其实只对这些基本的对象进行了组合。 在接下来的几篇文章中我们将简单介绍 Kubernetes 中的四种基本对象中 Pod 并根据源代码分析它的作用和实现原理。

2019年11月19日，业界应用最为广泛的Kubernetes管理平台创建者Rancher Labs（以下简称Rancher）在KubeCon2019北美峰会上宣布，Rancher打造的轻量级Kubernetes发行版k3s正式GA，这款产品专为在资源有限的环境设计，可以满足在边缘计算环境中、在小型设备上运行Kubernetes集群的需求。与此同时，极简MicroPaaS平台Rio也正式发布beta版本。Rio是一款创造性的Kubernetes应用部署引擎，它提供了一整套从运维到流水线的、已集成好的部署体验。 “Kubernetes已经成为容器编排的事实标准，”Rancher联合创始人及CEO梁胜表示：“k3s、Rio以及近期发布的Rancher v2.3，组合成了Rancher‘Kubernetes即服务（Kubernetes-as-a-service）’的整套解决方案堆栈，从数据中心到云到边缘端，为ITOps和DevOps团队提供了全新的Kubernetes使用方式。”