开发者社区官方技术圈

创建即用，用户只需关注具体的业务逻辑，无需关注ocketMQ本身的版本迭代以及产品运维等方面的问题，极大的降低了用户在系统运维方面的成本投入。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

借助于优质的阿里云云原生基础设施而实现的消息队列RocketMQ版，有如下的优势：

1.接入方便：创建即用，用户只需关注具体的业务逻辑，无需关注RocketMQ本身的版本迭代以及产品运维等方面的问题，极大的降低了用户在系统运维方面的成本投入。

2.架构先进：消息队列RocketMQ版将存储和计算分离，可以独立按需水平的扩展存储和计算，从而满足高效弹性运维和高性能大规格能力的诉求。

3.高性能：提供了单实例集群最高100万TPS稳定消息收发的能力，使用户在面对峰值流量场景，无需担心系统稳定性。

4.弹性低成本：在面对突发流量的场景时，往往需要预留大量Buffer资源，消息队列RocketMQ版提供了预留+突发弹性的组合能力，无需再去预留资源，节省机器资源；在存储方面实现Serverless弹性化，按量付费使用，在拥有弹性的同时，成本也更低。

5.运维更方便：提供了例如全链路Trace、Prometheus等可观测系统，丰富了运维可观测能力；还提供完善的OpenAPI能力，使用户可以集成自助运维系统。

6.金融级容灾：提供全球跨地域消息路由复制能力，支持毫秒级低延迟、自定义Topic级别数据备份同步能力；提供异地双活容灾能力，支持国内地域组建双活应用系统。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

消息队列RocketMQ版是阿里云基于Apache1RocketMQ构建的低延迟、高并发、高可用、高可靠的分布式“消息、事件、流”统一处理平台，面向互联网分布式应用场景提供微服务异步解耦、流式数据处理、事件驱动处理等核心能力。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

集群内和集群外，这两种访问链路下，整个svc 的网络链路是不一样的。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•ingress controller的本质是多一层nginx7层代理

•ingress controller本质是多一层nginx7层代理，默认情况下ingress controller svc使用的lb为4层 tcp监听，tls需要通过ingress配置来支持。对于七层节点来说，服务端如果需要采集客户端真实IP地址，需要采集XFF的header来确定客户端的地址需要采集XFF的header来确定客户端的地址

•ingress的后端或者证书更新的时候，svc的ep更新后，ingress也会重新reload backend，这之间是需要一个时间差的，这个差值一般在几秒以内，不会对业务产生影响。所以存在pod已经被从svc 的ep中移除，但是还为从ingress controller的backend移除，依然会存在请求打到老pod，所以建议在pod中设置prestop来进行优雅的关闭连接。

•Loadblance 类型的svc

•依赖slb的负载均衡算法 健康检查，白名单等功能，可以通过SLB的ACL名单，来控制SLB的访问规则。

•slb支持7层监听，可以将证书放到slb上来完成https的握手，但是slb与后端pod使用http协议通讯。 这时候如果集群内访问SLB IP其实链路是不经过SLB的，会被iptables规则直接转发到目的pod，无法建立http是连接

•默认添加的后端服务器是nodeport类型，Terway模式，优选eni类型，这样SLB会直接转发到目的pod所在的ECS的附属ENI上，避免了后端ECS上的多次转发

•NodePort类型的svc

•依赖节点本身具备公网ip，这种用法会比较消耗eip，需要每个ECS配置EIP来提供被公网访问的能力

•不同的pod所在节点公网能力有所不同，会增加运维成本，建议使用SLB的方式提供对外服务的能力"

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

i.偶发出访问不通-出口NAT网关：

如果您有大量访问公网的机器或者pod，公网NAT网关做为统一公网出口，需要留意NAT网关的性能上限（带宽，最大连接数，吞吐量），可通过nat网关监控确认是否有达到性能瓶颈丢包等行为。

