Merge remote-tracking branch 'upstream/master' into HEAD
This commit is contained in:
vineeth
@@ -23,30 +23,30 @@ The **v1.16** release will stop serving the following deprecated API versions in
|
||||
Existing persisted data can be retrieved/updated via the new version.
|
||||
* Notable changes:
|
||||
* `spec.templateGeneration` is removed
|
||||
* `spec.selector` is now required and immutable after creation
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate`
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `extensions/v1beta1` was `OnDelete`)
|
||||
* Deployment in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
|
||||
* Migrate to use the **apps/v1** API version, available since v1.9.
|
||||
Existing persisted data can be retrieved/updated via the new version.
|
||||
* Notable changes:
|
||||
* `spec.rollbackTo` is removed
|
||||
* `spec.selector` is now required and immutable after creation
|
||||
* `spec.progressDeadlineSeconds` now defaults to `600` seconds
|
||||
* `spec.revisionHistoryLimit` now defaults to `10`
|
||||
* `maxSurge` and `maxUnavailable` now default to `25%`
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.progressDeadlineSeconds` now defaults to `600` seconds (the default in `extensions/v1beta1` was no deadline)
|
||||
* `spec.revisionHistoryLimit` now defaults to `10` (the default in `apps/v1beta1` was `2`, the default in `extensions/v1beta1` was to retain all)
|
||||
* `maxSurge` and `maxUnavailable` now default to `25%` (the default in `extensions/v1beta1` was `1`)
|
||||
* StatefulSet in the **apps/v1beta1** and **apps/v1beta2** API versions is no longer served
|
||||
* Migrate to use the **apps/v1** API version, available since v1.9.
|
||||
Existing persisted data can be retrieved/updated via the new version.
|
||||
* Notable changes:
|
||||
* `spec.selector` is now required and immutable after creation
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate`
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
* `spec.updateStrategy.type` now defaults to `RollingUpdate` (the default in `apps/v1beta1` was `OnDelete`)
|
||||
* ReplicaSet in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
|
||||
* Migrate to use the **apps/v1** API version, available since v1.9.
|
||||
Existing persisted data can be retrieved/updated via the new version.
|
||||
* Notable changes:
|
||||
* `spec.selector` is now required and immutable after creation
|
||||
* `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades
|
||||
|
||||
The **v1.20** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
|
||||
The **v1.22** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
|
||||
|
||||
* Ingress in the **extensions/v1beta1** API version will no longer be served
|
||||
* Migrate to use the **networking.k8s.io/v1beta1** API version, available since v1.14.
|
||||
@@ -84,8 +84,8 @@ apiserver startup arguments:
|
||||
|
||||
Deprecations are announced in the Kubernetes release notes. You can see these
|
||||
announcements in
|
||||
[1.14](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#deprecations)
|
||||
and [1.15](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#deprecations-and-removals).
|
||||
[1.14](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.14.md#deprecations)
|
||||
and [1.15](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#deprecations-and-removals).
|
||||
|
||||
You can read more [in our deprecation policy document](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)
|
||||
about the deprecation policies for Kubernetes APIs, and other Kubernetes components.
|
||||
|
||||
@@ -186,7 +186,7 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:1.13-alpine
|
||||
image: nginx:1.16-alpine
|
||||
ports:
|
||||
- containerPort: 80
|
||||
volumeMounts:
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
layout: blog
|
||||
title: Join SIG Scalability and Learn Kubernetes the Hard Way
|
||||
date: 2020-03-19
|
||||
slug: join-sig-scalability
|
||||
---
|
||||
|
||||
**Authors:** Alex Handy
|
||||
|
||||
Contributing to SIG Scalability is a great way to learn Kubernetes in all its depth and breadth, and the team would love to have you [join as a contributor](https://github.com/kubernetes/community/tree/master/sig-scalability#scalability-special-interest-group). I took a look at the value of learning the hard way and interviewed the current SIG chairs to give you an idea of what contribution feels like.
|
||||
|
||||
## The value of Learning The Hard Way
|
||||
|
||||
There is a belief in the software development community that pushes for the most challenging and rigorous possible method of learning a new language or system. These tend to go by the moniker of "Learn \_\_ the Hard Way." Examples abound: Learn Code the Hard Way, Learn Python the Hard Way, and many others originating with Zed Shaw's courses in the topic.
|
||||
|
||||
While there are folks out there who offer you a "Learn Kubernetes the Hard Way" type experience (most notably [Kelsey Hightower's](https://github.com/kelseyhightower/kubernetes-the-hard-way)), any "Hard Way" project should attempt to cover every aspect of the core topic's principles.
|
||||
|
||||
Therefore, the real way to "Learn Kubernetes the Hard Way," is to join the CNCF and get involved in the project itself. And there is only one SIG that could genuinely offer a full-stack learning experience for Kubernetes: SIG Scalability.
|
||||
|
||||
The team behind SIG Scalability is responsible for detecting and dealing with issues that arise when Kubernetes clusters are working with upwards of a thousand nodes. Said [Wojiciech Tyczynski](https://github.com/wojtek-t), a staff software engineer at Google and a member of SIG Scalability, the standard size for a test cluster for this SIG is over 5,000 nodes.
|
||||
|
||||
And yet, this SIG is not composed of Ph.D.'s in highly scalable systems designs. Many of the folks working with Tyczynski, for example, joined the SIG knowing very little about these types of issues, and often, very little about Kubernetes.
|
||||
|
||||
Working on SIG Scalability is like jumping into the deep end of the pool to learn to swim, and the SIG is inherently concerned with the entire Kubernetes project. SIG Scalability focuses on how Kubernetes functions as a whole and at scale. The SIG Scalability team members have an impetus to learn about every system and to understand how all systems interact with one another.
|
||||
|
||||
## A complex and rewarding contributor experience
|
||||
|
||||
While that may sound complicated (and it is!), that doesn't mean it's outside the reach of an average developer, tester, or administrator. Google software developer Matt Matejczyk has only been on the team since the beginning of 2019, and he's been a valued member of the team since then, ferreting out bugs.
|
||||
|
||||
"I am new here," said Matejczyk. "I joined the team in January [2019]. Before that, I worked on AdWords at Google in New York. Why did I join? I knew some people there, so that was one of the decisions for me to move. I thought at that time that Kubernetes is a unique, cutting edge technology. I thought it'd be cool to work on that."
|
||||
|
||||
Matejczyk was correct about the coolness. "It's cool," he said. "So actually, ramping up on scalability is not easy. There are many things you need to understand. You need to understand Kubernetes very well. It can use every part of Kubernetes. I am still ramping up after these 8 months. I think it took me maybe 3 months to get up to decent speed."
|
||||
|
||||
When Matejczyk spoke to what he had worked on during those 8 months, he answered, "An interesting example is a regression I have been working on recently. We noticed the overall slowness of Kubernetes control plane in specific scenarios, and we couldn't attribute it to any particular component. In the end, we realized that everything boiled down to the memory allocation on the golang level. It was very counterintuitive to have two completely separate pieces of code (running as a part of the same binary) affecting the performance of each other only because one of them was allocating memory too fast. But connecting all the dots and getting to the bottom of regression like this gives great satisfaction."
|
||||
|
||||
Tyczynski said that "It's not only debugging regressions, but it's also debugging and finding bottlenecks. In general, those can be regressions, but those can be things we can improve. The other significant area is extending what we want to guarantee to users. Extending SLA and SLO coverage of the system so users can rely on what they can expect from the system in terms of performance and scalability. Matt is doing much work in extending our tests to be more representative and cover more Kubernetes concepts."
|
||||
|
||||
## Give SIG Scalability a try
|
||||
|
||||
The SIG Scalability team is always in need of new members, and if you're the sort of developer or tester who loves taking on new complex challenges, and perhaps loves learning things the hard way, consider joining this SIG. As the team points out, adding Kubernetes expertise to your resume is never a bad idea, and this is the one SIG where you can learn it all from top to bottom.
|
||||
|
||||
See [the SIG's documentation](https://github.com/kubernetes/community/tree/master/sig-scalability#scalability-special-interest-group) to learn about upcoming meetings, its charter, and more. You can also join the [#sig-scalability Slack channel](https://kubernetes.slack.com/archives/C09QZTRH7) to see what it's like. We hope to see you join in to take advantage of this great opportunity to learn Kubernetes and contribute back at the same time.
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
layout: blog
|
||||
title: 'Kong Ingress Controller and Service Mesh: Setting up Ingress to Istio on Kubernetes'
|
||||
date: 2020-03-18
|
||||
slug: kong-ingress-controller-and-istio-service-mesh
|
||||
---
|
||||
|
||||
**Author:** Kevin Chen, Kong
|
||||
|
||||
Kubernetes has become the de facto way to orchestrate containers and the services within services. But how do we give services outside our cluster access to what is within? Kubernetes comes with the Ingress API object that manages external access to services within a cluster.
|
||||
|
||||
Ingress is a group of rules that will proxy inbound connections to endpoints defined by a backend. However, Kubernetes does not know what to do with Ingress resources without an Ingress controller, which is where an open source controller can come into play. In this post, we are going to use one option for this: the Kong Ingress Controller. The Kong Ingress Controller was open-sourced a year ago and recently reached one million downloads. In the recent 0.7 release, service mesh support was also added. Other features of this release include:
|
||||
|
||||
* **Built-In Kubernetes Admission Controller**, which validates Custom Resource Definitions (CRD) as they are created or updated and rejects any invalid configurations.
|
||||
* **In-memory Mode** - Each pod’s controller actively configures the Kong container in its pod, which limits the blast radius of failure of a single container of Kong or controller container to that pod only.
|
||||
* **Native gRPC Routing** - gRPC traffic can now be routed via Kong Ingress Controller natively with support for method-based routing.
|
||||
|
||||
|
||||
|
||||
If you would like a deeper dive into Kong Ingress Controller 0.7, please check out the [GitHub repository](https://github.com/Kong/kubernetes-ingress-controller).
|
||||
|
||||
But let’s get back to the service mesh support since that will be the main focal point of this blog post. Service mesh allows organizations to address microservices challenges related to security, reliability, and observability by abstracting inter-service communication into a mesh layer. But what if our mesh layer sits within Kubernetes and we still need to expose certain services beyond our cluster? Then you need an Ingress controller such as the Kong Ingress Controller. In this blog post, we’ll cover how to deploy Kong Ingress Controller as your Ingress layer to an Istio mesh. Let’s dive right in:
|
||||
|
||||
|
||||
|
||||
### Part 0: Set up Istio on Kubernetes
|
||||
|
||||
This blog will assume you have Istio set up on Kubernetes. If you need to catch up to this point, please check out the [Istio documentation](https://istio.io/docs/setup/). It will walk you through setting up Istio on Kubernetes.
|
||||
|
||||
### 1. Install the Bookinfo Application
|
||||
|
||||
First, we need to label the namespaces that will host our application and Kong proxy. To label our default namespace where the bookinfo app sits, run this command:
|
||||
|
||||
```
|
||||
$ kubectl label namespace default istio-injection=enabled
|
||||
namespace/default labeled
|
||||
```
|
||||
|
||||
Then create a new namespace that will be hosting our Kong gateway and the Ingress controller:
|
||||
|
||||
```
|
||||
$ kubectl create namespace kong
|
||||
namespace/kong created
|
||||
```
|
||||
|
||||
Because Kong will be sitting outside the default namespace, be sure you also label the Kong namespace with istio-injection enabled as well:
|
||||
|
||||
```
|
||||
$ kubectl label namespace kong istio-injection=enabled
|
||||
namespace/kong labeled
|
||||
```
|
||||
|
||||
Having both namespaces labeled `istio-injection=enabled` is necessary. Or else the default configuration will not inject a sidecar container into the pods of your namespaces.
|
||||
|
||||
Now deploy your BookInfo application with the following command:
|
||||
|
||||
```
|
||||
$ kubectl apply -f http://bit.ly/bookinfoapp
|
||||
service/details created
|
||||
serviceaccount/bookinfo-details created
|
||||
deployment.apps/details-v1 created
|
||||
service/ratings created
|
||||
serviceaccount/bookinfo-ratings created
|
||||
deployment.apps/ratings-v1 created
|
||||
service/reviews created
|
||||
serviceaccount/bookinfo-reviews created
|
||||
deployment.apps/reviews-v1 created
|
||||
deployment.apps/reviews-v2 created
|
||||
deployment.apps/reviews-v3 created
|
||||
service/productpage created
|
||||
serviceaccount/bookinfo-productpage created
|
||||
deployment.apps/productpage-v1 created
|
||||
```
|
||||
|
||||
Let’s double-check our Services and Pods to make sure that we have it all set up correctly:
|
||||
|
||||
```
|
||||
$ kubectl get services
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
details ClusterIP 10.97.125.254 <none> 9080/TCP 29s
|
||||
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 29h
|
||||
productpage ClusterIP 10.97.62.68 <none> 9080/TCP 28s
|
||||
ratings ClusterIP 10.96.15.180 <none> 9080/TCP 28s
|
||||
reviews ClusterIP 10.104.207.136 <none> 9080/TCP 28s
|
||||
```
|
||||
|
||||
You should see four new services: details, productpage, ratings, and reviews. None of them have an external IP so we will use the [Kong gateway](https://github.com/Kong/kong) to expose the necessary services. And to check pods, run the following command:
|
||||
|
||||
```
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
details-v1-c5b5f496d-9wm29 2/2 Running 0 101s
|
||||
productpage-v1-7d6cfb7dfd-5mc96 2/2 Running 0 100s
|
||||
ratings-v1-f745cf57b-hmkwf 2/2 Running 0 101s
|
||||
reviews-v1-85c474d9b8-kqcpt 2/2 Running 0 101s
|
||||
reviews-v2-ccffdd984-9jnsj 2/2 Running 0 101s
|
||||
reviews-v3-98dc67b68-nzw97 2/2 Running 0 101s
|
||||
```
|
||||
|
||||
This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page!
|
||||
|
||||
```
|
||||
$ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
|
||||
<title>Simple Bookstore App</title>
|
||||
```
|
||||
|
||||
### 2. Kong Kubernetes Ingress Controller Without Database
|
||||
|
||||
To expose your services to the world, we will deploy Kong as the north-south traffic gateway. [Kong 1.1](https://github.com/Kong/kong/releases/tag/1.1.2) released with declarative configuration and DB-less mode. Declarative configuration allows you to specify the desired system state through a YAML or JSON file instead of a sequence of API calls. Using declarative config provides several key benefits to reduce complexity, increase automation and enhance system performance. And with the Kong Ingress Controller, any Ingress rules you apply to the cluster will automatically be configured on the Kong proxy. Let’s set up the Kong Ingress Controller and the actual Kong proxy first like this:
|
||||
|
||||
```
|
||||
$ kubectl apply -f https://bit.ly/k4k8s
|
||||
namespace/kong configured
|
||||
customresourcedefinition.apiextensions.k8s.io/kongconsumers.configuration.konghq.com created
|
||||
customresourcedefinition.apiextensions.k8s.io/kongcredentials.configuration.konghq.com created
|
||||
customresourcedefinition.apiextensions.k8s.io/kongingresses.configuration.konghq.com created
|
||||
customresourcedefinition.apiextensions.k8s.io/kongplugins.configuration.konghq.com created
|
||||
serviceaccount/kong-serviceaccount created
|
||||
clusterrole.rbac.authorization.k8s.io/kong-ingress-clusterrole created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/kong-ingress-clusterrole-nisa-binding created
|
||||
configmap/kong-server-blocks created
|
||||
service/kong-proxy created
|
||||
service/kong-validation-webhook created
|
||||
deployment.apps/ingress-kong created
|
||||
```
|
||||
|
||||
To check if the Kong pod is up and running, run:
|
||||
|
||||
```
|
||||
$ kubectl get pods -n kong
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/ingress-kong-8b44c9856-9s42v 3/3 Running 0 2m26s
|
||||
```
|
||||
|
||||
There will be three containers within this pod. The first container is the Kong Gateway that will be the Ingress point to your cluster. The second container is the Ingress controller. It uses Ingress resources and updates the proxy to follow rules defined in the resource. And lastly, the third container is the Envoy proxy injected by Istio. Kong will route traffic through the Envoy sidecar proxy to the appropriate service. To send requests into the cluster via our newly deployed Kong Gateway, setup an environment variable with the a URL based on the IP address at which Kong is accessible.
|
||||
|
||||
```
|
||||
$ export PROXY_URL="$(minikube service -n kong kong-proxy --url | head -1)"
|
||||
$ echo $PROXY_URL
|
||||
http://192.168.99.100:32728
|
||||
```
|
||||
|
||||
Next, we need to change some configuration so that the side-car Envoy process can route the request correctly based on the host/authority header of the request. Run the following to stop the route from preserving host:
|
||||
|
||||
```
|
||||
$ echo "
|
||||
apiVersion: configuration.konghq.com/v1
|
||||
kind: KongIngress
|
||||
metadata:
|
||||
name: do-not-preserve-host
|
||||
route:
|
||||
preserve_host: false
|
||||
" | kubectl apply -f -
|
||||
kongingress.configuration.konghq.com/do-not-preserve-host created
|
||||
```
|
||||
|
||||
And annotate the existing productpage service to set service-upstream as true:
|
||||
|
||||
```
|
||||
$ kubectl annotate svc productpage Ingress.kubernetes.io/service-upstream="true"
|
||||
service/productpage annotated
|
||||
```
|
||||
|
||||
Now that we have everything set up, we can look at how to use the Ingress resource to help route external traffic to the services within your Istio mesh. We’ll create an Ingress rule that routes all traffic with the path of `/` to our productpage service:
|
||||
|
||||
```
|
||||
$ echo "
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: productpage
|
||||
annotations:
|
||||
configuration.konghq.com: do-not-preserve-host
|
||||
spec:
|
||||
rules:
|
||||
- http:
|
||||
paths:
|
||||
- path: /
|
||||
backend:
|
||||
serviceName: productpage
|
||||
servicePort: 9080
|
||||
" | kubectl apply -f -
|
||||
ingress.extensions/productpage created
|
||||
```
|
||||
|
||||
And just like that, the Kong Ingress Controller is able to understand the rules you defined in the Ingress resource and routes it to the productpage service! To view the product page service’s GUI, go to `$PROXY_URL/productpage` in your browser. Or to test it in your command line, try:
|
||||
|
||||
```
|
||||
$ curl $PROXY_URL/productpage
|
||||
```
|
||||
|
||||
That is all I have for this walk-through. If you enjoyed the technologies used in this post, please check out their repositories since they are all open source and would love to have more contributors! Here are their links for your convenience:
|
||||
|
||||
* Kong: [[GitHub](https://github.com/Kong/kubernetes-ingress-controller)] [[Twitter](https://twitter.com/thekonginc)]
|
||||
* Kubernetes: [[GitHub](https://github.com/kubernetes/kubernetes)] [[Twitter](https://twitter.com/kubernetesio)]
|
||||
* Istio: [[GitHub](https://github.com/istio/istio)] [[Twitter](https://twitter.com/IstioMesh)]
|
||||
* Envoy: [[GitHub](https://github.com/envoyproxy/envoy)] [[Twitter](https://twitter.com/EnvoyProxy)]
|
||||
|
||||
Thank you for following along!
|
||||
Reference in New Issue
Block a user