- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

云计算运维笔记

huawei_2649597846 发表于 2023/09/18 10:32:08 2023/09/18

【摘要】欢迎大家来到云计算运维笔记！在这里，我们将探索云计算运维的各个方面，为您提供实用的技巧、最佳实践和经验分享。

欢迎大家来到云计算运维笔记！

在这里，我们将探索云计算运维的各个方面，为您提供实用的技巧、最佳实践和经验分享。

随着云计算技术的快速发展，越来越多的企业选择将自己的应用和数据迁移到云端。云计算为企业带来了许多好处，如灵活性、可扩展性和成本效益等。然而，云计算环境也面临一系列的挑战和复杂性，特别是在运维方面。

云计算运维不仅涉及到对基础设施、网络和安全的管理，还需要关注应用程序的监控、性能优化和故障恢复等方面。在这个过程中，我们将面临各种挑战，如自动化运维工具的选择、容器化技术的应用、持续集成和部署等。

在云计算运维笔记中，我们将深入研究这些话题，并分享实际应用中遇到的问题和解决方案。我们将介绍各种工具和技术，如容器编排工具（如Kubernetes）、自动化运维工具（如Ansible、Terraform）、监控和日志管理工具等，帮助您更好地管理和优化云计算环境。

无论您是一个云计算运维的新手还是一个有经验的专业人士，我们相信都能为您提供有价值的信息和实用的建议。让我们一起深入探索云计算运维的世界，共同成长和进步！

HTTP存活探针是一种用于检测网络中的服务器和网络应用程序是否处于活动状态的工具。它通过发送HTTP请求并接收HTTP响应来验证服务器的可用性。

HTTP存活探针通常执行以下操作：

发送HTTP请求：探针会发送一个HTTP请求到目标服务器的特定URL或端口，例如发送一个GET请求。
监测响应：探针会监听从服务器返回的HTTP响应。通过解析响应状态码、响应头和响应正文等信息，可以判断服务器是否成功响应。
判断存活状态：根据收到的响应进行判断，如果服务器返回了预期的响应，并且状态码表明请求成功，那么可以认为服务器存活；否则，可能存在故障或不可用的情况。
生成报告或触发警报：根据监测结果，HTTP存活探针可以生成报告或触发警报，以通知运维人员或系统管理员服务器的状态。

HTTP存活探针有助于实时监测服务器的可用性和性能，以及发现潜在的故障和问题。它可用于监测网站、Web应用程序、API、负载均衡器等网络资源的健康状态，并提供及时的反馈和通知。

探针可以定期执行，例如每隔几秒钟或分钟发送一个HTTP请求，并根据响应时间、错误码和重试次数等指标来评估服务器的稳定性和可用性。

总之，HTTP存活探针是一种有助于实时监测和验证服务器可用性的工具，帮助运维人员及时发现和解决网络问题，确保服务器的正常运行和用户的畅通访问。

创建http存活探针

操作记录：

1.创版并修改

[root@kcloud-server ~]# kubectl run --image=httpd --port 80 --dry-run -oyaml liveness-http > pod.yaml
[root@kcloud-server ~]# cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: liveness-http
  name: liveness-http
spec:
  containers:
  - image: httpd
    name: liveness-http
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        port: 80
      initialDelaySeconds: 15
      failureThreshold: 1
  dnsPolicy: ClusterFirst
  restartPolicy: Always复制

创建tcp存活探针

操作记录：

[root@kcloud-server ~]# cat liveness-tcp.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: liveness-tcp
  name: liveness-tcp
spec:
  containers:
  - image: httpd
    name: liveness-tcp
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket: 
        port: 80
      timeoutSeconds: 2
      periodSeconds: 15
  dnsPolicy: ClusterFirst
  restartPolicy: Always复制

Service（服务）管理是指在计算机系统中对服务进行配置、监控和维护的过程。服务是在后台运行的软件程序，提供某种特定的功能或服务。在操作系统中，服务可以作为独立的进程或线程运行，并为其他应用程序或用户提供服务。

Service管理通常包括以下几个方面：

配置和安装：在进行Service管理之前，需要进行服务的配置和安装。这通常涉及指定服务的运行参数、权限设置、端口配置等。
启动和停止：Service管理允许管理员对服务进行启动和停止操作。通过启动服务，将其加载到内存并开始提供服务。而停止服务则意味着将其从内存中卸载，停止对外提供服务。
监控和日志记录：对服务的监控是Service管理的重要方面。通过监控服务的运行状态、资源使用情况等指标，可以及时发现并解决问题。此外，服务管理还负责记录服务的日志，以便于故障排查和性能分析。
高可用性和负载均衡：服务管理也涉及确保服务的高可用性和负载均衡。通过使用负载均衡器、故障转移技术和集群等方法，可以确保服务在故障或高负载情况下持续可用，并提供平衡的资源分配。
升级和维护：服务管理还包括对服务进行升级和维护的过程。这可能涉及安装更新、修复漏洞、添加新功能等操作，以确保服务按时更新和优化。
安全管理：在服务管理中，确保服务的安全性也是至关重要的。这包括限制访问权限、配置防火墙规则、应用加密措施等，以减少安全漏洞和保护用户数据。

通过有效的Service管理，可以确保计算机系统中的各种服务正常运行，提供稳定、可靠和高效的服务。管理员可以使用各种工具和技术来简化和自动化这些管理任务，以减少人工干预和提高效率。