-偶发性的负载增加导致链路中出现丢包。 如遇负载徒增的问题导致丢包，基于tcpip协议的特性会有自动重传，小量的丢包可以忽略，如果量级比较高（可自行评估可承受的偶发延迟率，如超过1%的请求超过1s不可接受），需要评估是否需要横向扩展或者提高宿主机的配置，可参考上面所属的亲和性打散，cpu-static的优化，使用alinux2系统以及使用最新的规格如7代实例等。

ii.持续出访问不通

-底层实例网络故障

•先判断节点到公网，节点到节点是否能通

-集群网络模式

•Terway模式，pod拥有独立于ecs的eni, 需要留意pod eni的网络环境 （路由表，安全组等）。Terway Trunk ENI支持为每个Pod配置固定IP、独立的虚拟交换机、安全组。

•Flannel 模式，pod出方向经由节点eth0, 由CCM组件自动添加pod网段对应下一跳节点的路由条目。若路由表项缺失，会造成pod访问或者回包异常。

-是否设置NetworkPolicy

•Terway-eniip使用Calico的Felix作为NetworkPolicy功能的实现; 在基于IPvlan的ENI多IP的IPvlan模式中Terway的NetworkPolicy是通过集成Cilium组件来实现。

•注意NetworkPolicy的限制范围：可访问公网服务的来源IP网段；只能被带有特定标签的应用访问；限制一个Pod只能访问指定地址；控制命名空间下Pod公网访问权限。

-是否开启Istio注入

•开启Istio注入，Istio-proxy会根据用户设置的isito 规则改写iptables规则，pod出入流量会被istio-proxy拦截处理。

-EIP:

•通常VPC内配置NAT网关提供SNAT出公网能力，如果某些ECS实例已经绑定了EIP，这些ECS实例会优先通过绑定的EIP访问互联网，而VPC内的其他ECS实例通过NAT网关的SNAT功能访问互联网，造成VPC内ECS实例的公网出口IP不一致，EIP单独的网络环境也会带来额外的问题。

•以上场景非最佳实践，可以通过为ECS实例绑定弹性网卡来解决公网出口IP不统一的问题。为绑定了EIP的ECS实例单独分配一块弹性网卡，并将EIP绑定到弹性网卡，这样来自互联网的访问流量会经过弹性网卡到达ECS实例，当ECS实例需要访问互联网时会通过NAT网关进行转发。

-安全组出口规则

企业安全组需要明文规定出口规则。普通安全组出方向默认全开。参考官方文档中总结。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

对于集群内访问

svc：

•我们首先推荐集群使用svc 的 clusterip，此模式下，访问svc 的clusterip的转发模式取决于svc的internalTrafficPolicy配置，默认是cluster。 所以访问ClusterIP会被iptables/ipvs 规则默认转发到svc 后端的所有endpoint

•某些客户场景是通过lb类型暴露svc服务到集群外部， 同时配置lb的域名解析到lb的ip。而这个lb是提供给集群外和集群内访问。这种情况下，对于集群外部访问，lb可以均匀的转发到集群内后端的ep。但是对于集群内的pod访问svc的lb IP， 流量转发取决于externalTrafficPolicy的设置，一般情况下，ACK为Local模式，此时，客户端pod和lb后端的某个ep在同一个节点上时，流量才会被iptables/ipvs规则转发该节点上的后端ep上，而不会转发到其他节点上的ep。 这时候就产生了疑问，如何实现在集群内访问lb ip呢？可以给svc配置host（通过ervice.beta.kubernetes.io/alibaba- cloud-loadbalancer-hostname:""${your_service_hostname}""）， 不过这种情况下，一般建议配置7层监听，如果是4层监听，可能存在访问回环的问题。

•有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 ""None"" 来创建 Headless Service。

可以使用一个无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。对于无头 Services 并不会分配 Cluster IP，kube-proxy 不会处理它们， 而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

