Updated envoy website URLs to new domain (#13772)

* Updated envoy website URLs to new domain

* Update content/en/blog/2017/0.1-auth/index.md

* Update content/en/news/releases/0.x/announcing-0.1/index.md

* Update content/zh/news/releases/0.x/announcing-0.1/index.md

* Update content/zh/blog/2017/0.1-auth/index.md

---------

Co-authored-by: Craig Box <craig.box@gmail.com>

content/en/blog/2017/0.1-auth/index.md

@@ -57,7 +57,7 @@ Istio authentication uses [Kubernetes service accounts](https://kubernetes.io/do
 
 ### Communication security
 
-Service-to-service communication is tunneled through high performance client side and server side [Envoy](https://envoyproxy.github.io/envoy/) proxies. The communication between the proxies is secured using mutual TLS. The benefit of using mutual TLS is that the service identity is not expressed as a bearer token that can be stolen or replayed from another source. Istio authentication also introduces the concept of Secure Naming to protect from a server spoofing attacks - the client side proxy verifies that the authenticated server's service account is allowed to run the named service.
+Service-to-service communication is tunneled through high performance client side and server side {{<gloss envoy>}}Envoy{{</gloss>}} proxies. The communication between the proxies is secured using mutual TLS. The benefit of using mutual TLS is that the service identity is not expressed as a bearer token that can be stolen or replayed from another source. Istio authentication also introduces the concept of Secure Naming to protect from a server spoofing attacks - the client side proxy verifies that the authenticated server's service account is allowed to run the named service.
 
 ### Key management and distribution
 

content/en/blog/2017/0.1-using-network-policy/index.md

@@ -29,8 +29,8 @@ In contrast, operating at the network layer has the advantage of being universal
 
 ## Implementation
 
-The Istio’s proxy is based on [Envoy](https://github.com/envoyproxy/envoy), which is implemented as a user space daemon in the data plane that
-interacts with  the network layer using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be
+Istio’s proxy is based on {{<gloss envoy>}}Envoy{{</gloss>}}, which is implemented as a user space daemon in the data plane that
+interacts with the network layer using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be
 distributed (and upgraded!) in a container.
 
 Network Policy data plane is typically implemented in kernel space (e.g. using iptables, eBPF filters, or even custom kernel modules). Being in kernel space

content/en/news/releases/0.x/announcing-0.1/index.md

@@ -16,7 +16,7 @@ aliases:
 ---
 
 Google, IBM, and Lyft are proud to announce the first public release of [Istio](/): an open source project that provides a uniform way to connect, secure, manage and monitor microservices. Our current release is targeted at the [Kubernetes](https://kubernetes.io/) environment; we intend to add support for other environments such as virtual machines and Cloud Foundry in the coming months.
-Istio adds traffic management to microservices and creates a basis for value-add capabilities like security, monitoring, routing, connectivity management and policy.  The software is built using the battle-tested [Envoy](https://envoyproxy.github.io/envoy/) proxy from Lyft, and gives visibility and control over traffic *without requiring any changes to application code*. Istio gives CIOs a powerful tool to enforce security, policy and compliance requirements across the enterprise.
+Istio adds traffic management to microservices and creates a basis for value-add capabilities like security, monitoring, routing, connectivity management and policy.  The software is built using the battle-tested {{<gloss envoy>}}Envoy{{</gloss>}} proxy from Lyft, and gives visibility and control over traffic *without requiring any changes to application code*. Istio gives CIOs a powerful tool to enforce security, policy and compliance requirements across the enterprise.
 
 ## Background
 

content/zh/blog/2017/0.1-auth/index.md

@@ -55,7 +55,7 @@ Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/zh-cn/docs/
 
 ### 通信安全{#communication-security}
 
-服务间通信基于高性能客户端和服务器端 [Envoy](https://envoyproxy.github.io/envoy/) 代理的传输隧道。代理之间的通信使用双向 TLS 来进行保护。使用双向 TLS 的好处是服务身份不会被替换为从源窃取或重放攻击的令牌。Istio Auth 还引入了安全命名的概念，以防止服务器欺骗攻击 - 客户端代理验证允许验证特定服务的授权的服务帐户。
+服务间通信基于高性能客户端和服务器端 {{<gloss envoy>}}Envoy{{</gloss>}} 代理的传输隧道。代理之间的通信使用双向 TLS 来进行保护。使用双向 TLS 的好处是服务身份不会被替换为从源窃取或重放攻击的令牌。Istio Auth 还引入了安全命名的概念，以防止服务器欺骗攻击 - 客户端代理验证允许验证特定服务的授权的服务帐户。
 
 ### 密钥管理和分配{#key-management-and-distribution}
 

content/zh/blog/2017/0.1-using-network-policy/index.md

@@ -29,7 +29,7 @@ target_release: 0.1
 
 ## 实现{#implementation}
 
-Istio 的代理基于 [Envoy](https://github.com/envoyproxy/envoy)，它作为数据平面的用户空间守护进程实现的，使用标准套接字与网络层交互。这使它在处理方面具有很大的灵活性，并允许它在容器中分发（和升级！）。
+Istio 的代理基于 {{<gloss envoy>}}Envoy{{</gloss>}}，它作为数据平面的用户空间守护进程实现的，使用标准套接字与网络层交互。这使它在处理方面具有很大的灵活性，并允许它在容器中分发（和升级！）。
 
 网络策略数据平面通常在内核空间中实现（例如：使用 iptables 、eBPF 过滤器、或甚至自定义内核模块）。在内核空间使它们性能很好，但不像 Envoy 代理那样灵活。
 

content/zh/news/releases/0.x/announcing-0.1/index.md

@@ -16,7 +16,7 @@ aliases:
 ---
 
 Google、IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/zh-cn/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。
-Istio 为微服务添加了流量管理能力，同时为比如安全、监控、路由、连接管理和策略等附加能力打下了基础。此软件构建于来自 Lyft 的经过实战检验的 [Envoy](https://envoyproxy.github.io/envoy/) 代理之上，能在 *无需改动任何应用代码* 的情况下赋予对应用流量的可见性和控制能力。Istio 为 CIO 们提供了一个在企业内加强安全、策略和合规性的强有力的工具。
+Istio 为微服务添加了流量管理能力，同时为比如安全、监控、路由、连接管理和策略等附加能力打下了基础。此软件构建于来自 Lyft 的经过实战检验的 {{<gloss envoy>}}Envoy{{</gloss>}} 代理之上，能在 *无需改动任何应用代码* 的情况下赋予对应用流量的可见性和控制能力。Istio 为 CIO 们提供了一个在企业内加强安全、策略和合规性的强有力的工具。
 
 ## 背景{#background}