Service管理--ClusterIP

Service名称为“service-clusterip”，用于唯一标识该Service对象。
Service对象所在的命名空间为“default”，表示该Service对象是默认命名空间下的资源。
该Service对象被配置为ClusterIP类型，可用于集群内部的服务发现和通信。它为后端Pod提供了固定的虚拟IP地址，并自动将请求负载均衡到这些Pod上。
Service对象映射了集群内部的端口80，并将流量转发到后端Pod的端口81。这意味着，任何向Service IP地址的80端口发送的请求都将被转发到运行在Pod中的应用程序的81端口。此外，由于Service对象的存在，即使在Pod重启、替换或扩展时，客户端仍然可以通过相同的IP和端口来访问服务，而无需关注内部的Pod变化。

综上所述，通过定义这样一个Service对象，运行在Kubernetes集群中的应用程序可以通过该Service暴露在集群内部的端口实现内部通信，同时自动实现负载均衡和高可用性特性

操作记录：

[root@kcloud-server ~]# kubectl create service clusterip service-clusterip --tcp 80:81 --dry-run -oyaml > service-clusterip.yaml 
W1127 10:59:35.948542   60222 helpers.go:557] --dry-run is deprecated and can be replaced with --dry-run=client.
[root@kcloud-server ~]# vim service-clusterip.yaml 
[root@kcloud-server ~]# kubectl  apply -f service-clusterip.yaml 
service/service-clusterip created复制

Service管理--NodePort

Service名称为“service-nodeport”，用于唯一标识该Service对象。
Service对象所在的命名空间为“default”，表示该Service对象是默认命名空间下的资源。
该Service对象被配置为NodePort类型，在集群内部和外部都可以使用。它为后端Pod提供了固定的虚拟IP地址，并自动将请求负载均衡到这些Pod上。同时，它还通过开放一个NodePort端口（30001）来暴露服务给外部访问，从而为外部用户提供了一个接入点。
Service对象映射了集群内部的端口80，并将流量转发到后端Pod的同一端口。此外，通过在每个节点上开放一个NodePort端口，该Service在所有节点上都能够被访问。因此，当外部客户端向任何节点的30001端口发送请求时，请求将被转发到Service IP地址的80端口，再通过负载均衡机制分配到相应的Pod上。

综上所述，通过定义这样一个Service对象，运行在Kubernetes集群中的应用程序可以通过该Service暴露在集群内部的端口实现内部通信，同时通过开放NodePort端口使得外部用户可以通过该Service访问服务。此外，由于Service对象的存在，即使在Pod重启、替换或扩展时，客户端仍然可以通过相同的IP和端口来访问服务，而无需关注内部的Pod变化。

[root@kcloud-server ~]# kubectl create service nodeport  service-nodeport --tcp 80:30001 --dry-run -oyaml > service-nodeport.yaml
[root@kcloud-server ~]# cat service-nodeport.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: service-nodeport
  name: service-nodeport
spec:
  ports:
  - name: 80-30001
    port: 80
    protocol: TCP
    targetPort: 30001
    nodePort: 30001
  selector:
    app: service-nodeport
  type: NodePort
status:
  loadBalancer: {}
[root@kcloud-server ~]# kubectl apply -f service-nodeport.yaml 
service/service-nodeport created复制

Secrets管理--Opaque

Secret名称为"mysecret"，用于唯一标识该Secret对象。
Secret对象所在的命名空间为"default"，表示该Secret对象是默认命名空间下的资源。
该Secret对象被配置为Opaque类型，表示它是一个通用的、不特定于特定类型的Secret。Opaque类型的Secret可以用于存储任意的键值对数据。
在该Secret对象中，包含了两个键值对数据：username 和 password。username 的值为"YWRtaW4="，经过Base64编码后表示"admin"；password 的值为"MWYyZDFlMmU2N2Rm"，经过Base64编码后表示"1f2d1e2e67df"。

综上所述，通过定义这样一个Opaque类型的Secret对象，可以将敏感信息（如用户名和密码）以加密的方式存储在Kubernetes集群中，并在需要的时候在容器或应用程序中使用这些信息。请确保在实际使用中采取适当的安全措施，并根据需求选择更加复杂的安全机制。

操作记录：

1.将参数写入文件

将被加密后的字符串解码写入env文件中

[root@kcloud-server ~]# echo YWRtaW4= | base64 -d
admin[root@kcloud-server ~]# vim env-file.txt 
[root@kcloud-server ~]# echo MWYyZDFlMmU2N2Rm | base64 -d
1f2d1e2e67df[root@kcloud-server ~]# vim env-file.txt 
[root@kcloud-server ~]# cat env-file.txt 
username=admin
password=1f2d1e2e67df复制

2.基于文件创建secret

[root@kcloud-server ~]# kubectl  create secret generic --from-env-file env-file.txt mysecret --dry-run -oyaml > secret.yaml 
W1127 11:08:22.669612   72608 helpers.go:557] --dry-run is deprecated and can be replaced with --dry-run=client.
[root@kcloud-server ~]# cat secret.yaml apiVersion: v1
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: null
  name: mysecret复制

NetworkPolicy管理--deny