1.可以通过极速模式加速弹出速度，当伸缩组预热后（已完成一次扩容和缩容），伸缩组即可进入极速伸缩模式。2.使用自定义镜像的方式，通过Alibaba Cloud Linux 2（原Aliyun Linux 2）作为基础镜像，可以大大提升IaaS层的资源交付速度（50%）。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

NodeLocal DNSCache采用TCP协议与CoreDNS进行通信，CoreDNS会根据请求来源使用的协议与上游DNS服务器进行通信。因此默认情况下，来自业务容器的集群外部域名解析请求会依次经过NodeLocal DNSCache、CoreDNS，最终以TCP协议请求VPC内DNS服务器，即ECS上默认配置的100.100.2.136和100.100.2.13两个IP。

VPC内DNS服务器对TCP协议支持有限，如果您使用了NodeLocal DNSCache，您需要修改CoreDNS配置，让其总是优先采用UDP协议与上游DNS服务器进行通信，避免解析异常。建议您使用以下方式修改CoreDNS配置文件，即修改命名空间kube-system下名为coredns的Deployment。具体操作，请参见管理配置项。在forward插件中指定请求上游的协议为perfer_udp，修改之后CoreDNS会优先使用UDP协议与上游通信。修改方式如下所示：

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

部分早期版本的CoreDNS开启了Autopath插件，该插件在一些极端场景下会导致解析结果出错，请确认其是否处于开启状态，并编辑配置文件将其关闭。更多信息，请参见#3765。

说明 关闭Autopath插件后，客户端发起的域名解析请求QPS最高会增加3倍，解析单个域名耗时最高增加3倍，请关注CoreDNS负载和业务影响。

1.执行kubectl -n kube-system edit configmap coredns命令，打开CoreDNS配置文件。

2.删除autopath @kubernetes一行后保存退出。

3.检查CoreDNS Pod运行状态和运行日志，运行日志中出现reload字样后说明修改成功。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

说明CoreDNS刷新配置过程中，可能会占用额外内存。修改CoreDNS配置项后，请观察Pod运行状态，如果出现Pod内存不足的情况，请及时修改CoreDNS Deployment中容器内存限制，建议将内存调整至2 GB。

控制台操作方式

A.登录容器服务管理控制台。

B.在控制台左侧导航栏中，单击集群。

C.在集群列表页面中，单击目标集群名称或者目标集群右侧操作列下的详情。

D.在集群管理页左侧导航栏中，选择配置管理 > 配置项。

E.在kube-system命名空间下，单击配置项coredns右侧的YAML编辑。

F.参考下列的YAML文件，保证health插件开启，并调整lameduck参数为15s，然后单击确定。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

亲和性配置可能导致CoreDNS不同副本间存在较大负载差异，建议按以下步骤关闭 修改服务kube-dns的yaml配置删除以下所有内容：

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

建议您在部署CoreDNS副本时，应将CoreDNS副本打散在不同可用区、不同集群节点上，避免单节点、单可用区故障。CoreDNS默认配置了按节点的弱反亲和性，可能会因为节点资源不足导致部分或全部副本部署在同一节点上，如果遇到这种情况，请删除Pod重新触发其调度来调整。

CoreDNS所运行的集群节点应避免CPU、内存用满的情况，否则会影响域名解析的QPS和响应延迟。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

建议您在任何情况下设置CoreDNS副本数应至少为2，且副本数维持在一个合适的水位以承载整个集群的解析。

CoreDNS所能提供的域名解析QPS与CPU消耗成正相关，开启缓存的情况下，单个CPU可以支撑10000+ QPS的域名解析请求。不同类型的业务对域名请求的QPS需求存在较大差异，您可以观察每个CoreDNS副本的峰值CPU使用量，如果其在业务峰值期间占用CPU大于一核，建议您对CoreDNS进行副本扩容。无法确定峰值CPU使用量时，可以保守采用副本数和集群节点数1：8的比值来部署，即每扩容8个集群节点，增加一个CoreDNS副本。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

