Merge remote-tracking branch 'origin/master' into issue_13383

content/en/case-studies/nokia/index.html

@@ -0,0 +1,93 @@
+---
+title: Nokia Case Study
+linkTitle: Nokia
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+logo: nokia_featured_logo.png
+---
+
+
+<div class="banner1" style="background-image: url('/images/CaseStudy_nokia_banner1.jpg')">
+  <h1> CASE STUDY:<img src="/images/nokia_logo.png" class="header_logo" style="width:20%;margin-bottom:-2.2%"><br> <div class="subhead" style="margin-top:1%">Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes
+
+</div></h1>
+
+</div>
+
+<div class="details">
+    Company &nbsp;<b>Nokia</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Espoo, Finland
+</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Telecommunications</b>
+</div>
+
+<hr>
+<section class="section1">
+<div class="cols">
+  <div class="col1" style="width:100%"">
+    <h2>Challenge</h2>
+    <a href="https://www.nokia.com/en_int">Nokia</a>’s core business is building telecom networks end-to-end; its main products are related to the infrastructure, such as antennas, switching equipment, and routing equipment. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on <a href="https://cloud.vmware.com/">VMware Cloud</a> and <a href="https://www.openstack.org/">OpenStack</a> Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."
+
+    <h2>Solution</h2>
+    The company decided that moving to cloud native technologies would allow teams to have infrastructure-agnostic behavior in their products. Teams at Nokia began experimenting with Kubernetes in pre-1.0 versions. "The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes," says Csatari. The first Kubernetes-based product, the <a href="https://networks.nokia.com/products/telecom-application-server">Nokia Telephony Application Server</a>, went live in early 2018. "Now, all the products are doing some kind of re-architecture work, and they’re moving to Kubernetes."
+<br>
+<h2>Impact</h2>
+    Kubernetes has enabled Nokia’s foray into 5G. "When you develop something that is part of the operator’s infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari. The teams using Kubernetes are already seeing clear benefits. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it’s easier to implement features in the application layer," says Csatari. And because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack, or bare metal," he adds. As a result, "we save several hundred hours in every release."
+
+</div>
+
+</div>
+</section>
+<div class="banner2">
+  <div class="banner2text">
+    "When people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes."
+<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
+  </div>
+</div>
+<section class="section2">
+<div class="fullcol">
+  <h2>Nokia was the first name in mobile phones when they were becoming ubiquitous in the late 1990s and early 2000s. But by 2014, the company had sold off its mobile device division and was focusing its core business not on the handhelds used for calls, but on the networks.</h2>
+  Today, Nokia is building telecom networks end-to-end—from antennas to switching and routing equipment—serving operators in more than 120 countries. "As telecom vendors, we have to deliver our software to several telecom operators and put the software into their infrastructure, and each of the operators have a bit different infrastructure," says Gergely Csatari, Senior Open Source Engineer at Nokia. "There are operators who are running on bare metal. There are operators who are running on virtual machines. There are operators who are running on VMware Cloud and OpenStack Cloud. We want to run the same product on all of these different infrastructures without changing the product itself."<br><br>
+  Looking for a way to allow its teams to build products with infrastructure-agnostic behavior, the company decided to embrace containerization, Kubernetes, and other cloud native technologies, a move that is being made across the telecom industry. Since early 2018, "when people are picking up their phones and making a call on Nokia networks, they are creating containers in the background with Kubernetes," says Csatari. "Now, all the products are doing some kind of re-architecture work, and they’re moving to Kubernetes."
+
+</div>
+</section>
+<div class="banner3" style="background-image: url('/images/CaseStudy_nokia_banner3.jpg')">
+  <div class="banner3text">
+    "Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
+
+  </div>
+</div>
+<section class="section3">
+<div class="fullcol">
+  Nokia’s cloud native journey began about two years ago, when Csatari’s team was building the company’s Telephony Application Server (TAS). "We wanted to have a service execution engine in the product, which was a totally separate function from all other parts," he says. "There, we had the possibility to think about new architectures and new tools that we could use. We created this particular product based on Kubernetes, and we liked the work, so we started to talk about cloud native and containers and all of these things. We did a very extensive research of different container orchestration tools. We knew that we have some, let’s say, strange or different requirements because of the special environment that our software is running on."<br><br>
+  For one thing, Nokia’s software serves millions of people, and is required to have the carrier-grade "five nines" availability: to be up 99.999% of the time. "If you turn it to minutes, this means we’re allowed to have only 10 minutes of downtime in a whole year," says Csatari. "Downtime here means that you are not able to serve the person to full capacity, which means that we cannot fail. This includes software upgrades, everything, because when you call 911, you’re using our software, and you expect that it will work."<br><br>
+  That meant that they needed to be able to set affinity and anti-affinity rules in their orchestration tools. "You cannot put all of the functions to the same physical host because physical hosts are failing," Csatari explains. "If you fail with one physical host, then you lose all of the core processing processes. Then there are no calls going through. So we have to divide them among the different physical hosts. At that time, only Kubernetes was able to provide these features. The simplicity of the label-based scheduling of Kubernetes was a sign that showed us this architecture will scale, will be stable, and will be good for our purposes."
+
+</div>
+</section>
+<div class="banner4" style="background-image: url('/images/CaseStudy_nokia_banner4.jpg')" style="width:100%">
+  <div class="banner4text">
+  "Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business." <br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span>
+  </div>
+</div>
+
+<section class="section5" style="padding:0px !important">
+<div class="fullcol">
+  The TAS went live in early 2018, and now Kubernetes is also enabling Nokia’s foray into 5G. The company is introducing microservices architecture and Kubernetes while adding 5G features to existing products. And all new 5G product development will be on top of Kubernetes. "When you develop something that is part of the operator’s infrastructure, you have to develop it for the future, and Kubernetes and containers are the forward-looking technologies," says Csatari. <br><br>
+  There have been real time savings thanks to Kubernetes. "By separating the infrastructure and the application layer, we have less dependencies in the system, which means that it’s easier to implement features in the application layer," says Csatari. Because teams can test the exact same binary artifact independently of the target execution environment, "we find more errors in early phases of the testing, and we do not need to run the same tests on different target environments, like VMware, OpenStack or bare metal," he adds. As a result, "we save several hundred hours in every release."<br><br>
+  Moving from Nokia’s legacy cluster management system, which had been built in-house more than thirty years ago, to a Kubernetes platform also meant that "we started using Linux as a base operating system, so we just opened the window to all of these open source projects instead of implementing everything in house," says Csatari. (From CNCF’s ecosystem, the team is already using <a href="https://helm.sh/">Helm</a>, <a href="https://grpc.io/">gRPC</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://prometheus.io/">Prometheus</a>, and <a href="https://www.envoyproxy.io/">Envoy</a>, and plans to implement <a href="https://coredns.io/">CoreDNS</a>.) "Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."
+
+</div>
+
+<div class="banner5" style="width:100%">
+  <div class="banner5text">
+"I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that’s very exciting for me and my colleagues,"<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Gergely Csatari, Senior Open Source Engineer, Nokia</span></div>
+</div>
+
+<div class="fullcol">
+  The company has a long-term goal of moving the entire product portfolio into the Kubernetes platform. To that end, Nokia teams are working together with other companies to add the features needed to use Kubernetes with the real-time, nanosecond-sensitive applications close to the edge of the radio network. <br><br>
+  And the CNCF community is proving to be a great forum for that collaboration. "I had some discussions at KubeCon with people from the networking SIG and the resource management working group, to work together on our requirements, and that’s very exciting for me and my colleagues," says Csatari. "Previously, everybody had the same problem, but everybody just did it in his own, and now we are trying to solve the same problem together."<br><br>
+  Perhaps the biggest impact that Kubernetes is having on Nokia, Csatari believes, is that people are starting to think about how a telecom company can do DevOps. "We are building a DevOps pipeline, which reaches from the actual developer to the customers, and thinking about new ways how can we digitally deliver our software to our customers and get feedback from the customers right to the engineers," he says. "This is something that will fundamentally change how telecom companies are delivering software, and how quickly can we develop new features. This is because of the usage of containers and, of course, the usage of Kubernetes."
+
+</div>
+</section>

content/en/docs/concepts/overview/kubernetes-api.md

@@ -69,7 +69,7 @@ To make it easier to eliminate fields or restructure resource representations, K
 multiple API versions, each at a different API path, such as `/api/v1` or
 `/apis/extensions/v1beta1`.
 
-We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-lifed and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
+We chose to version at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling access to end-of-life and/or experimental APIs. The JSON and Protobuf serialization schemas follow the same guidelines for schema changes - all descriptions below cover both formats.
 
 Note that API versioning and Software versioning are only indirectly related.  The [API and release
 versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and

content/en/docs/concepts/workloads/controllers/cron-jobs.md

@@ -47,7 +47,7 @@ It is important to note that if the `startingDeadlineSeconds` field is set (not
 A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.
 
 For example, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
-`startingDeadlineSeconds` field is not set. The default for this field is `100` seconds. If the CronJob controller happens to
+`startingDeadlineSeconds` field is not set. If the CronJob controller happens to
 be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
 
 To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -71,7 +71,7 @@ array has six possible fields:
   * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
     have started successfully;
   * `Unschedulable`: the scheduler cannot schedule the Pod right now, for example
-    due to lacking of resources or other constraints;
+    due to lack of resources or other constraints;
   * `ContainersReady`: all containers in the Pod are ready.
 
 

content/en/docs/setup/independent/troubleshooting-kubeadm.md

@@ -113,7 +113,7 @@ Right after `kubeadm init` there should not be any pods in these states.
 This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin
 should [install the pod network solution](/docs/concepts/cluster-administration/addons/)
 of choice. You have to install a Pod Network
-before CoreDNS may deployed fully. Hence the `Pending` state before the network is set up.
+before CoreDNS may be deployed fully. Hence the `Pending` state before the network is set up.
 
 ## `HostPort` services do not work
 

content/en/examples/controllers/daemonset.yaml

@@ -19,7 +19,7 @@ spec:
         effect: NoSchedule
       containers:
       - name: fluentd-elasticsearch
-        image: k8s.gcr.io/fluentd-elasticsearch:1.20
+        image: gcr.io/fluentd-elasticsearch/fluentd:v2.5.1
         resources:
           limits:
             memory: 200Mi

content/ja/examples/controllers/daemonset.yaml

@@ -19,7 +19,7 @@ spec:
         effect: NoSchedule
       containers:
       - name: fluentd-elasticsearch
-        image: k8s.gcr.io/fluentd-elasticsearch:1.20
+        image: gcr.io/fluentd-elasticsearch/fluentd:v2.5.1
         resources:
           limits:
             memory: 200Mi

content/zh/docs/concepts/workloads/controllers/daemonset.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1
 kind: DaemonSet
 metadata:
   name: fluentd-elasticsearch
@@ -13,7 +13,7 @@ spec:
     spec:
       containers:
       - name: fluentd-elasticsearch
-        image: k8s.gcr.io/fluentd-elasticsearch:1.20
+        image: gcr.io/fluentd-elasticsearch/fluentd:v2.5.1
         resources:
           limits:
             memory: 200Mi

content/zh/docs/concepts/workloads/pods/init-containers.md

@@ -41,15 +41,15 @@ Init 容器与普通的容器非常像，除了如下两点：
 
 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 值为 Never，它不会重新启动。
 
-指定容器为 Init 容器，需要在 PodSpec 中添加 `initContainers` 字段，以 [v1.Container](/docs/api-reference/v1.6/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。
+指定容器为 Init 容器，需要在 PodSpec 中添加 `initContainers` 字段，以 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。
 Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。
 
 
 
 ### 与普通容器的不同之处
 
 Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。
-然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#resources) 处有说明。
+然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#资源) 处有说明。
 而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
 
 如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。
@@ -62,8 +62,8 @@ Init 容器支持应用容器的全部字段和特性，包括资源限制、数
 
 因为 Init 容器具有与应用容器分离的单独镜像，它们的启动相关代码具有如下优势：
 
-* 它们可以包含并运行实用工具，处于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
-* 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用镜像中。例如，创建镜像没必要 `FROM` 另一个镜像，只需要在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具。
+* 它们可以包含并运行实用工具，出于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
+* 它们可以包含用于安装的工具和定制化代码，这些都是在应用镜像中没有的。例如，创建镜像没必要 `FROM` 另一个镜像，只需要在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具。
 * 应用镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
 * 它们使用 Linux Namespace，所以对应用容器具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用容器不能够访问。
 * 它们在应用容器启动之前运行完成，然而应用容器并行运行，所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动，直到满足了一组先决条件。