KCNA考试第五章：kubernetes学习实践(2)-阿里云开发者社区

7. 网络

由于大量的Pods需要大量的手工网络配置，我们可以使用Service和Ingress对象来定义和抽象网络

ClusterIP

最常见的服务类型。ClusterIP是Kubernetes内部的一个虚拟IP，可以作为一组pods的单个端点使用。这种服务类型可以用作轮询负载均衡器。

NodePort

NodePort服务类型通过添加简单的路由规则扩展了ClusterIP。它在集群中的每个节点上打开一个端口(默认在30000-32767之间)，并将其映射到ClusterIP。这种服务类型允许将外部流量路由到集群。

loadbalance

LoadBalancer服务类型通过部署外部LoadBalancer实例来扩展NodePort。只有当你在一个有API来配置LoadBalancer实例的环境中，比如GCP、AWS、Azure甚至OpenStack，这才会起作用。

ExternalName

一种没有任何路由的特殊服务类型。ExternalName使用Kubernetes内部DNS服务器创建DNS别名。您可以使用它创建一个简单的别名来解析一个相当复杂的主机名，比如:my-cool-database-az1-uid123.cloud-provider-i-like.com。如果您想从Kubernetes集群获取外部资源，这一点尤其有用。

ClusterIP、NodePort和LoadBalancer相互扩展

如果需要更大的灵活性来公开应用程序，可以使用Ingress对象。入口提供了一种从集群外部为集群内的服务公开HTTP和HTTPS路由的方法。它通过配置路由规则来实现这一点，用户可以通过入口控制器设置和实现路由规则。

一个Ingress将所有流量发送到一个Service的例子，从Kubernetes文档中获取

入口控制器的标准特性可能包括:

LoadBalancing

TLS offloading/termination

Name-based virtual hosting

Path-based routing

许多入口控制器甚至提供了更多的功能，比如:

Redirects

Custom errors

Authentication

Session affinity

Monitoring

Logging

Weighted routing

Rate limiting.

Kubernetes还提供了一个具有NetworkPolicy概念的集群内部防火墙。NetworkPolicies是一个简单的IP防火墙(OSI三层或四层)，可以基于规则控制流量。您可以为传入(进入)和传出(出口)流量定义规则。NetworkPolicies的一个典型用例是限制两个不同名称空间之间的流量。

交互式教程-展示你的应用程序

现在，您可以在Kubernetes文档提供的交互式教程的第4部分中了解如何使用Service公开应用程序

7.1 demo

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

$ k apply -f nginx-deployment.yaml
$ k expose deployment nginx-deployment 80
$ k get svc
NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
kubernetes              ClusterIP      10.96.0.1        <none>        443/TCP                      51d
nginx-deployment        ClusterIP      10.101.106.248   <none>        80/TCP                       8s
$ curl 10.101.106.248:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

8. Volume & Storage

如前所述，在设计容器时并没有考虑到持久存储，特别是当存储跨越多个节点时。Kubernetes介绍了一些解决方案，但请注意，这些解决方案并没有自动消除使用容器管理存储的所有复杂性。

集装箱已经有了安装卷的概念，但由于我们没有直接使用集装箱，Kubernetes将卷作为Pod的一部分，就像集装箱一样。

下面是一个hostPath卷挂载的例子，类似于Docker引入的主机挂载:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory

卷允许在同一个Pod中的多个容器之间共享数据。当您想要使用侧车模式时，这个概念允许极大的灵活性。它们的第二个用途是在Pod崩溃并在同一节点上重新启动时防止数据丢失。pod以干净的状态启动，但所有数据会丢失，除非写入卷。

不幸的是，包含多个服务器的集群环境在持久性存储方面需要更多的灵活性。根据环境的不同，我们可以使用像Amazon EBS、谷歌Persistent Disks、Azure Disk storage这样的云块存储，也可以使用像Ceph、GlusterFS这样的存储系统或更传统的系统，比如NFS。

这些只是Kubernetes中可以使用的存储的几个例子。为了让用户体验更加统一，Kubernetes使用了容器存储接口CSI (Container Storage Interface)，它允许存储供应商编写一个可以在Kubernetes中使用的插件(存储驱动程序)。

为了使用这个抽象，我们还有两个可以使用的对象:

PersistentVolumes (PV)

存储片的抽象描述。对象配置包含卷的类型、卷大小、访问模式和唯一标识符以及如何挂载它的信息。

PersistentVolumeClaims (PVC)

用户对存储的请求。如果集群有多个持久化卷，用户可以创建一个PVC，根据用户的需要预留一个持久化卷。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity:
    storage: 50Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  csi:
    driver: ebs.csi.aws.com
    volumeHandle: vol-05786ec9ec9526b67
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: centos
      command: ["/bin/sh"]
      args:
        ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: ebs-claim

这个例子展示了一个PersistentVolume，它使用了一个使用CSI驱动程序实现的AWS EBS卷。在配置了PersistentVolume之后，开发人员可以使用PersistentVolumeClaim来预留它。最后一步是在Pod中使用PVC作为卷，就像我们之前看到的hostPath示例一样。

可以直接在Kubernetes中操作存储集群。像Rook这样的项目提供云本地存储业务编排，并与经过实战测试的存储解决方案(如Ceph)集成。

Rook架构，从Rook文档中检索

9. 配置对象