包括且不仅限于以下：

•CoreDNS与APIServer连通性异常（例如APIServer重启、APIServer迁移、网络抖动）时，CoreDNS会因错误日志写入失败导致容器重启。更多信息，请参见Setklog's logtostderr flag。

•启动CoreDNS时会占用额外内存，默认采用的Memory1Limit在较大规模集群下可能触发OOM（OutOfMemory）问题，严重时可能导致CoreDNS1Pod反复重启下可能触发OOM（OutOfMemory）问题，严重时可能导致CoreDNS Pod反复重启无法自动恢复。更多信息，请参见CoreDNS uses a lot memory during initialization phase。

•CoreDNS存在若干可能影响Headless Service域名、集群外部域名解析的问题。更多信息，请参见plugin/kubernetes: handle tombstones in default processor和 Data is not synced when CoreDNS reconnects to kubernetes api server after protracted disconnection。

•在集群节点异常情况下，部分旧版本CoreDNS默认采用的容忍策略，可能会导致CoreDNS Pod部署在异常节点上，且CoreDNS Pod无法被自动驱逐，继而导致域名解析异常。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 亲和以及反亲和要求、数据局部性、负载间的干扰等等 。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。 根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

过滤阶段会将所有满足 Pod 调度需求的节点选出来。 例如，PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。 在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下， 这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

3.3及更早版本Alpine不支持search参数，不支持搜索域，无法完成服务发现。

•并发请求/etc/resolv.conf中配置的多个DNS服务器，导致NodeLocal DNSCache优化失效。

•并发使用同一Socket请求A和AAAA记录，在旧版本内核上触发Conntrack源端口冲突导致丢包问题。

关于以上问题的更多信息，请参见musl libc。

当Kubernetes集群中部署的容器采用了Alpine作为基础镜像时，可能会因为上述musl libc特性而无法正常解析域名，建议尝试更换基础镜像，如Debian、CentOS等。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

DNS域名解析请求是Kubernetes最高频的网络行为之一，其中很多请求是可以优化和避免的。您可以通过以下方式优化域名解析请求：

•（推荐）使用连接池：当一个容器应用需要频繁请求另一服务时，推荐使用连接池。连接池可以将请求上游服务的链接缓存在内存中，避免每次访问时域名解析和TCP建连的开销。

•使用DNS缓存：

•（推荐）当您的应用无法改造成通过连接池连接另一服务时，可以考虑在应用侧缓存DNS解析结果，具体操作，请参见使用节点DNS缓存NodeLocal DNSCache。

•如果NodeLocal DNSCache无法适用的，可以在容器内置NSCD（Name Service Cache1Daemon）缓存。关于如何使用NSCD缓存，请参见在Kubernetes集群中使用NSCD。

•优化resolv.conf文件：由于resolv.conf文件中ndots和search两个参数的机制作用，容器内配置域名的不同写法决定了域名解析的效率，关于ndots和search两个参数的机制详情，请参见DNS原理和配置说明。

•优化域名配置：当容器内应用需要访问某域名时，该域名按以下原则配置，可以最大程度减少域名解析尝试次数，继而减少域名解析耗时。

•Pod访问同命名空间的Service，优先使用< service-name>访问，其中service-name代指Service名称。

• P o d 跨命名空间访问Service ， 优先使用< service- name> . < name -space-name>访问，其中namespace-name代指Service所处的命名空间。

•Pod访问集群外部域名时，优先使用FQDN类型域名访问，这类域名通过常见域名最后加半角句号（.）的方式来指定地址，可以避免search搜索域拼接带来的多次无效搜索，例如需要访问www.aliyun.com，则优先使用FQDN类型域名www.aliyun.com.来访问。"

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

Nginx Ingress Controller整合了阿里云AHAS流量防护的产品功能，可以实现更加精细的流量控制。当有请求流量时，您可以在AHAS控制台中查看Nginx网关请求的实时QPS和RT等数据。具体开启的操作步骤，请参见使用Ingress-sentinel实现流控。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•硬件选型在高并发场景下，Ingress对CPU资源和网络连接数占用都非常高，所以可选增强型ECS实例。

