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

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

7. 网络

7.1 demo

8. Volume & Storage

9. 配置对象

10. Autoscaling

11. Additional Resources

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

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