介绍

本指南将引导您在 Kubernetes 集群上设置渐进式交付 GitOps 管道。

GitOps 是什么?

GitOps 是一种进行持续交付的方法,它通过将 Git 用作声明性基础结构和工作负载的真实来源来工作。对于 Kubernetes,这意味着使用 git push 代替 kubectl create/apply 或者 kubectl create/apply

GitOps vs CiOps 在传统的 CI/CD 管道中,CD 是由持续集成工具支持的实现扩展,用于将构建工件升级到生产环境。在 GitOps 管道模型中,对生产的任何更改必须先在源代码管理中提交(最好通过拉取请求),然后再应用于集群。如果整个生产状态受版本控制并在单个Git 存储库中进行描述,则在灾难发生时,可以快速恢复整个基础架构,而无需重新运行 CI 管道。

Kubernetes 反模式:让我们做 GitOps,而不是 CIOps!

为了将 GitOps 模型应用到 Kubernetes 上,你需要做三件事:

  • 一个 Git 存储库,其中包含以 YAM 格式定义的工作负载、Helm charts 和定义集群所需状态的任何其他 Kubernetes 自定义资源
  • 一个容器注册中心(registry),CI 系统在其中推送不可变的镜像(没有 latest 标签,使用 语义版本控制 或 git commit sha
  • 一个进行双向同步的 Kubernetes 控制器:
    • 监视配置存储库中的更改并将其应用于您的集群
    • 监视容器 registry(注册中心) 的新映像,并根据部署策略更新工作负载定义。

在本研讨会中,您将使用 GitHub 托管配置存储库,使用 Docker Hub 作为容器注册中心,使用 Flux 作为 GitOps 控制器,并使用 Helm Operator 进行应用程序生命周期管理。

什么是渐进式交付?

渐进式交付是高级部署模式(如金丝雀,功能标记和 A/B 测试)的总称。

通过给予应用程序开发人员和 SRE 团队对爆炸半径的细粒度控制,渐进交付技术被用来降低在生产中引入新软件版本的风险。

使用金丝雀的好处是能够在生产环境中使用发现问题的安全回滚策略对新版本进行容量测试。通过缓慢增加负载,您可以监视和捕获有关新版本如何影响生产环境的指标。

Martin Fowler 博客

在本研讨会中,您将使用

Flagger,

Linkerd

Prometheus

来自动化金丝雀分布 Helm charts。

前提条件

为了安装研讨会的前提条件,您需要一个 Kubernetes 集群(1.13 或更新版本),并支持 负载平衡器RBAC

确保您已经在本地安装了以下工具:

  • kubectl 1.16
  • git 2.20

Helm v3

在 macOS 上安装 Helm v3 CLI:

brew install helm

在 Linux 或 Windows 上,您可以从官方发布页面下载二进制文件。

Git

Fork workshop 仓库并克隆它到本地(使用你的 GitHub 用户名替换 GHUSER):

export GHUSER=stefanprodan
git clone https://github.com/${GHUSER}/gitops-helm-workshop

设置您的 GitHub 用户名和电子邮件:

cd gitops-helm-workshop
git config user.name "${GHUSER}"
git config user.email "your@main.address"

集群状态目录结构:

├── cluster
├── canaries
├── charts
│   └── podinfo
├── namespaces
└── releases

Flux

将 Flux 存储库添加到 Helm 存储库:

helm repo add fluxcd https://charts.fluxcd.io

创建 fluxcd namespace:

kubectl create ns fluxcd

通过提供您的 GitHub 存储库 URL 安装 Flux:

helm upgrade -i flux fluxcd/flux --wait \
--namespace fluxcd \
--set registry.pollInterval=1m \
--set git.pollInterval=1m \
--set git.url=git@github.com:${GHUSER}/gitops-helm-workshop

安装 fluxctl:

# macOS and linux
curl -sL https://fluxcd.io/install | sh
export PATH=$PATH:$HOME/.fluxcd/bin # windows
https://github.com/fluxcd/flux/releases

找到 Git SSH 公钥:

export FLUX_FORWARD_NAMESPACE=fluxcd

fluxctl identity

复制公钥并在 GitHub 存储库上创建具有写访问权的部署密钥。转到 Settings > Deploy keys,单击 Add deploy key,选中 Allow write access,粘贴 Flux 公钥并单击 Add key

Helm Operator

fluxcd 命名空间中安装 Flux Helm Operator:

helm upgrade -i helm-operator fluxcd/helm-operator --wait \
--namespace fluxcd \
--set git.ssh.secretName=flux-git-deploy \
--set git.pollInterval=1m \
--set chartsSyncInterval=1m \
--set helm.versions=v3

Linkerd

下载 Linkerd v2 CLI:

# macOS and linux
curl -sL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin # windows
https://github.com/linkerd/linkerd2/releases

linkerd 名称空间中安装 Linkerd 控制平面:

linkerd install | kubectl apply -f -

使用以下命令验证安装:

linkerd check

Flagger

添加 Flagger Helm 仓库:

helm repo add flagger https://flagger.app

安装 Flagger 的金丝雀 CRD:

kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml

linkerd 命名空间中安装 Flagger:

helm upgrade -i flagger flagger/flagger --wait \
--namespace linkerd \
--set crd.create=false \
--set metricsServer=http://linkerd-prometheus:9090 \
--set meshProvider=linkerd

Helm 发布

一个 chart 发布是通过 Kubernetes 自定义资源 HelmRelease 进行描述的。

一个 Helm release 可以引用的 chart,如下:

  • 通过 HTTPS 的公共或私有 Helm 存储库
  • 通过 SSH 的公共或私有 Git 存储库

安装 NGINX

为了将应用程序暴露在集群之外,您将使用 NGINX ingress 控制器。控制器将在 Linkerd 网格内运行。

创建一个启用 linkerd 注入的名称空间:

apiVersion: v1
kind: Namespace
metadata:
annotations:
fluxcd.io/ignore: "false"
linkerd.io/inject: enabled
name: ingress-nginx

创建一个 Helm release 来安装 NGINX ingress 控制器:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: nginx-ingress
namespace: ingress-nginx
annotations:
fluxcd.io/ignore: "false"
spec:
releaseName: nginx-ingress
chart:
repository: https://kubernetes-charts.storage.googleapis.com/
name: nginx-ingress
version: 1.33.4
values:
controller:
service:
type: LoadBalancer

应用更改:

git add -A && \
git commit -m "install ingress" && \
git push origin master && \
fluxctl sync

验证 Helm operator 是否已安装 release:

kubectl -n ingress-nginx get hr

查找 ingress 控制器的公共 IP:

kubectl -n ingress-nginx get svc

安装 podinfo

Podinfo 是一个很小的 Go Web 应用程序。您将使用存储 cluster/charts/podinfo 的 git 仓库中的 Helm chart 安装 podinfo。

创建启用 linkerd 注入的 prod 命名空间:

apiVersion: v1
kind: Namespace
metadata:
annotations:
fluxcd.io/ignore: "false"
linkerd.io/inject: enabled
name: prod

创建一个 Helm release 以安装 podinfo chart(替换 GHUSER 为你的 GitHub 用户名和使用你的 ingress IP 替换 LB-PUBLIC-IP):

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: podinfo
namespace: prod
annotations:
fluxcd.io/ignore: "false"
spec:
releaseName: podinfo
chart:
git: git@github.com:GHUSER/gitops-helm-workshop
ref: master
path: cluster/charts/podinfo
values:
image:
repository: stefanprodan/podinfo
tag: 3.1.0
service:
enabled: true
type: ClusterIP
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:9898;
proxy_hide_header l5d-remote-ip;
proxy_hide_header l5d-server-id;
path: /
hosts:
- LB-PUBLIC-IP.nip.io

请注意,如果您使用的是 EKS,则主机应设置为 elb.amazonaws.com 地址:

kubectl -n ingress-nginx get svc | grep Ingress

应用更改:

git add -A && \
git commit -m "install podinfo" && \
git push origin master && \
fluxctl sync

验证 Helm operator 是否已安装 podinfo:

kubectl -n prod get hr

打开浏览器并导航到 http://LB-PUBLIC-IP.nip.io/,您应该看到 podinfo v3.1.0 UI

自动升级

Flux 可以用于自动化集群中的容器映像更新。

您可以通过注释 Helm release 对象来启用自动化 image 标记更新。

您还可以通过使用 glob、regex 或语义版本表达式来控制更新应该考虑哪些标记。

编辑 podinfo Helm release 并启用 Flux 自动 Image 更新:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
annotations:
fluxcd.io/automated: "true"
fluxcd.io/tag.chart-image: semver:~3.1

应用更改:

git add -A && \
git commit -m "automate podinfo" && \
git push origin master && \
fluxctl sync

验证 Helm operator 是否已升级 podinfo:

kubectl -n prod get hr

在本地拉取 Flux 所做的更改:

git pull origin master

打开浏览器并导航到 http://LB-PUBLIC-IP.nip.io/,您应该看到 podinfo v3.1.5 UI。

密封的 secrets

为了将 secrets 安全地存储在公共 Git 存储库中,您可以使用 Sealed Secrets 控制器 并将您的 Kubernetes Secrets 加密为 SealedSecrets。只能通过在集群中运行的控制器来解密密封的 secrets。

创建 Sealed Secrets Helm release:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: sealed-secrets
namespace: fluxcd
annotations:
fluxcd.io/ignore: "false"
spec:
releaseName: sealed-secrets
chart:
repository: https://kubernetes-charts.storage.googleapis.com/
name: sealed-secrets
version: 1.8.0

应用更改:

git add -A && \
git commit -m "install sealed-secrets" && \
git push origin master && \
fluxctl sync

安装 kubeseal CLI:

wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v1.8.0/kubeseal-darwin-amd64
sudo install -m 755 kubeseal-darwin-amd64 /usr/local/bin/kubeseal

在启动时,sealed-secrets 控制器生成一个 RSA key 并记录公钥。使用 kubeseal,您可以将您的公钥保存为 pub-cert.pem,公钥可安全存储在 Git 中,可用于加密 secrets,无需直接访问 Kubernetes 集群:

kubeseal --fetch-cert \
--controller-namespace=fluxcd \
--controller-name=sealed-secrets \
> pub-cert.pem

您可以使用 kubectl 在本地生成 Kubernetes secret,并使用 kubeseal 对其进行加密:

kubectl -n prod create secret generic basic-auth \
--from-literal=user=admin \
--from-literal=password=admin \
--dry-run \
-o json > basic-auth.json kubeseal --format=yaml --cert=pub-cert.pem < basic-auth.json > basic-auth.yaml

这将生成一个类型为 SealedSecret 的自定义资源,其中包含加密的凭据。

Flux 将在您的集群上应用 sealed secret,然后 sealed-secrets 的控制器将其解密为 Kubernetes secret。

为了准备进行灾难恢复,您应该使用以下命令备份 Sealed Secrets 控制器的私钥:

kubectl get secret -n fluxcd sealed-secrets-key -o yaml \
--export > sealed-secrets-key.yaml

要在灾难后从备份中恢复,请替换新创建的密钥并重新启动控制器:

kubectl replace secret -n fluxcd sealed-secrets-key -f sealed-secrets-key.yaml
kubectl delete pod -n fluxcd -l app=sealed-secrets

金丝雀发布

一个金丝雀发布是用名为 Canary 的 Kubernetes 自定义资源描述的。

应用程序启动

编辑 podinfo Helm release 和禁用 image 更新和 ClusterIP 服务:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: podinfo
namespace: prod
annotations:
fluxcd.io/automated: "false"
spec:
releaseName: podinfo
values:
image:
repository: stefanprodan/podinfo
tag: 3.1.0
service:
enabled: false
type: ClusterIP

应用更改:

git add -A && \
git commit -m "prep canary" && \
git push origin master && \
fluxctl sync

创建一个针对 podinfo 的金丝雀发布:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: podinfo
namespace: prod
annotations:
fluxcd.io/ignore: "false"
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: podinfo
service:
port: 9898
analysis:
interval: 10s
maxWeight: 100
stepWeight: 5
threshold: 5
metrics:
- name: request-success-rate
thresholdRange:
min: 99
interval: 1m
- name: request-duration
thresholdRange:
max: 500
interval: 1m
webhooks:
- name: acceptance-test
type: pre-rollout
url: http://flagger-loadtester.prod/
timeout: 30s
metadata:
type: bash
cmd: "curl -sd 'test' http://podinfo-canary.prod:9898/token | grep token"
- name: load-test
type: rollout
url: http://flagger-loadtester.prod/
metadata:
cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.prod:9898/"

应用更改:

git add -A && \
git commit -m "add canary" && \
git push origin master && \
fluxctl sync

验证 Flagger 已经初始化金丝雀:

kubectl -n prod get canary

自动金丝雀提升

安装负载测试服务以在金丝雀分析期间生成流量:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: load-tester
namespace: prod
annotations:
fluxcd.io/ignore: "false"
spec:
releaseName: load-tester
chart:
git: https://github.com/weaveworks/flagger
ref: 1.0.0-rc.1
path: charts/loadtester
values:
fullnameOverride: load-tester

当您部署新的 podinfo 版本时,Flagger 逐渐将流量转移到金丝雀,同时测量请求的成功率以及平均响应持续时间。

基于对这些Linkerd提供的指标的分析,金丝雀部署要么提升要么回滚。

通过更新容器映像来触发金丝雀部署:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
spec:
releaseName: podinfo
values:
image:
tag: 3.1.1

应用更改:

git add -A && \
git commit -m "update podinfo" && \
git push origin master && \
fluxctl sync

当 Flagger 检测到部署修订版本已更改时,它将开始新的部署。您可以使用以下方法监视流量的变化:

watch kubectl -n prod get canaries

自动回滚

在金丝雀分析期间,您可能会生成 HTTP 500 错误和高延迟,以测试 Flagger 是否暂停并回滚有故障的版本。

触发另一只金丝雀的发布:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
spec:
releaseName: podinfo
values:
image:
tag: 3.1.2

应用更改:

git add -A && \
git commit -m "update podinfo" && \
git push origin master && \
fluxctl sync

执行到测试 pod 和产生 HTTP 500 错误:

kubectl -n prod exec -it $(kubectl -n prod get pods -o name | grep -m1 load-tester | cut -d'/' -f 2) bash

$ hey -z 1m -c 5 -q 5 http://podinfo-canary:9898/status/500
$ hey -z 1m -c 5 -q 5 http://podinfo-canary:9898/delay/1

当检查失败的数量达到金丝雀分析阈值时,流量将路由回主要服务器,并且金丝雀将比例缩放为零。

观看Flagger日志:

$ kubectl -n linkerd logs deployment/flagger -f | jq .msg

 Starting canary analysis for podinfo.prod
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Halt podinfo.test advancement success rate 69.17% < 99%
Halt podinfo.test advancement success rate 61.39% < 99%
Halt podinfo.test advancement success rate 55.06% < 99%
Halt podinfo.test advancement request duration 1.20s > 0.5s
Halt podinfo.test advancement request duration 1.45s > 0.5s
Rolling back podinfo.prod failed checks threshold reached 5
Canary failed! Scaling down podinfo.test

使用 Linkerd 进行监视

Linkerd 仪表板可实时提供有关服务情况的高级视图。

它可用于可视化服务依赖关系,流量拆分和了解特定服务路由的运行状况。

通过运行以下命令打开仪表板:

linkerd dashboard --port=50750

在金丝雀分析期间,导航至:

http://127.0.0.1:50750/namespaces/ingress-nginx/deployments/nginx-ingress-controller

您可以使用以下命令从命令行监视生产名称空间的实时流量:

linkerd -n prod top deploy

您可以使用以下命令查看 podinfo 公开的所有路由:

linkerd -n prod routes service/podinfo

以上路由是从 podinfo swagger 规范生成的,并作为 Linkerd 服务配置文件导出。

Canary Helm 测试

Flagger 附带有一个测试服务,该服务在配置为 Webhook 时可以运行 Helm 测试。

创建测试

为 podinfo 令牌 API 创建一个测试:

apiVersion: v1
kind: Pod
metadata:
name: {{ template "podinfo.fullname" . }}-jwt-test-{{ randAlphaNum 5 | lower }}
labels:
heritage: {{ .Release.Service }}
release: {{ .Release.Name }}
chart: {{ .Chart.Name }}-{{ .Chart.Version }}
app: {{ template "podinfo.name" . }}
annotations:
linkerd.io/inject: disabled
"helm.sh/hook": test-success
spec:
containers:
- name: tools
image: giantswarm/tiny-tools
command:
- sh
- -c
- |
TOKEN=$(curl -sd 'test' ${PODINFO_SVC}/token | jq -r .token) &&
curl -H "Authorization: Bearer ${TOKEN}" ${PODINFO_SVC}/token/validate | grep test
env:
- name: PODINFO_SVC
value: {{ template "podinfo.fullname" . }}:{{ .Values.service.externalPort }}
restartPolicy: Never

将以上文件保存在 cluster/charts/podinfo/tests 中。

prod 名称空间中部署 Helm 测试运行器:

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: helm-tester
namespace: prod
annotations:
fluxcd.io/ignore: "false"
spec:
releaseName: helm-tester
chart:
git: https://github.com/weaveworks/flagger
ref: 1.0.0-rc.1
path: charts/loadtester
values:
fullnameOverride: helm-tester
serviceAccountName: helm-tester

应用更改:

git add -A && \
git commit -m "install helm-tester" && \
git push origin master && \
fluxctl sync

运行测试

将 helm 测试添加为预发布 webhook:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: podinfo
namespace: prod
spec:
analysis:
webhooks:
- name: "helm test"
type: pre-rollout
url: http://helm-tester.prod/
timeout: 2m
metadata:
type: "helmv3"
cmd: "test podinfo"
- name: load-test
url: http://load-tester.prod/
metadata:
cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.prod:9898/"

应用更改:

git add -A && \
git commit -m "update podinfo" && \
git push origin master && \
fluxctl sync

当金丝雀分析开始时,Flagger 将在将流量路由到金丝雀之前调用预发布 Webhooks。

如果 helm 测试失败,Flagger 将重试,直到达到分析阈值并且金丝雀回退为止。

使用 Flux,Helm v3,Linkerd 和 Flagger 渐进式交付 Kubernetes的更多相关文章

  1. 初探云原生应用管理(二): 为什么你必须尽快转向 Helm v3

    系列介绍:这个系列是介绍如何用云原生技术来构建.测试.部署.和管理应用的内容专辑.做这个系列的初衷是为了推广云原生应用管理的最佳实践,以及传播开源标准和知识.在这个系列文章的开篇初探云原生应用管理(一 ...

  2. Helm V3 新版本发布

    Helm v3.0.0 Alpha 1 is coming! Helm 作为 Kubernetes 体系的包管理工具,已经逐渐成为了事实上的应用分发标准.根据 2018 年 CNCF 的一项云原生用户 ...

  3. 小白学k8s(7)helm[v3]使用了解

    helm使用 什么是helm 安装helm Helm V2 & V3 架构设计 配置kube config helm使用 添加仓库 helm安装nginx helm的核心概念 Chart Co ...

  4. Kubernetes 中的渐进式交付:蓝绿部署和金丝雀部署

    渐进式交付是持续交付的下一步, 它将新版本部署到用户的一个子集,并在将其滚动到全部用户之前对其正确性和性能进行评估, 如果不匹配某些关键指标,则进行回滚. 这里有一些有趣的项目,使得渐进式交付在 Ku ...

  5. DevOps - 从渐进式交付说起(含实践 Demo)

    作者:CODING - 王炜 1. 开篇 如果让你主导一款千万.甚至亿级用户产品的功能迭代,你会怎么做?你需要面对的挑战可能来自于: 商业战略的变化带来新的产品诉求,而产品的任何改动哪怕仅是界面调整, ...

  6. 使用 flux2+kustomize+helm+github 进行多集群 GitOps 云原生渐进式交付

    对于此示例,我们假设有两个集群的场景:暂存(staging)和生产(production). 最终目标是利用 Flux 和 Kustomize 来管理两个集群,同时最大限度地减少重复声明. 我们将配置 ...

  7. 使用 Flux+Flagger+Istio+Kubernetes 实战 GitOps 云原生渐进式(金丝雀)交付

    在这篇指南中,你将获得使用 Kubernetes 和 Istio 使用 GitOps 进行渐进式交付(Progressive Delivery)的实际经验. 介绍 gitops-istio GitOp ...

  8. 云原生生态周报 Vol. 19 | Helm 推荐用户转向 V3

    作者| 禅鸣.忠源.天元.进超.元毅 业界要闻 Helm 官方推荐用户迁移到 V3 版本 Helm 官方发布博客,指导用户从 v2 迁移到 v3,这标志着官方开始正式推进 helm 从 v2 转向 v ...

  9. [转帖]Helm V2 迁移到 V3 版本

    Helm V2 迁移到 V3 版本 -- :: Mr-Liuqx 阅读数 63更多 分类专栏: kubernetes 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上 ...

随机推荐

  1. centos 7系统,解决python3.x 安装后使用yum不能安装的问题(错误:urlgrabber-ext-down | KeyboardInterrupt)

    1.在安装python3.xx版本后,通过yum去安装软件会出现问题,目前我遇到的有2种问题 比如显示:urlgrabber-ext-down Downloading packages: File & ...

  2. 关于Lombok框架子类继承时EqualsAndHashCode注解的callSuper取值的思考

    先看例子(原始用例来源于这篇文章): TV类 @Getter @Setter //@EqualsAndHashCode @AllArgsConstructor @NoArgsConstructor p ...

  3. 使用T4模板动态生成NPoco实体类

    这是一个妥妥的NPoco类,这是我们在工作开发中,手动去写这个实体类,属实非常心累,字段少无所谓一次两次,数量多了,字段多了,就心态裂开

  4. Trie 练习记录

    蒟蒻以前写的逊爆讲解 Trie CF665E Beautiful Subarrays 代码 把之前每个前缀和放进 trie 树里,然后 trie 树上查询即可. CF37C Old Berland L ...

  5. do{}while(false)的用法

    do{}while(false): 在工作中我们能经常发现有人写 do{}while(false)  这样的代码,初看时让人迷惑不解,按照上面的语法 do{}while(false) 这样 do{} ...

  6. springboot使用mybatis拦截进行SQL分页

    新建一个类MyPageInterceptor.java(注意在springboot中要添加注解@Component) package com.grand.p1upgrade.mapper.test; ...

  7. 学习笔记: mysql增删改查基础语句

    mysql基础入门语句 增: INSERT INTO 表名(字段1, 2, 3) VALUES('值1', '2', '3') 删: DELETE FROM 表明 WHERE 删除条件 不提供更新条件 ...

  8. STL——容器(Map & multimap)的简述与构造

    1. map/multimap 的简介 map 是标准的关联式容器,一个 map 里存储的元素是一个键值对序列,叫做 (key,value) 键值对.它提供基于 key 快速检索数据的能力. map ...

  9. 学习笔记——JS语言精粹

    JS作用域是基于词法作用域的顶级对象. JS是一门弱类型语言,强类型能在编译时检测错误. JS是唯一一门所有浏览器都能识别的语言. 块注释对于被注释的代码是不安全的,例如/*  var rm=/a*/ ...

  10. js 传输数据 加密

    一.js函数加密 escape()和unescape(); escape() 函数可对字符串进行编码,这样就可以在所有的计算机上读取该字符串. 加密 escape(string) unescape() ...