系统选择Aliyun操作系统

阿里云上的操作系统已经默认优化了一些常见参数，其他还需要调优的系统参数主要包括系统最大Backlog数和可用端口的最大范围。系统参数调优后可以保证Nginx处理高并发请求的能力，以及在连接后端时不会因为端口耗尽而失败。

•K8s配置

•设置Ingress Pod独占节点资源

•设置CPU Policy为static。

• 推荐调整ingress-controller1service对应的SLB规格为超强型（slb.s3.large）。

•推荐集群使用Terway网络插件及配置独占ENI。

•Ingress配置

•设置Ingress Pod为Guaranteed类型。

•设置nginx-ingress-controller1container的资源限制requests和limits：15 Core 20 GiB。

•设置initContainer init-sysctl的资源限制requests和limits：100 m 70 MiB。

•删除Ingress Pod中的podAntiAffinity，使一个节点上可调度两个Pod。

•调整Deployment Replicas数为新增节点数的2倍。

•设置ConfigMap的worker-processes数为15（预留部分给系统使用）。

•调整ConfigMap的keepalive链接最大请求数。

•关闭日志访问记录。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

也可以配置HPA对Ingress Controller进行扩容。具体操作，请参见容器水平伸缩（HPA）。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

Nginx Ingress Controller提供了基于SLS日志以及Prometheus的监控大盘，帮助您更好地了解您的业务的流量情况。

•SLS日志：

•创建集群时，如果您已经选中了启用日志组件及Ingress Dashboard，您就可以直接通过容器服务管理控制台网络 > 路由页面的Ingress概览中查看到基于SLS日志服务提供的大盘服务，您也可以直接在运维管理 > 日志中心查看到Nginx Ingress Controller产生的相关日志。具体操作，请参见Ingress访问日志分析与监控。

•如果您在创建时没有选中日志以及Ingress的相关选项，也可以手动配置日志收集组件和规则。具体操作，请参见Ingress访问日志分析与监控。关于监控的更多信息，请参见Ingress Dashboard监控。

•ARMS Prometheus监控：ARMS Prometheus监控可以在创建集群时选择安装，或者在创建集群后通过运维管理 > Prometheus监控安装或查看。具体操作，请参见ARMS Prometheus监控。说明 使用ARMS Prometheus监控时，请为集群中的Ingress资源添加host字段，否则在默认情况下，该Ingress的部分metrics将会缺失。您也可以通过在Nginx Ingress Controller的Deployment中修改controller启动参数，加入--metrics-per-host=false来解决该问题。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

Nginx Ingress Controller提供了对WebSocket的原生支持，您不需要进行任何配置即可转发WebSocket连接。如果您有持续较长的WebSocket连接，可以通过Annotation适当地调整后端连接的超时时间，防止业务因为超时而断连。关于调整的具体操作，请参见Custom timeouts。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

gRPC仅支持通过TLS端口访问。因此，请确保您的业务通过NginxIngress Controller访问gRPC服务时，使用的是加密的TLS端口。关于配置gRPC的具体操作，请参见通过Ingress Controller实现gRPC服务访问。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

针对使用HTTPS的后端服务，您可以在Ingress中添加nginx.ingress.kubernetes.io/backend-protocol:"HTTPS"的Annotation切换为HTTPS连接。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

请确保Nginx Ingress Controller分布在不同的节点上，避免不同Nginx Ingress Controller之间资源的抢占和单点故障。您也可以为其使用独占节点来保证性能与稳定性，具体操作，请参见使用独占节点保证Nginx Ingress性能与稳定性。同时建议您不要为Nginx Ingress Controller设定资源限制，避免OOM所带来的流量中断。如果确实有限制的需要，建议资源限制CPU不低于1000 Milicore（YAML配置里格式为1000m）和内存不低于2 GiB。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