NetworkPolicy 名称为 "default-deny"，用于唯一标识该 NetworkPolicy 对象。
NetworkPolicy 对象所在的命名空间为 "default"，表示该 NetworkPolicy 对象是默认命名空间下的资源。
该 NetworkPolicy 对象的规则设置为默认禁止所有入 Pod 的流量。这意味着，除非有明确的规则允许特定的流量进入 Pod，否则所有的入站流量将被阻止。

通过定义这样一个 NetworkPolicy 对象，您可以实现对 Pod 的网络流量进行细粒度的控制。默认情况下，所有入站流量都会被拒绝，这提供了一个基于黑名单的安全策略。您可以通过添加额外的规则来允许特定的流量进入 Pod，以满足应用程序的需求。请注意，NetworkPolicy 只在支持它的网络插件和平台上生效，如 Calico、Cilium 等。在应用 NetworkPolicy 之前，请确保您的集群和网络环境满足相关的要求。

[root@kcloud-server ~]# cat network-policy-deny.yaml 
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
  namespace: default
spec:
  policyTypes:
  - Ingress
  podSelector: {}

[root@kcloud-server ~]# kubectl apply -f network-policy-deny.yaml 
networkpolicy.networking.k8s.io/default-deny unchanged复制

ReplicaSet管理

Replicaset 名称为 "nginx"，用于唯一标识该 Replicaset 对象。
Replicaset 对象所在的命名空间为 "default"，表示该 Replicaset 对象是默认命名空间下的资源。
该 Replicaset 对象的副本数为 3，表示您希望运行 3 个 Pod 的副本。
该 Replicaset 对象使用的镜像为 nginx，表示每个 Pod 将基于 nginx 镜像运行。

通过定义这样一个 Replicaset 对象，您可以在 Kubernetes 集群中部署、管理多个副本的 Pod。Replicaset 使用指定的副本数来保证一定数量的 Pod 始终处于运行状态。如果某个 Pod 发生故障或被删除，Replicaset 会自动创建一个新的 Pod，以保证副本数不变。此外，Replicaset 也可以更新现有 Pod，以应用新的镜像或配置等更改。在实际使用中，请根据需求调整副本数和镜像等参数，并确保您的集群和环境满足相关的要求。

1.基于现有的模版导入

[root@kcloud-server ~]# kubectl  get rs -n kube-system coredns-79d6ff7d89 -oyaml > replicaset.yaml 复制

2.修改模版至需要的内容

[root@kcloud-server ~]# cat replicaset.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx复制

HPA管理

HorizontalPodAutoscaler（HPA）是Kubernetes中的一个资源对象，用于自动调整Pod副本数量，以适应应用程序负载的变化。HPA基于指定的指标和阈值来监控Pod的状态，并根据需要增加或减少副本数量。

HPA的工作原理如下：

HPA通过指定的指标（例如CPU使用率、内存使用率等）来监测Pod的状态。这些指标可以来自Pod容器、节点或者自定义的指标。
当被监测的指标超过或低于设定的阈值时，HPA会自动调整Pod的副本数量。
当指标超过阈值时，HPA会增加Pod的副本数量，以应对高负载。当指标低于阈值时，HPA会减少Pod的副本数量，以节约资源。
HPA的调整动作是周期性进行的，可以在HPA对象的配置中设置调整间隔。

使用HPA可以带来以下优势：

自动伸缩：HPA能够根据实际负载情况自动扩展或收缩Pod的副本数量，无需手动干预。
高可用性：通过自动扩展Pod的副本数量，HPA确保应用程序始终有足够的资源运行，提高应用程序的可用性。
资源节约：HPA能够根据负载情况自动缩减Pod的副本数量，以节约资源和成本。
弹性伸缩：HPA根据实际负载情况进行动态调整，能够快速应对负载峰值和波动。

为了使用HPA，您需要满足以下条件：

Kubernetes集群版本：HPA需要运行在支持自动水平伸缩功能的Kubernetes集群上，至少是版本1.2或更高。
指标服务配置：如果使用内置指标（如CPU使用率），您需要确保Kubernetes集群已经配置了相关的指标服务，以收集和监控指标。
适当的指标和阈值设置：您需要选择适合应用程序的指标，并根据实际需求和性能要求设置合适的阈值。

通过配置和管理HPA，您可以实现应用程序的自动扩展和资源优化，提高应用程序的可靠性和弹性。

HPA 名称为 "frontend-scaler"，用于唯一标识该 HPA 对象。
HPA 对象所在的命名空间为 "default"，表示该 HPA 对象是默认命名空间下的资源。
HPA 对象的副本数伸缩范围设置为 3 到 10，这意味着根据 CPU 使用率的情况，HPA 可以自动调整 Pod 的副本数量，在副本数低于 3 或高于 10 时进行调整。
HPA 对象的期望每个 Pod 的 CPU 使用率设置为 50%，即当 Pod 的 CPU 使用率超过 50% 时，HPA 将增加或减少 Pod 的副本数量，以维持稳定的 CPU 使用率。

通过定义这样一个 HPA 对象，您可以根据 CPU 使用率来自动扩展或收缩 Pod 的副本数量，以适应应用程序的负载变化。HPA 监控 Pod 的指标，并根据指定的阈值进行自动伸缩。请注意，为了正确使用 HPA，您需要确保集群已经启用了 Pod 的自动水平扩展（Horizontal Pod Autoscaling），并且相关的指标收集和监控已正确配置。同时，还要根据实际需求和应用程序的特点，调整副本数伸缩范围和目标 CPU 使用率等参数