12因素应用程序建议将配置存储在环境中。但这到底是什么意思呢?运行应用程序需要的不仅仅是应用程序代码和一些库。应用程序有配置文件，连接到其他服务、数据库、存储系统或缓存，这需要像连接字符串这样的配置。

将配置直接合并到容器构建中被认为是不好的做法。任何配置更改都需要重新构建整个映像，并重新部署整个容器或吊舱。当使用多个环境(开发、登台、生产)并为每个环境构建映像时，这个问题只会变得更糟。12因素应用程序更详细地解释了这个问题:Dev/prod奇偶性。

在Kubernetes中，这个问题是通过使用ConfigMap将配置从Pods中解耦来解决的。ConfigMaps可用于将整个配置文件或变量存储为键-值对。有两种可能的方式使用ConfigMap:

将ConfigMap挂载为Pod中的卷

将ConfigMap中的变量映射到Pod中的环境变量。

下面是一个包含nginx配置的ConfigMap示例:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  nginx.conf: |
    user nginx;
    worker_processes 3;
    error_log /var/log/nginx/error.log;
...
      server {
          listen     80;
          server_name _;
          location / {
              root   html;
              index  index.html index.htm; } } }

一旦ConfigMap被创建，你就可以在Pod中使用它:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /etc/nginx
      name: nginx-conf
  volumes:
  - name: nginx-conf
    configMap:
      name: nginx-conf

从一开始，Kubernetes也提供了一个对象来存储敏感信息，如密码、密钥或其他凭证。这些对象被称为Secrets。秘密与ConfigMaps非常相关，基本上它们唯一的区别是秘密是base64编码的。

关于使用“秘密”的风险，人们一直在争论不休，因为“秘密”(与名称相反)并不被认为是安全的。在原生云环境中，已经出现了专门创建的秘密管理工具，它们可以很好地与Kubernetes集成。HashiCorp Vault就是一个例子。

10. Autoscaling

自动伸缩机制

Horizontal Pod Autoscaler (HPA)

Horizontal Pod Autoscaler (HPA)是Kubernetes中最常用的自动定标器。HPA可以监视deployments或ReplicaSets，并在达到某个阈值时增加副本的数量。成像Pod可以使用500MiB的内存，并且您配置了80%的阈值。如果利用率超过400MiB(80%)，将调度第二个Pod。现在您的容量为1000MiB。如果使用了800MiB，将调度第三个Pod，以此类推。

Cluster Autoscaler

当然，如果集群容量是固定的，那么启动越来越多的pod副本是没有意义的。如果需求增加，Cluster Autoscaler可以向集群添加新的工作节点。集群自动伸缩器与水平自动伸缩器协同工作。

Vertical Pod Autoscaler

Vertical Pod Autoscaler 相对较新，允许吊舱动态增加资源请求和限制。如前所述，垂直扩展受到节点容量的限制。

不幸的是，Kubernetes的(水平)自动伸缩是无法开箱即用的，需要安装一个名为metrics-server的附加组件。

但是，用Kubernetes Metrics api的Prometheus Adapter替换度量服务器是可能的。prometheus-adapter允许您在Kubernetes中使用自定义指标，并根据系统上的请求或用户数量等因素进行放大或缩小。

像KEDA这样的项目可以根据外部系统触发的事件来扩展Kubernetes工作负载，而不是仅仅依赖于指标。KEDA是基于kubernetes的事件驱动自动scaler的缩写，于2019年作为微软和红帽公司的合作伙伴启动。与HPA类似，KEDA可以扩展部署、复制集、pod等，还可以扩展Kubernetes作业等其他对象。通过大量现成的扩展器的选择，KEDA可以扩展到特殊的触发器，比如数据库查询，甚至Kubernetes集群中pod的数量。

交互式教程-缩放您的应用程序

在交互式教程的第五部分:运行应用程序的多个实例中，你可以学习如何手动扩展应用程序。

11. Additional Resources

Learn more about…

Differences between Containers and Pods

What are Kubernetes Pods Anyway?, by Ian Lewis (2017)

Containers vs. Pods - Taking a Deeper Look, by Ivan Velichko (2021)

kubectl tips & tricks

kubectl Cheat Sheet

Storage and CSI in Kubernetes

Container Storage Interface (CSI) for Kubernetes GA, by Saad Ali

(2019)

Kubernetes Storage: Ephemeral Inline Volumes, Volume Cloning,Snapshots and more!, by Henning Eggers (2020)

Autoscaling in Kubernetes

Architecting Kubernetes clusters - choosing the best autoscaling strategy, by Daniele Polencic (2021)

✈推荐阅读：

KCNA考试第一章：cloud foundry云原生工程师考试

KCNA考试第二章：Cloud Native Architecture

KCNA考试第三章：容器编排

KCNA考试第四章：kubernetes需要掌握的基础知识

KCNA考试第五章：kubernetes实践

KCNA考试第六章：持续交付

KCNA考试第七章：监控与探测

十二个因素的应用程序

KCNA（云原生入门）测试题

KCNA考试第五章：kubernetes学习实践(2)

7. 网络

7.1 demo

8. Volume & Storage

9. 配置对象

10. Autoscaling

11. Additional Resources

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

KCNA考试 第五章：kubernetes学习实践(2)

7. 网络

7.1 demo

8. Volume & Storage

9. 配置对象

10. Autoscaling

11. Additional Resources

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

KCNA考试第五章：kubernetes学习实践(2)