Nginx Ingress Controller 默认使用HTTP协议连接到后端服务，但同时提供了对多种后端协议的支持，其中比较常用的协议有WebSocket、HTTPS和gRPC。关于支持的后端协议具体类型，请参见Backend Protocol。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

过滤和打分。

过滤阶段会将所有满足 Pod 调度需求的节点选出来。 例如，PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。 在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下， 这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。

在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。 根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。

最后，kube-scheduler 会将 Pod 调度到得分最高的节点上。 如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

会触发内存子系统（Memcg）级别的直接内存回收，阻塞进程执行。如果此时的内存申请速度超过回收速度，容器会触发OOMKilled并释放内存。应用管理员可能会调高应用的内存Limit，以降低Pod OOM等风险，但这也导致整机内存的Limit之和可能超出物理容量，即处于内存超卖状态。超卖状态下，某个Pod大量申请内存，可能造成整机内存不足，导致其他Pod申请内存时触发整机内存回收或OOM（Kubernetes默认不启用Swap），进而影响应用表现。在上述两种情形中，个别Pod可能影响其他Pod的内存访问性能，即使这些Pod的内存使用未超过Request声明，应用性能仍会受到较大影响。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

这是因为对于k8s来说， 在删除过程中需要对多个对象（如 Endpoint、ipvs/iptables、SLB）进行状态同步，这些同步操作是异步执行的。在pod被删除的时候，pod会被置于terminating状态，从相关的svc移除，不再承接新流量，但是依然可以处理老的流量请求。但是由于是异步进行的，所以存在相关pod已经收到了SIGTERM的信号，被终止，但是还未被从SLB后端移除，造成了流量被发送到了deleted的pod上，所以针对这种情况，建议使用PreStop，使pod收到了SIGTERM后不要马上终止，确保被SLB转发而来的流量请求依然可以被处理。 但是需要注意PreStop的时间不可以超过 terminationGracePeriodSeconds，如果到达了 terminationGracePeriodSeconds 时间，PreStop还未执行完毕，pod依然会被马上强制终止。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 Pod 的标签来约束Pod 可以调度到的节点，而不是基于节点上的标签，比如将两个服务的 Pod 放到同一个云提供商可用区内，因为它们彼此之间通信非常频繁 。

•Pod 间亲和性和反亲和性都需要相当的计算量，因此会在大规模集群中显著降低调度速度。 我们不建议在包含数百个节点的集群中使用这类设置。

•Pod 反亲和性需要节点上存在一致性的标签。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

自身内存限制：当容器自身的内存（含Page Cache）接近容器上限时，会触发内核的内存回收子系统，这个过程会影响容器内应用的内存申请和释放的性能。

节点内存限制：当容器内存超卖（Memory Limit>Request）导致整机内存不足，会触发内核的全局内存回收，这个过程对性能影响较大，极端情况甚至导致整机异常

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

这是因为对于k8s来说，pod running后，就会被加到svc的后端，也就是SLB的后端中，此时如果pod 内承接业务请求的应用还未就绪，那么就会引起相关的业务中断。所以需要给pod设置相关的readiness探针，让pod内的应用完全就绪后才会被加入到svc后端中。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

nodeselector是节点选择的最简单推荐形式。可以使用 nodeSelector 字段将pod调度到指定的节点标签的节点上。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

有时候需要某一类别的pod根据业务需求部署到指定的节点池或者可用区，或者需要部署到指定标签的节点上，那么就需要使用节点的亲和性。

•requiredDuringSchedulingIgnoredDuringExecution： 调度器只有在规则被满足的时候才能执行调度。

•preferredDuringSchedulingIgnoredDuringExecution： 调度器会优先尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。

•在上述类型中，IgnoredDuringExecution 意味着如果节点标签在 Kubernetes调度 Pod 时发生了变更，Pod 仍将继续运行。