1.创建deploy

创建一个deploy来被伸缩

[root@kcloud-server ~]# kubectl create deploy --image nginx --port 80 nginx --dry-run -oyaml > hpa.yaml 复制

2.基于deploy创建hpa

[root@kcloud-server ~]# kubectl  autoscale deploy nginx frontend-scaler --min 3 --max 10 --cpu-percent=50 --dry-run -oyaml >> hpa.yaml 复制

3.修改hpa文件

[root@kcloud-server ~]# cat hpa.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  creationTimestamp: null
  name: frontend-scaler
spec:
  maxReplicas: 10
  minReplicas: 3
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  targetCPUUtilizationPercentage: 50复制

4.部署

[root@kcloud-server ~]# kubectl apply -f hpa.yaml 
deployment.apps/nginx configured
horizontalpodautoscaler.autoscaling/frontend-scaler configured复制

5.观察

Pod由1个副本变成了3个副本(hpa要求的最低副本数量)

如果集群中有监控插件,且Pod的cpu使用率大于了50%那么就会产生一个新的Pod

Pod 安全上下文

Pod 安全上下文（Pod Security Context）是Kubernetes中的一个资源对象，用于定义Pod中容器的安全设置。Pod Security Context允许您控制容器运行时的安全性，并确保容器在运行时获得适当的权限和约束。

Pod Security Context可以在两个级别进行配置：

Pod级别的安全上下文：在Pod级别配置的安全上下文将应用于Pod中的所有容器。这些设置包括：
- 运行用户（User）和用户组（Group）：指定容器进程的运行用户和用户组的ID。
- 文件系统权限（FSGroup）：指定容器中文件和目录的默认权限。
- 容器特权（Privileged）：指定是否容器具有特权访问主机资源的能力。
- SELinux选项：指定容器的SELinux安全选项。
- 容器的只读根文件系统（ReadOnlyRootFilesystem）：指定容器是否使用只读的根文件系统。
- Sysctls：指定要应用于Pod中容器的内核参数。
容器级别的安全上下文：在容器级别配置的安全上下文将仅应用于特定的容器。这些设置包括：
- 运行用户（User）和用户组（Group）：指定容器进程的运行用户和用户组的ID。
- 文件系统权限（RunAsUser、RunAsGroup、SupplementalGroups）：指定容器中文件和目录的权限。
- 容器特权（Privileged）：指定容器是否具有特权访问主机资源的能力。
- SELinux选项：指定容器的SELinux安全选项。
- 容器的只读根文件系统（ReadOnlyRootFilesystem）：指定容器是否使用只读的根文件系统。

通过配置Pod Security Context，您可以实施一些基本的安全措施来保护Pod中的容器，限制其对主机和集群资源的访问权限，并增加应用程序的安全性。不同的安全策略可以根据应用程序的需求和安全要求进行调整和配置。请注意，Pod Security Context需要适当的权限和集群配置才能生效。

创建一个名为 secure-busybox 的 Pod

apiVersion: v1
kind: Pod
metadata:
  name: secure-busybox
spec:
  containers:
    - name: busybox-container
      image: busybox
      command: ["sleep", "3600"]
      securityContext:
        runAsUser: 1001
        runAsGroup: 2001
        capabilities:
          drop:
          - SYS_CHROOT
        readOnlyRootFilesystem: true
      resources: {}
      volumeMounts: []
  hostname: secure-busybox
  dnsPolicy: Default
  hostNetwork: false
  hostIPC: false
  hostPID: false复制

RBAC管理

RBAC（Role-Based Access Control）是Kubernetes中用于授权和访问控制的一种策略，允许向用户、组和服务帐户分配特定的权限和角色。RBAC通过控制对Kubernetes API资源的访问来限制用户、组或服务帐户对集群的访问权限，帮助管理员更好地管理和维护Kubernetes集群。

RBAC授权模型包括四个核心概念：

用户（User）：指使用Kubernetes API的实体，例如管理员或开发人员。
角色（Role）：定义对Kubernetes API资源执行特定操作的权限列表。
服务帐户（Service Account）：一个由Kubernetes API控制的帐户，用于授权Pod中的容器或其他应用程序。
绑定（Binding）：将角色与用户、组或服务帐户关联起来的机制。

使用RBAC可以带来以下优点：

精细控制：RBAC提供了精细的授权机制，使管理员可以根据需要对Kubernetes集群的不同资源进行划分和授权。
角色复用：RBAC允许管理员创建角色，并将其分配给多个用户、组或服务帐户。这样可以避免重复性设置和维护角色。
安全性增强：RBAC可以保护集群免受未经授权的访问和攻击，从而增强了集群的安全性。
可扩展性：RBAC可以轻松扩展，管理员可以根据实际需求和业务需要添加新的用户、角色和绑定。

要使用RBAC，您需要在Kubernetes API服务器上启用它，并进行相应的配置。管理员需要创建角色和绑定，并将其分配给指定的用户、组或服务帐户，以定义他们对Kubernetes API资源和操作的访问权限。

请注意，正确地配置RBAC是确保Kubernetes集群安全的重要步骤。在操作RBAC之前，请确保您已经对Kubernetes安全性有足够的了解，并按照最佳实践进行配置和管理。

