周一见 | Docker 受限“实体清单”微服务测试要点kubectl 常用命令和技巧

Posted 2021-03-31 K8sMeetup社区

技术校对：星空下的文仔（才云）、bot（才云）

本周新闻

1. Docker 受限“实体清单”

2. 微服务测试要点

3. 服务网格漫画图解

4. kubectl 常用命令和技巧

5. K8s 的挑战和应对方法

6. 本周 K8s 开源项目推荐

本文共计 3170 字，阅读大约需要 5 分钟

1

Docker 受限“实体清单”

Docker 公司最新的服务条款于 8 月 13 日生效，其中服务条款 1.2 显示：禁止美国被拒绝人清单和被拒绝贸易方清单上的人或组织使用该服务。

这简单来说就是， Docker 公司提供的服务，禁止美国“实体清单”上的实体使用。 目前中国 IT 行业被美国列入贸易管制“实体清单”的企业包括华为、商汤科技、依图、旷视、海康威视、科大讯飞、奇虎 360、东方网力、云从科技、中科曙光与海光等。

从服务条款中，我们可以明确得知 Docker 商业版及 Docker 的其它服务，比如 Docker Hub，将受到限制。那么，Docker 开源项目是否还能使用？

8 月 16 日，Linux 基金会亚太区首席战略官 Keith 在社交媒体平台表示：

美国出口管制的事，开源不受影响，Docker 开源版可以继续使用，受影响的是商业版。

另外，国内有关专家表示，对于使用 K8s 外企发行版的企业，最好使用国产版本，以避免由于意外情况而正常使用。

目前该事件已经引起热议，后续有新进展 K8sMeetup 社区会第一时间播报。

2

微服务测试要点

做好微服务和模块化应用程序的测试非常重要也非常有挑战，因为我们必须确保容器中的微服务运行良好，但又不能依靠传统测试测量来完成工作。

微服务注意事项

如果以传统方式测试应用程序，那么我们要以与生产环境相匹配的方式配置测试环境，再设置应用程序所有组件，这样一来，需要花费大量时间，并且整个过程非常复杂。

而在容器中运行微服务具有一个特别的优势：通用兼容性，因此我们不必将测试环境与部署架构完全匹配，在某些情况下，甚至可以测试单个组件。

这里有几个测试微服务时的注意事项：

• 微服务依赖于网络通信来相互通信，因此必须测试网络可靠性和要求。
• 自动化和基础结构元素现在可作为代码添加，我们要确保微服务在通过管道推送时，它们也能正常运行。
• 尽管容器化是通用的，但我们仍然必须注意特定的依赖性，最好创建一个测试策略以包含这些依赖性。

几种测试方法

微服务测试并不简单，但如果我们做好了正确的策略，这对我们会非常有帮助。这里介绍了几种微服务测试方法:

• 单元测试 ：这允许开发人员以细粒度的方式测试微服务。它不仅将测试限制在单个微服务上，还允许开发人员采用更细粒度的方法。
• 集成测试 ：这是以交互方式处理微服务的测试。部署微服务需要彼此合作，集成测试是确保微服务能够实现的关键过程。

• 端到端测试：这是将微服务作为完整的应用程序进行测试。这种类型的测试可以测试功能、UI、通信和其他构成应用程序的组件。

3

服务网格图像解释

Kubernetes 拥有着 Pod、Deployment、Service、Ingress 控制器等“工具”，帮助我们轻松部署服务，并按照我们的想法进行合理扩展。

现在，我们的集群快速成长，拥有着大量服务，并进行着复杂的互相通信以满足服务请求，而服务网格，就可以帮助我们管理和控制它们之间的流量。

关键“器官”

Sidecar Proxy

Sidecar Proxy 可以帮助我们拦截网络流量，有时候还会对其进行修改。

自定义资源（CRD）

Kubernetes 提供了自定义资源（类似于 Service、Pod，Deployment、ReplicaSet 等）的能力，我们可以使用 kubectl 命令与这些资源进行交互。几乎所有的服务网格都能创建自定义资源，以管理和控制创建的组件。

Kubernetes Operator

Operator 像是 Kubernetes 自动化机器人。服务网格可以根据集群中发生的事件，使用不同的 Operator 以自动执行要采取的措施。

如何管理流量

服务网格就像 Kubernetes 创建和部署我们的应用程序一样管理应用程序流量。服务网格会将 Sidecar Proxy 注入到 Pod 中，以便流入所有网络流量。

安全通讯

手动设置相互 TLS 身份验证并不简单，因为它涉及配置证书和集群中每个参与服务发送的证书签名请求，但是，如果我们借助 Sidecar Proxy，可以在一个地方处理该问题。

网络监控

Sidecar Proxy 可以将有关目标服务的信息发送到 Prometheus 等监视服务器，以了解流量流模式。由于这是在 Sidecar 级别完成的，因此实际的应用程序可能会对此一无所知。

Traffic management

我们还可以根据在 Sidecar Proxy 级别配置的规则将流量路由到不同版本的 Service 中。下图中，“/svc-b/ user”的所有请求将到达 Service B 的 V1，而对相同服务但不同端点“/svc-b/order”的所有请求将到达 Service B 的 V2。这可以用于 AB 测试和金丝雀发布。

4

kubectl 常用命令和技巧

kubectl 是重要的 Kubernetes 命令行工具，可让我们对集群运行命令。以下就罗列了常用的一些命令和技巧。

获取 Pod 和节点列表

获取所有未运行的 Pod（即状态不为 Running 的）：