•同时指定了 nodeSelector 和 nodeAffinity，两者必须都要满足， 才能将 Pod调度到候选节点上。

•指定了多个与 nodeAffinity 类型关联的 nodeSelectorTerms， 只要其中一个nodeSelectorTerms 满足的话，Pod 就可以被调度到节点上。

•指定了多个与同一 nodeSelectorTerms 关联的matchExpressions， 则只有当所有 matchExpressions 都满足时 Pod 才可以被调度到节点上。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

调度器通过 Kubernetes 的监测（Watch）机制来发现集群中新创建但是未被调度到节点上的 Pod。 对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler会选择一个最优的节点去运行这个 Pod。 然而，Pod 内的每一个容器对资源都有不同的需求， 而且 Pod 本身也有不同的需求。因此，Pod 在被调度到节点上之前根据这些特定的调度需求，需要对集群中的节点进行一次过滤。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

在一个集群中，满足一个 Pod 调度请求的所有节点称之为可调度节点。如果没有任何一个节点能满足 Pod 的资源请求， 那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•Guaranteed（优先级最高）：

Pod中每个容器都必须包含内存和CPU的request和limits；

request和limits需要相等；

•Burstable：

Pod不符合Guaranteed的QoS

Pod中至少一个容器具有内存和CPU的request或limits

•BestEffort（优先级最低）：

Pod中的容器没有设置内存和CPU的request或limits

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•它们总是运行到完成。

•每个都必须在下一个启动之前成功完成。

•同时 Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startup-Probe， 因为它们必须在 Pod 就绪之前运行完成。(如上图所示)

•如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

•基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源，这些资源在 Pod 生命周期过程中并没有被使用。

•Pod 的 有效 QoS 层 ，与 Init 容器和应用容器的一样。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 ""Never""，并且 Pod 的 Init 容器失败， 则Kubernetes 会将整个 Pod 状态设置为失败。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

可以开启同步加速功能：https://help.aliyun.com/document_detail/414209.html"

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。

•Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

•应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

•Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 应用容器不能访问的 Secret 的权限。

•由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod内的所有的应用容器会并行启动。

•init 容器具有特权权限，应用容器一般情况下是没有此权限的，可以使用init 容器完成一些特权操作。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

每个运行中的进程都有一个称为OutOfMemory（OOM）分数的值。系统通过比较所有运行进程的OOM分数来选择要杀掉的进程。

当需要释放内存时，分数最高的进程将被杀死。 OOM分数由两个参数计算得出：进程已消耗内存占可用内存的百分比，与一个基于pod QoS等级和容器内存申请量固定的OOM分数调节因子。对于两个属于Burstable等级的单容器的pod，系统会杀掉内存实际使用量占内存申请量比例更高的pod。这就是上图中使用了内存申请量90% 的pod B在pod C（只使用了70%）之前被杀掉的原因，尽管pod C比pod B使用了更多兆字节的内存。

这说明我们不仅要注意requets和limits之间的关系，还要留心requests和预期实消耗内存之间的关系。

既然上面已经提到了相关的request和limits，及时节点上所有的pod都设置了limits，也建议一个节点上的limits不要超卖太多，以防大部分pod在同一时间承受高业务流量，造成节点上的资源被打满，或者把业务高峰期的pod错开放置在不同节点上，以实现资源利用最大化同时，不影响节点上的其他应用，这个需要在应用部署的时候结合业务行为指定部署的最优解。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

节点上所有的limits总和允许大于ECS的分配资源，但是request一定是小于ECS的分配资源。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

•在Kubernetes资源（例如无状态应用Deployment）模板中配置拉取凭证（image-PullSecret）会导致免密组件失效，如果需使用免密组件，请避免手工配置拉取凭证（imagePullSecret）。

•如果部署的Kubernetes资源（例如无状态应用Deployment）使用了自定义的ServiceAccount，需先调整免密组件配置文件中Service-Account字段，使其作用于自定义的ServiceAccount，再进行部署资源操作。

