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

简介: KCNA考试 第五章:kubernetes学习实践(2)

7. 网络

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


ClusterIP

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

1035234-20181020215539574-213176954.png

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集群获取外部资源,这一点尤其有用。

1035234-20181020215539574-213176954.png

ClusterIP、NodePort和LoadBalancer相互扩展


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

1035234-20181020215539574-213176954.png

一个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

1035234-20181020215539574-213176954.png

卷允许在同一个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)集成。

1035234-20181020215539574-213176954.png

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(云原生入门)测试题


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
Web App开发 Kubernetes 数据可视化
Kubernetes Dashboard 可视化插件部署 博主亲自实践可用
Kubernetes Dashboard 可视化插件部署 博主亲自实践可用
29 0
|
1月前
|
canal Kubernetes Docker
Kubernetes_v1.18.2环境搭建 博主亲自实践可用
Kubernetes_v1.18.2环境搭建 博主亲自实践可用
48 0
|
1月前
|
Prometheus 监控 Kubernetes
干货|EasyMR 基于 Kubernetes 应用的监控实践
在云原生时代,Promtheus+Grafana 的组合已经成为了可观测性工具中不可或缺的一部分。在本文中,我们将详细探讨在大数据计算引擎 EasyMR 中如何动态采集 Kubernetes 应用监控数据。
41 0
|
2月前
|
存储 Kubernetes Cloud Native
云原生|kubernetes|持久化存储pv,pvc和StorageClass的学习
云原生|kubernetes|持久化存储pv,pvc和StorageClass的学习
74 0
|
2月前
|
存储 Kubernetes 关系型数据库
kubernetes学习之持久化存储StorageClass(4---nfs存储服务)
kubernetes学习之持久化存储StorageClass(4---nfs存储服务)
33 0
|
2月前
|
Kubernetes Cloud Native 应用服务中间件
云原生|kubernetes|关于configMap的一些学习
云原生|kubernetes|关于configMap的一些学习
37 1
|
2月前
|
Kubernetes Cloud Native 安全
猿创征文|云原生|kubernetes学习之多账户管理--权限精细化分配方案(两种方式-sa和用户)
猿创征文|云原生|kubernetes学习之多账户管理--权限精细化分配方案(两种方式-sa和用户)
76 0
|
2月前
|
Kubernetes Cloud Native API
猿创征文|云原生|kubernetes学习之RBAC(六)
猿创征文|云原生|kubernetes学习之RBAC(六)
22 0
|
2月前
|
Kubernetes Cloud Native 应用服务中间件
【云原生】kubernetes学习之资源(对象)控制器概述---概念和实战(五)
【云原生】kubernetes学习之资源(对象)控制器概述---概念和实战(五)
18 0
|
2月前
|
Kubernetes 供应链 安全
k8s学习-CKS考试必过宝典
k8s学习-CKS考试必过宝典
67 0