创建一个 Namespace 叫做 “my-namespace”

有一个用户叫做 “james”

需要给 james 赋予在 my-namespace 中创建和删除 Pod 的权限，但是不能够删除和修改 Service 和 Deployment

[root@k8s-master-node1 RBAC]# kubectl create namespace my-namespace

[root@k8s-master-node1 RBAC]# kubectl create role james -role  -n my-namespace --verb=create,delete --resource=pods --dry-run -oyaml > james-role.yaml

[root@k8s-master-node1 RBAC]# kubectl create rolebinding -n my-namespace --role james-role  --user james  --dry-run -oyaml james-rolebinding  > james-rolebinding.yaml

[root@k8s-master-node1 RBAC]# kubectl apply -f james-rolebinding.yaml 
复制

创建自定义资源类型

自定义资源类型（Custom Resource Types）是Kubernetes中的一种扩展机制，它允许用户根据自己的需求定义和创建新的资源类型。这样可以将用户自定义的状态和行为以资源的形式集成到Kubernetes集群中，从而扩展Kubernetes的功能和能力。

自定义资源类型的主要组成部分包括：

API定义：自定义资源类型需要定义自己的API规范。这包括定义资源的名称、属性、字段、验证规则和行为等。
控制器：自定义资源类型可以关联一个或多个控制器，用于定义自定义资源类型的生命周期、状态管理和业务逻辑。控制器负责监听自定义资源对象的变化，并根据定义的逻辑执行相应的操作。

通过自定义资源类型，用户可以根据自己的需求创建与Kubernetes原生资源类型类似的资源，并在Kubernetes集群中进行管理。例如，您可以创建自定义资源类型来表示特定应用程序的配置、数据源的映射、监控指标或任何其他与业务相关的信息。

使用自定义资源类型的好处包括：

扩展性：自定义资源类型使得用户可以扩展Kubernetes的功能，以满足特定的业务需求。
一致性：自定义资源类型遵循Kubernetes资源模型和API设计原则，使其与Kubernetes生态系统中的其他资源类型保持一致。
集成性：自定义资源类型与Kubernetes的其他组件和工具紧密集成，可以使用kubectl、Operator等工具进行管理和操作。
可编程性：自定义资源类型可以通过API进行管理和操作，使得用户可以使用各种编程语言和工具与其进行交互。

在创建和使用自定义资源类型之前，建议深入了解Kubernetes的资源模型、API设计和开发相关知识。同时，根据最佳实践和安全要求来设计和管理自定义资源类型，以确保其稳定性、安全性和可扩展性。

创建一个自定义资源类型 webapp

该类型包含以下字段：name、image、replicas、port，其中 name 字段为必需字段。

请编写相应的自定义资源类型定义文件和示例 YAML 文件，并创建一个 webapp 类型的对象

包括以下属性：name 为 web1、image 为 nginx、replicas 为 3、port 为 80。

kind: CustomResourceDefinition
apiVersion: apiextensions.k8s.io/v1
metadata:
  name: webapps.app.qwe
spec:
  group: app.qwe
  names:
    kind: WebApp
    plural: webapps
    shortNames:
    - wa
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        required:
        - name
        properties:
          name:
            type: string        
          image:
            type: string
          replicas:
            type: integer
          port:
            type: integer
[root@k8s-master-node1 ~]# cat webapp.yaml 
kind: WebApp
apiVersion: app.qwe/v1
metadata:
  name: web1
name: web1复制

生命周期管理--配置Pod生命周期[1.0分]**

在Kubernetes中，通过配置Pod的生命周期管理，您可以定义和控制Pod中各个容器的启动、运行和终止过程。这涉及到以下几个关键概念：

启动容器（Init Containers）：Init Containers是在Pod中所有其他容器运行之前执行的容器。它们用于执行初始化任务，例如准备环境、下载依赖等。Init Containers完成后，才会启动其他容器。
容器生命周期钩子（Container Lifecycle Hooks）：容器生命周期钩子允许您在容器的生命周期阶段执行自定义操作。这些阶段包括容器的启动前、启动后、终止前和终止后。您可以使用钩子来处理资源创建、数据加载、健康检查等操作。
生命周期处理程序（Lifecycle Handlers）：通过在Pod或容器配置中定义生命周期处理程序，您可以指定容器在特定状态下需要执行的命令。例如，在容器启动前执行一个命令以准备环境，或在容器终止前执行一个命令以清理资源。
重启策略（Restart Policy）：重启策略确定当容器终止时是否将其重新启动。Kubernetes提供了三种重启策略：Always（总是重启，默认选项）、OnFailure（只有在失败时重启）和Never（从不重启）。

通过配置这些生命周期管理选项，您可以灵活地控制Pod中容器的启动和关闭顺序，以及执行额外的初始化或清理任务。这些功能对于处理应用程序的依赖关系、资源初始化、数据清理等场景非常有用。

无论是通过声明式的Pod定义文件还是通过编程方式创建Pod，您都可以在Pod配置中使用这些生命周期管理选项来配置和定制Pod的行为。这样，您就可以根据自己的需求和业务逻辑设定合适的生命周期管理策略，并确保Pod在各种情况下都能正确运行和终止。

案例：