kubectl get pods -A --field-selector=status.phase!=Running | grep -v Complete

获取节点列表及其内存大小：

kubectl get no -o json |    jq -r '.items | sort_by(.status.capacity.memory)[]|[.metadata.name,.status.capacity.memory]| @tsv'

获取节点列表和在其上运行的容器的数量：

kubectl get po -o json --all-namespaces |    jq '.items | group_by(.spec.nodeName) | map({"nodeName": .[0].spec.nodeName, "count": length}) | sort_by(.count)'

用  kubectl top  获取消耗 CPU 和内存资源的 Pod 列表：

        
          
          
        

         
           
           
         # cpu
         
           
           
         kubectl top pods -A | sort --reverse --key 3 --numeric
         
           
           
         # memory
         
           
           
         kubectl top pods -A | sort --reverse --key 4 --numeric
        
          
          
        

网络

获取集群节点的内部 IP 地址：

kubectl get nodes -o json |    jq -r '.items[].status.addresses[]? | select (.type == "InternalIP") | .address' |   paste -sd "
" -

打印 Service 以及各自的 nodePort：

kubectl get --all-namespaces svc -o json |     jq -r'.items [] | [.metadata.name，（[[。spec.ports []。nodePort | tostring] | join（“ |”））]] | @tsv'

日志

打印带有时间戳的日志：

kubectl -n my-namespace logs -f my-pod --timestamps2020-07-08T14:01:59.581788788Z fail: Microsoft.EntityFrameworkCore.Query[10100]

打印 Pod 的部分日志，只需要用  --tail :

        
          
          
        

         
           
           
         kubectl -n my-namespace logs -f my-pod --tail=50
        
          
          
        

打印所有容器中的日志：

        
          
          
        

         
           
           
         kubectl -n my-namespace logs -f my-pod --all-containers
        
          
          
        

其他常用命令

将 secret 从一个命名空间复制到另一命名空间空间：

        
          
          
        

         
           
           
         kubectl get secrets -o json --namespace namespace-old | 
         
           
           
          jq '.items[].metadata.namespace = "namespace-new"' | 
         
           
           
          kubectl create-f -
        
          
          
        

另外，这是 Kubernetes 文档里的 kubectl 备忘单：https://kubernetes.io/docs/reference/kubectl/cheatsheet/

5

K8s 的挑战和应对方法

Kubernetes 是当今容器编排的事实标准，受到了广大企业的热捧，据 Gartner 预测，2023 年全球 70％ 以上的企业将运行两个或两个以上的容器化应用程序。但使用 Kubernetes 并不是一件简单的事情，以下是使用 Kubernetes 要注意的几个要点。

掌握 Kubernetes 复杂性

如果我们要部署完整的 K8s 基础架构，那么要配置的组件数量会非常多，部署过程比较困难，因此我们最好：

• 应用适当的 DNS 设置。
• 管理负载均衡。
• 设置资源约束：在容器、节点以及甚至命名空间级别定义资源约束。
• 管理 K8s RBAC：对跨 Pod、节点集群、命名空间定义和配置“角色”要做好详细规划。

加强 Kubernetes 安全性

在 K8s 环境中实施安全性需要考虑到，微服务的大量部署会导致的攻击面增加。K8s 非常易于部署，但如果我们不严格管理和控制，就会导致大量漏洞的产生。以下是我们需要考虑的安全性要素：

• 镜像完整性。
• 节点访问。
• 网络分段以及隔离。
• API 管理。
• Ingress 和 Egress IAM。

这些要素组合起来的复杂性常常被大家低估，并导致了许多安全漏洞，我们可以采用一些最佳实践来安全地使用 K8s：

• 运行非根容器： 如果出现破坏，根容器会提高横向移动的风险。
• 实施 RBAC： 正确配置RBAC策略，可以最大程度地提高安全性。
• 实施全面的测试过程： 在生产中进行部署之前，必须系统地运行包括功能测试、用户测试和负载测试在内的全面测试。
• 配置 CI/CD 管道： 正确配置 CI/CD 管道对于提高质量和安全性，以及加快应用程序发布速度至关重要。
• 注册表和 Deployment 管理： 确保将 Docker 镜像安全地存储在私有注册表服务器中，我们可以启用镜像管理工作流。
• 使用 Pod 安全策略（PSP）。
• 镜像扫描： 在使用外部图像之前，我们最好对其进行扫描，资源可降低引入漏洞的风险。

• 使用服务网格：服务网格有助于确保通信经过授权、认证，从而确保通信安全。

6

本周 K8s 开源项目推荐

Krane

• 它是一个简单的 Kubernetes RBAC 静态分析工具，可以检查 K8s RBAC 设计中的潜在安全风险，并提出相关建议。
• github.com/appvia/krane

kubeletctl

• 它是一个可以实现 kubelet API 的命令行工具。
• github.com/cyberark/kubeletctl

Kip

• Kip 是一个虚拟 Kubelet 提供程序，Kid Pod 在集群上运行，并在集群上创建一个虚拟 Kubernetes 节点。
• github.com/elotl/kip

KubiScan

• 它可以在 Kubernetes RBAC 授权模型中扫描集群是否存在危险权限。
• github.com/cyberark/KubiScan

cluster-turndown

• 它可以基于自定义计划和关闭条件对 Kubernetes 集群的备份节点进行自动伸缩。
• github.com/kubecost/cluster-turndown

sinker

• 它将容器镜像从一个注册表同步到另一个。

• github.com/plexsystems/sinker

推荐阅读：

在看点一下