English日本語
1. Linkerd 2.3正式颁布
Linkerd 2.3正式颁布，为Kubernetes提供零接触、零信赖网络，标志取mTLS已经由尝试环境正式成长为一项全面支持职能，同时带来一系列沉要的安全基元。最沉要的是，Linkerd 2.3在默认设置下即可在网格服务之间提供经过身份验证的保密通讯能力。
；じ鱇ubernetes服务之间的通讯内容，是实现零信赖网络系统的沉要一步。在零信赖步骤傍边，Linkd不再对数据中心安全天堑做出各种不切现实的如果，而是将与身份验证、授权以及机密性有关的要求“落地”至各个单元。在Kubernetes术语傍边，这意味着上述要求将运行在各集群内以验证、授权并加密对应通讯内容。
实现流程描述：
1) 节造平面中附带证书宣告机造（简称为「身份」）。
2) 数据平面各代理从身份服务处接管TLS证书，该证书与代理所归属的Kubernetes服务账户绑定，且每24幼时进行一次轮换。
3) 数据平面各代理睬自动对网格服务间的通讯进行升级，从而利用证书实现TLS衔接的验证与加密。
由于节造平面同样运行在数据平面之上，因而节造平面各组件之间的通讯也将以同样的方式得到；。
以上提到的所有都将默认启用，不必要额表配置；谎灾，从2.3版本起头，Linkerd将为全数网格服务之间提供经过加密以及身份验证的通讯通路。固然单凭这一次升级还无法实现Kubernetes中成立零信赖网络的全数要求，但这依然是一次沉要的初步与尝试。
2. Fluentd 从 CNCF 毕业
CNCF（云原生推算基金会）在美国功夫 2019 年 4 月 11 日颁发 Fluentd 正式毕业了。这是从 CNCF 毕业的第 6 个项目，之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 、CoreDNS 和 containerd。
Fluentd 自 2011 年由 Treasure Data 公司的结合首创人 Sadayuki “Sada” Furuhashi 创建，作为构建统一纪录层的开源数据网络器，统一纪录层，统一网络采集和消费，以便更好的使用和理解数据。在 2016 年 11 月，Fluentd 也是第 6 个成为 CNCF 托管项主张。
Fluentd 能够从多种数据源采集事务，并将它写入文件，RDBMS，NoSQL，IaaS，SaaS，Hadoop 等等各类的指标地址。
3. Google颁布Cloud Run和Traffic Director
在上周于旧金山进行的 Google Cloud Next 2019 大会上，Google Cloud 正式颁布了Cloud Run和Traffic Director。
Cloud Run是业界第一个基于Knative + Kubernetes + gVisor系统的Serverless 服务。允许开发者在齐全受治理的无服务器执行环境中，运行无状态 HTTP 驱动的容器。它掌管所有基础架构，涵盖配置、扩大和服务器治理，其可能在‘几秒钟内’自动向上或向下扩大、甚至将资源占用降低为零，因而用户只需为现实使用的资源而付费。Cloud Run 同时提供全托管和GKE两种部署模式，在全托管模式中基于knative 在Google的内部实现和gVisor安全容器运行，GKE模式中则齐全基于开源knative来实现。两个knative实此刻API层一致。
此表，Cloud Run的计费模型也颇具创新性：它不是齐全依照工作数和资源收费，而是将所有并发的要求算在一个计费单元内，这有望大大减低用户必要支付的成本。
Traffic Director是一个与 AWS App Mesh 对标的 Service Mesh 产品。Traffic Director 通过 xDS 和谈与数据平面的 Envoy 进行通讯，可别离与 Google Cloud 的MIG和NEG两款产品结合去提供 Service Mesh 的能力。Traffic Director的职能与开源Istio项目中的 Pilot-discovery 类似，也复用了Istio 的不少技术实现（好比，通过 iptables 实现流量通明拦截）。Traffic Director 支持全球负载平衡、集中式的集群健全查抄、流量驱动的自动扩缩容等职能，援手客户在全球部署与治理高弹性的无状态利用。
4. 开源项目Kubecost
大无数Kubernetes治理工具都侧沉于易用性，监控，对pod行为的洞察等。但是若何监控与运行Kubernetes有关的成本?
Kubecost可能依照 Kubernetes的原生 API,好比 Pod，Deployment，Service，Namespace 等概想逐层监控并具体的推算和展示出每一层上你的真实破费。更沉要的是，无论你基层用的是 AWS 还是 GCP，Kubecost 内置的成本模型都能够应对自若。
如使用实时Kubernetes指标以及从重要云提供商上运行的集群派生的现实成本信息，以提供每个集群部署的每月成本的仪表板视图。内存，CPU，GPU和存储的成本都由Kubernetes组件(容器，容器，服务，部署等)分化。
Kubecost还能够跟踪“群集表”资源(例如S3存储桶)的成本，只管目前仅限于AWS。成本数据甚至能够共享回Prometheus，因而能够使用数据以编程方式更改群集行为。
5. kubernetes近期缝隙
CVE-2019-1002101 kubectl cp缝隙
近期kubernetes的kubectl cp号令发现安全问题(CVE-2019-1002101)，该问题严沉水平比力高，建议将kubectl升级到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解决此问题。
kubectl cp号令允许用户在容器和主机之间复造文件，其根基道理是：
1) 在源地址将文件打包。
2) 打包输出内容作为stream流通过网络传递给指标地址。
3) 传递蹊径蕴含：apiserver、kubelet、runtime
4) stream流在主张地址作为tar的输入，解压。
具体执行过程能够参考kubernetes/pkg/kubectl/cmd/cp.go文件中的copyToPod和copyFromPod两个函数。
在这个过程中，若是容器中的tar二进造文件是恶意的，它能够运行任何代码并输出意表的恶意了局。当挪用kubectl cp时，攻击者能够使用它将文件写入用户推算机上的任何蹊径，仅受本地用户的系统权限限度。
Kube-proxy IPVS增长flag ipvs-strict-arp
kube-proxy的ipvs模式会将clusterIP/externalIP等绑定到节点上名为kube-ipvs0的dummy设备，以确保节点上的ipvs规定能够对接见这些地址的流量作转发。
在1.13版本中，引入一个操作
echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
以不容IPVS模式下对kube-ipvs0 dummy设备上绑定的ip的ARP回复，具体可参考pr #70530，该扭转是为了建复ipvs模式下load banlancer类型service不能正常使用的问题(issue:#59976)。
而本次的buf fix则是跟前面的扭转有关，由于前面的扭转固然解决了loadbalancer的问题，但是又引入了其他问题：有些CNI插件在主机和容器间的衔接会用到ARP和谈。因而我们看到有些用户升级到1.13后反馈下面的问题：
issue#72779：kube-proxy v1.13.0 and 1.13.1 brokes services with externalIPs
issue#71555：kube-proxy/IPVS: arpignore and arpannounce break some CNI plugins
而本bug fix也很单一，就是为kube-proxy加了一个启动参数ipvs-strict-arp，默以为0，即不扭转节点上的ARP配置，若是必要扭转，则设置该参数值为1。
CVE-2019-3874
这个安全缝隙最早由红帽的工程师Matteo Croce，Natale Vinto和Andrea Spagnolo发现。当Kubernetes中的Pod以Root用户运行时，它能够绕过cgroup内存隔离，通过SCTP网络传输，创建一个潜在的DoS攻击，此问题自身与Kubernetes无关，但是涉及到Kubernetes挪用的内核？。问题的严沉性被界说为中等，社区建议将SCTP内核？榱腥牒诿ダ炊惚艽宋侍。用户能够通过执行如下号令来测试是否会到此类攻击。
modprobe sctp; lsmod | grep sctp
用户能够通过执行如下号令来把SCTP列入内核？榈暮诿。
echo "install sctp /bin/true" > /etc/modprobe.d/sctp.conf
Copyright ? 沙巴 版权所有 京ICP备05032414号 
京公网安备11010802024551号