在default命名空间下使用nginx:latest镜像创建一个名为lifecycle-demo的Pod，要求容器创建成功后执行命令“echo Hello from the postStart handler > /usr/share/message”，容器终止前执行命令“nginx -s quit; while killall -0 nginx; do sleep 1; done”。

完成后提交master节点的IP地址、用户名和密码到答题框

[root@k8s-master-node1 pod]# cat lifecycle-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: lifecycle-demo
  name: lifecycle-demo
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: lifecycle-demo
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh","-c","echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]复制

创建定时任务

在Kubernetes中，您可以使用CronJobs来创建定时任务。CronJobs是一种资源类型，用于在指定的时间间隔或时间点运行作业。

以下是创建定时任务的一般步骤：

创建一个CronJob定义文件（例如cronjob.yaml），并在其中指定任务的调度规则、容器模板和其他选项。

完成后使用该YAML文件创建CronJob，并提交master节点的用户名、密码和IP到答题框。

#[root@k8s-master-node1 ~]# kubectl create cronjob --namespace default --schedule="* * * * *" --image=busybox:latest --dry-run -oyaml hello > date.yaml
[root@k8s-master-node1 ~]# cat date.yaml 
apiVersion: batch/v1
kind: CronJob
metadata:
  creationTimestamp: null
  name: date
  namespace: default
spec:
  jobTemplate:
    metadata:
      creationTimestamp: null
      name: date
    spec:
      template:
        metadata:
          creationTimestamp: null
        spec:
          containers:
          - image: busybox:latest
            name: hello
          restartPolicy: OnFailure
  schedule: "*/1 * * * *"
复制

注意事项：

Cron表达式指定了任务的调度规则，可以根据需要自定义。例如，"*/5 * * * *"表示每5分钟运行一次，您可以根据自己的需求进行调整。
容器模板中的镜像地址和其他配置项需要根据实际情况进行修改。
要确保您的集群已启用CronJob控制器，否则无法使用CronJobs功能。

通过使用CronJobs，您可以方便地在Kubernetes中创建和管理定时任务，并根据需要定制任务的调度规则和容器配置，以满足您的业务需求。

Helm搭建Galera

Helm是一个流行的Kubernetes包管理工具，用于简化在Kubernetes集群中部署和管理应用程序。Galera是一个基于MySQL的开源多主数据库集群解决方案。使用Helm来搭建Galera集群可以有效地简化部署过程并提供自动化管理。

下面是使用Helm搭建Galera集群的详细步骤：

1.修改values