•确认Kubernetes集群所属地域与要拉取的镜像所在的地域是否一致，默认配置只可以拉取本地域的镜像。如果需要跨地域拉取镜像，请参考下面的配置。（仅适用于公网拉取）

•使用自定义RAM角色的AccessKey ID和AccessKey Secret进行镜像拉取的情况下，需要把访问密钥写入configMap，这样存在一定的密钥泄露风险。请确定AccessKey ID和AccessKey Secret所属的RAM角色只拥有拉取容器镜像的相关权限。

•在集群中创建新的Service Account一段时间后，免密插件根据ACK集群默认权限生成的ACR私有镜像拉取Token才会更新到应用使用到的Service1Account中，使用Service Account的应用才会使用Token去拉取镜像。如果创建完Service Account之后立即创建应用则会出现因鉴权失败无法拉取的情况。

•免密插件默认覆盖ACK中所有命名空间中默认的ServiceAccount中的imagePullSecret字段。被覆盖的ServiceAccount会随着对应kube-system命名空间中acr-configuration配置项中的service-account字段变动而变动。(见上图)。

•在修改kube-system命名空间中的acr-configuration配置项时，请确认缩进是否与给出的场景的例子相同。建议直接复制对应场景的YAML内容到编辑器中，修改对应的值然后直接应用到集群，以保证YAML格式的正确性。

•企业版实例创建后，默认不允许通过公网访问。因此在配置公网的访问控制策略前， 需要先打开公网的访问入口。在打开访问入口之后， 会默认生成一条127.0.0.1/32的公网白名单。如果删除所有白名单，可以认为放开所有的公网机访问ACR实例。

•镜像太大，造成每次部署时候拉取速度慢，以及传统容器运行需要将全量镜像数据下载后再解包，然而容器启动可能仅使用其中部分的内容，导致容器启动耗时长。此种场景可以考虑P2P加速和按需加载容器镜像。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

目前由于oss内网网段的限制，无法实现通过CEN，高速通道或VPN打通三种域名的方式实现跨地域跨VPC方式访问。需要通过在不同地域建立不同的ACR企业版实例+镜像分发的方式实现镜像的跨地域和跨账号的同步以及内网访问：

同账号同步实例：https://help.aliyun.com/document_detail/147064.html

跨账号同步实例：https://help.aliyun.com/document_detail/305586.html

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

可以采用配置专有网络的访问控制+PrivateZone的方式，实现同地域下ACR企业版实例接入不同的VPC网络配置专有网络访问控制：

https://help.aliyun.com/document_detail/142199.html

配置专有网络访问控制：https://help.aliyun.com/document_de-tail/142199.html

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版

需要获取OSS Bucket、容器镜像服务企业版实例和鉴权服务在VPC中的IP，根据获取的IP在本地数据中心创建路由规则。

•获取OSS Bucket在VPC中的域名。关于OSS内网域名的更多信息，请参见OSS内网域名与VIP网段对照表。

•OSS Bucket在VPC中的域名为${InstanceId}-registry.oss-${RegionId}-internal.aliyuncs.com （ 如果您使用的是自定义OSS Bucket，则域名为${CustomizedOSSBucket}.oss-${RegionId}-internal.aliyuncs.com）

•获取容器镜像服务企业版实例在VPC中的域名。

•容器镜像服务企业版实例在VPC中的默认域名为${InstanceName}-registry-vpc.${RegionId}.cr.aliyuncs.com 。

•获取鉴权服务在VPC中的域名。

•执行以下命令，获取鉴权服务在VPC中的域名。

•curl -vv https://${InstanceName}-registry-vpc.${RegionId}.cr.aliyuncs.-com/v2/

•获取配置路由规则的IP。

以上内容摘自《企业级云原生白皮书项目实战》电子书，点击https://developer.aliyun.com/ebook/download/7774可下载完整版