```bash
[root@master ~]# wget http://172.128.10.10/PUBLIC-CLOUD/mariadb-galera-7.3.14.tgz
[root@master ~]# tar xf mariadb-galera-7.3.14.tgz
[root@master ~]# cd mariadb-galera/
[root@master mariadb-galera]# vim values.yaml

108 type: NodePort
121 nodePort:
122 mysql: 32334
124 nodePorts:
125 mysql: "32334"
243 password: "chinaskill"
599 enabled: false

2.安装

[root@master mariadb-galera]# helm install maraidb .

公有云安全：Linux内核优化

将外连接的端口范围改为 1024 到 65000。

将 SYN 队列的长度设置为 8192。

系统同时保持 TIME_WAIT 套接字的最大数量 5000。

关闭 IPv6。

cat /etc/sysctl.conf
net.ipv4.ip_local_port_range= 1024 65000
net.ipv4.tcp_max_syn_backlog= 8192
net.ipv4.tcp_max_tw_buckets= 5000
net.ipv6.conf.all.disable_ipv6= 1

【实操题】基于 BDP 配置网络 buffer使得所有的 TCP 连接都能：

用于缓存每个连接的缓存最小值，足够适用于这个延迟以及带宽

用于缓存每个连接的缓存缺省值等于用于缓存的最小值

用于缓存每个连接的缓存最大值，等于 4 倍缓存最小值

设置重启后仍然生效

#延时*带宽（Mib）*1024*1024/8
cat /etc/sysctl.conf
net.ipv4.tcp_rmem = 114688 114688 458752
net.ipv4.tcp_wmem = 114688 114688 458752

chartmuseum 仓库

ChartMuseum是一个开源的Helm Chart仓库，它使用户可以轻松地存储和分发Helm Charts。管理Helm Charts时，可以使用本地文件系统、对象存储等多种方式来存储Charts文件。

ChartMuseum提供了一个Web UI界面来查看和搜索Charts，同时还提供了RESTful API，用户可以使用其API上传、查询和删除Charts文件，基于HTTP协议，与Helm客户端可以无缝集成，从而方便地进行Charts的管理和部署。

除此之外，ChartMuseum还支持安全性和可扩展性，例如：

认证和授权：ChartMuseum内置了基于HTTP Basic Auth的认证和授权功能，保护了Charts的安全性。
HTTPS支持：ChartMuseum支持HTTPS协议，增强了数据传输的安全性。
可扩展性：ChartMuseum支持多种Storage后端，如本地文件系统、Amazon S3、Google Cloud Storage等，可以轻松地扩展Charts的存储能力。
高可用：ChartMuseum采用无状态的设计，可以通过Kubernetes或Docker Compose等工具轻松实现高可用部署。

通过ChartMuseum，用户可以快速和方便地管理Helm Charts，提高部署效率和代码重用性。ChartMuseum也非常易于配置和部署，对于需要搭建自己的私有Chart仓库的企业和个人都是非常实用的。

在 k8s 集群中创建 chartmuseum 命名空间，编写 yaml 文件在 chartmuseum 命名空间中使用 chartmuseum:latest 镜像创建本地私有 chart 仓库，设置其仓库存储目录为宿主机的 /data/charts 目录。编写 service.yaml 文件，为 chart 私有仓库创建 Service 访问策略，定义其为 ClusterIP 访问模式。编写完成后启动 chartmuseum 服务。提交连接 kcloud 集群节点的用户名、密码和公网 IP 地址到答题框。

1.基础准备

[root@zcloud ~]# kubectl create ns chartmuseum复制

2.启动仓库

[root@zcloud ~]# vim chartmuseum.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: chartmuseum
  name: chartmuseum
  namespace: chartmuseum
spec:
  replicas: 1
  selector:
    matchLabels:
      app: chartmuseum
  template:
    metadata:
      labels:
        app: chartmuseum
    spec:
      containers:
      - image: bitnami/chartmuseum:latest
        imagePullPolicy: IfNotPresent
        name: chartmuseum
        ports:
        - containerPort: 8080
          protocol: TCP
        env:
        - name: DEBUG
          value: "1"
        - name: STORAGE
          value: local
        - name: STORAGE_LOCAL_ROOTDIR
          value: /charts复制

3.暴露仓库

[root@zcloud ~]# kubectl expose deployment chartmuseum -n chartmuseum --name chartmuseum --port 7070 --target-port 7070复制

添加chartmuseum为helm仓库

在 master 节点添加搭建的本地私有 chart 仓库源，name 为 chartmuseum，并上传 wordpress-13.0.23.tgz 包至 chartmuseum 私有仓库中。可以使用本地仓库 chart 源部署应用。完成后提交连接 kcloud 集群节点的用户名、密码和公网 IP 地址到答题框。

1.添加helm仓库

[root@zcloud ~]# helm repo add chartmuseum http://<clusterIP>复制

2.上传Chart到仓库

[root@zcloud ~]# helm pulgin install https://github.com/chartmuseum/helm-push
[root@zcloud ~]# curl --data-binary "@wordpress-13.0.23.tgz"  http://<clusterIP>/api/charts
# or
[root@zcloud ~]#  helm push wordpress-13.0.23.tgz chartmuseum

chkrootkit主机安全扫描

chkrootkit是一种主机安全扫描工具，用于检测系统中是否存在已知的rootkit和后门程序。rootkit是一种恶意软件，可以隐蔽地修改操作系统或其他应用程序的行为，从而绕过安全检查和攻击系统。通过使用chkrootkit，您可以识别和清除这些恶意软件，从而提升系统安全性。

chkrootkit通过检查系统文件和进程列表等方式来查找rootkit和后门程序，主要包括以下几个方面：

文件系统：chkrootkit会检查系统中一些常见的rootkit文件和隐藏文件（如LD_PRELOAD、rkit等），以及可疑的隐藏目录和隐藏文件。
进程：chkrootkit会扫描当前运行的进程列表，检查是否存在已知的rootkit进程或隐藏进程。
函数库：chkrootkit会扫描系统中的共享库，在其中查找已知的rootkit代码。
后门程序：chkrootkit会检查系统中的常见后门程序，例如IRC后门程序。
其他：chkrootkit还会检查系统中是否存在可疑的网络连接、ARP欺骗等安全问题。

使用chkrootkit进行扫描非常简单，首先需要安装chkrootkit工具，然后在命令行中运行下面的命令：

shellCopy Code

chkrootkit

chkrootkit会自动扫描系统中的文件、进程和其他相关信息，并输出检测结果。如果发现任何可疑的rootkit或后门程序，chkrootkit会给出详细的报告和建议。

需要注意的是，chkrootkit仅能检测已知的rootkit和后门程序，对于未知形式的恶意软件可能无法有效识别。因此，安全专家建议综合使用多种安全扫描工具和技术，以提高系统的安全性。

在公有云上的主机时刻面临被攻击的危险，除了可以购买云安全服务，还可以自行部署安全服务。在华为云上创建一个 X86 架构的云主机，镜像使用 CentOS7.9。使用提供的 makechk.tar.gz 包安装 chkrootkit 入侵检测工具，安装完毕后使用 chkrootkit 工具扫描系统，并将扫描结果保存到/var/log/chkrootkit/chkrootkit.log，根据扫描的结果，修复漏洞。操作完成后，提交该云主机的用户名、密码和公网 IP 到答题框。

操作记录：

### 1.安装依赖

```shell
tar xf makechk.tar.gz
cd makechk/packages/
yum install -y *.rpm
```

### 2.扫描漏洞

```shell
tar xf chkrootkit.tar.gz
cd chkrootkit-0.55/
make all
# 如果没有make
yum install -y make gcc
make all
mkdir /-p /var/log/chkrootkit/
[root@z chkrootkit-0.55]# ./chkrootkit > /var/log/chkrootkit/chkrootkit.log
```

日志分析服务

日志分析服务是一种将系统、应用程序和网络设备等产生的各种事件记录转换成有价值信息的服务。它可以帮助企业实时了解其IT架构中系统运行状况、安全威胁和合规性问题，以便及时采取措施进行应对。

常见的日志分析服务包括ELK(Stack)、Splunk、Graylog、Fluentd等。这些服务可以采集、分析、存储和可视化各种类型的日志数据，包括系统日志、数据库日志、安全日志、应用程序日志、Web访问日志等。它们还具备快速搜索、自动警报、可视化分析和基于规则的事件响应等功能。

以下是日志分析服务主要功能的简介：

数据采集：支持从多种数据源收集日志，如文件、标准输出、网络、数据库等。
数据存储：提供可扩展的存储方式，如Elasticsearch、Hadoop、MongoDB等，支持按时间、用户、应用程序等维度建立索引。
实时分析：支持实时查询、分析和可视化日志数据，以便及时检测和解决异常情况。
预警机制：支持基于规则和机器学习等方式，自动识别潜在威胁并发送警报，以便及时采取措施进行应对。
报告和可视化：支持生成各种类型的报告和可视化图表，方便用户进行数据分析和决策。
安全合规性：支持满足各种安全标准和合规性要求，如PCI DSS、HIPAA等。

日志分析服务可以帮助企业快速定位系统问题和安全威胁，提高运维效率和安全性。加上自动化的预警机制和事件响应机制，使得企业能更快的响应突发事件，保持业务连续性。

安全在公有云服务中占很大的比重，而日志分析服务可以很有效的分析日志规避部分风险。请在华为云上创建一个 X86 架构的云主机，镜像使用 CentOS7.9。自行配置 YUM 源安装 Docker 服务，然后使用提供的 sepb_elk_latest.tar 镜像安装 ELK 服务，安装完成后，进行添加数据操作，将 ELK 监控目标节点所需安装的 RPM 安装包下载到本地云主机的/root 目录下。完成后提交 ELK 云主机的用户名、密码和公网 IP 到答题框。

### 1.启动容器与下载依赖

```shell
[root@zcloud ~]# echo 262114 > /proc/sys/vm/max_map_count
[root@zcloud ~]# docker load -i sepb_elk_latest.tar
[root@zcloud ~]# docker run -it -d --name elk -p 5601:5601 -p 9200:9200 -p 5044:5044 --restart always sebp/elk:latest
[root@zcloud ~]# yum install -y wget
[root@zcloud ~]# wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.13.2-x86_64.rpm
[root@zcloud ~]# yum install -y filebeat-7.13.2-x86_64.rpm
```

### 2.配置filebeat

```shell
[root@zcloud ~]# vim /etc/filebeat/filebeat.yml
filebeat.inputs:

# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.

- type: log

# Change to true to enable this input configuration.
enabled: true

# Paths that should be crawled and fetched. Glob based paths.
paths:
- /var/lib/docker/containers/*/*.log
- /var/log/syslog
#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["192.168.16.190:9200"]

# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
[root@zcloud ~]# systemctl start filebeat
```

点赞
收藏
关注作者

0/1000

抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认取消

加入云驻计划，成为创作者

华为云周边好礼
免费体验产品
特殊身份标识
线下官方门票
内部专家零距离
与10000+优质创作者共同成长

立即加入

云计算运维笔记

欢迎大家来到云计算运维笔记！

在这里，我们将探索云计算运维的各个方面，为您提供实用的技巧、最佳实践和经验分享。

随着云计算技术的快速发展，越来越多的企业选择将自己的应用和数据迁移到云端。云计算为企业带来了许多好处，如灵活性、可扩展性和成本效益等。然而，云计算环境也面临一系列的挑战和复杂性，特别是在运维方面。

云计算运维不仅涉及到对基础设施、网络和安全的管理，还需要关注应用程序的监控、性能优化和故障恢复等方面。在这个过程中，我们将面临各种挑战，如自动化运维工具的选择、容器化技术的应用、持续集成和部署等。

无论您是一个云计算运维的新手还是一个有经验的专业人士，我们相信都能为您提供有价值的信息和实用的建议。让我们一起深入探索云计算运维的世界，共同成长和进步！

创建http存活探针

1.创版并修改

创建tcp存活探针

Service管理--ClusterIP

Service管理--NodePort

Secrets管理--Opaque

操作记录：

1.将参数写入文件

2.基于文件创建secret

NetworkPolicy管理--deny

ReplicaSet管理

1.基于现有的模版导入

2.修改模版至需要的内容

HPA管理

1.创建deploy

2.基于deploy创建hpa

3.修改hpa文件

4.部署

5.观察

Pod 安全上下文

RBAC管理

创建自定义资源类型

生命周期管理--配置Pod生命周期[1.0分]**

创建定时任务

Helm搭建Galera

Helm是一个流行的Kubernetes包管理工具，用于简化在Kubernetes集群中部署和管理应用程序。Galera是一个基于MySQL的开源多主数据库集群解决方案。使用Helm来搭建Galera集群可以有效地简化部署过程并提供自动化管理。

公有云安全：Linux内核优化

【实操题】 基于 BDP 配置网络 buffer使得所有的 TCP 连接都能：

chartmuseum 仓库

1.基础准备

2.启动仓库

3.暴露仓库

添加chartmuseum为helm仓库

1.添加helm仓库

2.上传Chart到仓库

全部回复

设置昵称

关于作者

目录

加入云驻计划，成为创作者

推荐阅读

相关产品

【实操题】基于 BDP 配置网络 buffer使得所有的 TCP 连接都能：