From 4fa93f5029a8313716dcc84874fe87c1fd20643e Mon Sep 17 00:00:00 2001 From: RichieEscarez Date: Wed, 30 Jan 2019 09:56:37 -0800 Subject: [PATCH] site: add blog (#837) * add blog folder * switch to sentence case --- blog/_index.md | 12 ++++++++++++ ...-workloads-using-Knative-on-Kubernetes.html | 18 ++++++++++++++++++ blog/articles/_index.md | 6 ++++++ blog/events/Knative-at-KubeCon-Seattle.html | 15 +++++++++++++++ blog/events/_index.md | 5 +++++ .../Announcing-Knative-v0-2-Release.html | 15 +++++++++++++++ .../Announcing-Knative-v0-3-Release.html | 15 +++++++++++++++ blog/releases/_index.md | 5 +++++ community/_index.md | 10 ++++++++++ 9 files changed, 101 insertions(+) create mode 100644 blog/_index.md create mode 100644 blog/articles/Build--deploy--manage-modern-serverless-workloads-using-Knative-on-Kubernetes.html create mode 100644 blog/articles/_index.md create mode 100644 blog/events/Knative-at-KubeCon-Seattle.html create mode 100644 blog/events/_index.md create mode 100644 blog/releases/Announcing-Knative-v0-2-Release.html create mode 100644 blog/releases/Announcing-Knative-v0-3-Release.html create mode 100644 blog/releases/_index.md create mode 100644 community/_index.md diff --git a/blog/_index.md b/blog/_index.md new file mode 100644 index 000000000..dda673597 --- /dev/null +++ b/blog/_index.md @@ -0,0 +1,12 @@ +--- +title: "Knative blog" +linkTitle: "Blog" +menu: + main: + weight: 30 +--- + + +Welcome to the Knative **blog** section. Keep up-to-date with product and +release announcements, read articles, hear about recent social events, and +find out where the Knative team will be talking next. diff --git a/blog/articles/Build--deploy--manage-modern-serverless-workloads-using-Knative-on-Kubernetes.html b/blog/articles/Build--deploy--manage-modern-serverless-workloads-using-Knative-on-Kubernetes.html new file mode 100644 index 000000000..356490297 --- /dev/null +++ b/blog/articles/Build--deploy--manage-modern-serverless-workloads-using-Knative-on-Kubernetes.html @@ -0,0 +1,18 @@ +--- +title: "Build, deploy, manage modern serverless workloads using Knative on Kubernetes" +linkTitle: "Serverless workloads using Knative" +date: 2018-11-14 +description: "Learn how to build, deploy, and manage modern serverless workloads using Knative on Kubernetes." +--- + +
+
+By now, Kubernetes should be the default target for your deployments. Yes, there are still use-cases where Kubernetes is not the optimal… +
+
+By now, Kubernetes should be the default target for your deployments. Yes, there are still use-cases where Kubernetes is not the optimal… +
+
+

Build, deploy, manage modern serverless workloads using Knative on Kubernetes

By now, Kubernetes should be the default target for your deployments. Yes, there are still use-cases where Kubernetes is not the optimal choice, but these represent an increasingly smaller number of modern workloads.

The main value of Kubernetes is that it greatly abstracts much of the infrastructure management pain. The broad support amongst virtually all major Cloud Service Providers (CSP) also means that your workloads are portable. Combined with the already vibrant ecosystem of Kubernetes-related tools, means that the experience of the operator, the person responsible for managing Kubernetes, is now pretty smooth.

But what about the experience of the developer, the person who builds solutions on top of Kubernetes?

Despite what some might tell you, Kubernetes is not yet today’s application server. For starters, the act of developing, deploying and managing services on Kubernetes is still too complicated. Yes, there are many open source projects for logging, monitoring, integration, etc., but, even if you put these together just right, the experience of developing on Kubernetes is still fragile and way too labour-intensive.

As if that wasn’t enough, the growing popularity of functions as the atomic unit of code development further contributes to the overall complexity. Often creating different development patterns on two disconnected surface areas:one for functions (FaaS) and one for applications (PaaS).

As the result, developers today are being forced to worry about infrastructure-related concerns: such as, image building, registry publishing, deployment services, load balancing, logging, monitoring, and scaling. However, what all they really want to do is write code.

Introducing Knative

At Google Cloud Next in San Francisco this week, Google announced an early preview of the GKE serverless add-on (g.co/serverlessaddon). Google also open-sourced Knative (kay-nay-tiv), the project that powers the serverless add-on (github.com/knative).

Knative implements many of the learnings from Google. The open source project already has contributions from companies like Pivotal, IBM, Red Hat and SAP and collaboration with open-source Function-as-a-Service framework communities like OpenWhisk, riff, and Kyma who either replatform on to Knative or consume one or more components from the Knative project.

Knative audience
Knative helps developers build, deploy, and manage modern serverless workloads on Kubernetes.

It provides a set of building blocks that enable modern, source-centric and container-based development workloads on Kubernetes:

  • Build — Source-to-container build orchestration
  • Eventing — Management and delivery of events
  • Serving — Request-driven compute that can scale to zero

Knative documentation provides instructions on how to install it on hosted Kubernetes offering like Google Cloud Platform or IBM, and on-prem Kubernetes installations, like the one offered by Pivotal. Finally, Knative repository also includes samples and how-to instructions to get you started developing on Kubernetes.

Knative Overview

Knative is based on the premise of clear separation of concerns. It allows developers and operators to reason about the workload development, deployment, and management by defining primitive objects in a form of Custom Resource Definitions (CRDs) which extend on the object model found in Kubernetes.

Knative defines primitives with clear separation of concerns
  • Configuration — is the desired state for your service, both code and configuration
  • Revision — represents an immutable point-in-time snapshot of your code and configuration
  • Route — assigns traffic to a revision or revisions of your service
  • Service — is the combined lite version of all the above objects to enable simple use cases

In addition to these objects, Knative also defines principle objects for eventing… you know, because serverless. Knative decouples event producers and consumers and implements CNCF CloudEvents (v0.1) to streamline event processing.

Knative eventing constructs
  • Event Sources — represents the producer of events (e.g. GitHub)
  • Event Types — describes the types of events supported by the different event sources (e.g. Webhook for the above mentioned GitHub source)
  • Event Consumers — represents the target of your action (i.e. any route defined by Knative)
  • Event Feeds — is the binding or configuration connecting the event types to actions

The functional implementation of the Knative object model means that Knative is both easy to start with, but capable enough to address more advanced use cases as the complexity of your solutions increases.

Summary

I hope this introduction gave you an understanding of the value of Knative. And how the Knative objects streamline development on Kubernetes, regardless if you work on applications or functions.

Over the next few weeks I will be covering each one of the key Knative usage patterns (image push, blue/green deployment model, source to URL, etc). In each post, I will also provide a sample code to illustrate that pattern and allow you to reproduce them on Knative. I’m super excited to share Knative with you, and I hope you come back to find out more.

+
+
diff --git a/blog/articles/_index.md b/blog/articles/_index.md new file mode 100644 index 000000000..291488d44 --- /dev/null +++ b/blog/articles/_index.md @@ -0,0 +1,6 @@ +--- +title: "Knative articles" +linkTitle: "Articles" +weight: 30 +--- + diff --git a/blog/events/Knative-at-KubeCon-Seattle.html b/blog/events/Knative-at-KubeCon-Seattle.html new file mode 100644 index 000000000..323b008a4 --- /dev/null +++ b/blog/events/Knative-at-KubeCon-Seattle.html @@ -0,0 +1,15 @@ +--- +title: "Knative at KubeCon Seattle" +linkTitle: "KubeCon 2018" +date: 2018-12-04 +description: "Knative sessions at KubeCon" +--- + +
+
+As we approach KubeCon and CloudNativeCon in Seattle (Dec. 11–13), we wanted to share the different Knative-related sessions that will be… +
+
+

Knative at KubeCon Seattle

Update (2018–12–19): Added sessions/keynotes/interviews links to videos

KubeCon SEA 2018

As we approach KubeCon and CloudNativeCon in Seattle (Dec. 11–13), we wanted to share the different Knative-related sessions that will be offered next week.

We are proud of the project’s progress so far. The number of sessions, variety of topics, and number of different companies represented by the speakers, truly represent the breadth of the growing community behind Knative.

Monday, Dec 10

Tuesday, Dec 11

Wednesday, Dec 12

Thursday, Dec 13

Looking forward to seeing you in Seattle next week. Remember, if you can’t attend, there will be a live video broadcast from the keynotes, and the break-out sessions should also be available shortly after the conference.

+
+
diff --git a/blog/events/_index.md b/blog/events/_index.md new file mode 100644 index 000000000..00aa8859a --- /dev/null +++ b/blog/events/_index.md @@ -0,0 +1,5 @@ +--- +title: "Knative social events" +linkTitle: "Events" +weight: 20 +--- diff --git a/blog/releases/Announcing-Knative-v0-2-Release.html b/blog/releases/Announcing-Knative-v0-2-Release.html new file mode 100644 index 000000000..7cf2255d1 --- /dev/null +++ b/blog/releases/Announcing-Knative-v0-2-Release.html @@ -0,0 +1,15 @@ +--- +title: "Announcing the Knative v0.2 release" +linkTitle: "Version 0.2 release" +date: 2018-11-14 +description: "The Knative v0.2 release announcement" +--- + +
+
+Improved pluggability, autoscaling, stability, and performance +
+
+

Announcing Knative v0.2 Release

Improved pluggability, autoscaling, stability, and performance

We are excited to announce a new release of Knative, the set of middleware components for building modern applications on Kubernetes. The 0.2 release of Knative is the first significant update since the project’s launch in July. It represents months of hard work by the entire Knative community to address our learnings from the growing number of Knative deployments.

The most exciting aspect of the 0.2 release is the inclusion of eventing. The Eventing component complements the other two foundational blocks already defined by Knative: Serving and Build. We look forward to the new types of events and innovative solutions the community will develop using this new capability.

Serving made significant improvements “under the hood,” encapsulating key areas of Knative into subsystems with new internal APIs to enable support for pluggable networking, autoscaling, and caching.

The complete release notes are available in Knative Serving, Build, and Eventing repositories. Here are a few highlights:

New Eventing Resource Model 
The eventing repo went through a significant rework of the resource model, resulting in migration of sources into Custom Resource Definitions (CRDs). Now, eventing includes a sophisticated use of standard Kubernetes concepts, resulting in better validation, cleaner interfaces, and RBAC support. The new architecture uses a simpler object model that is centered around channels and subscriptions.

Looser Coupling
One of the pieces of positive feedback we received on v0.1 was the “tasteful” choices defining Knative building blocks. In v0.2, Knative leans into this even further to enable operators to install the Build, Serving, and Eventing components independent of one another. The contract that enables these loose couplings between Knative components will also enable third party integrations over time, such as using a non-Knative Build with Serving, or delivering events to non-Serving deployments. We are excited to see what direction the community takes this.

Pluggable Subsystems
We also got a lot of feedback about wanting to customize Knative. The goal was always to support some measure of pluggability, so customization was significantly improved in v0.2. We introduced 3 new internal APIs in v0.2 to separate our core resource model from the subsystems that implement them: Networking, Autoscaling, and Caching. Networking enables developers to replace our Istio dependency with alternative ingress implementations. Autoscaling enables developers to replace our “cheap and cheerful” autoscaler with one of their own designs. Caching enables developers to employ image caching strategies to preload container images across their cluster (no implementation bundled, so this is a pure extension-point).

Improved Cold-Starts
Two of the dominant factors in cold-start performance are side-car injection and image pull latency. With their 1.0.2 release, Istio has made progress on reducing the Envoy programming time. In addition, we’ve made it possible to install Knative with side-car injection disabled. To enable folks to combat image pull latency, we have exposed a new extension point called an “Image” resource (part of knative/caching), which contains all the information needed for a controller to pre-load user images across a cluster. Caching is another feature we are excited to see the community build upon.

Autoscaling
We have replaced the previous per-Revision autoscalers with a single shared autoscaler. The new autoscaler is based on the same logic as the previous autoscaler, but has evolved to be purely metrics driven (including 0->1->0), eliminating the unnecessary Revision servingState field. We have replaced ConcurrencyModel (Single or Multi) with an integer ContainerConcurrency field. This allows limiting concurrency to values other than 1 for certain use cases (for example, limited thread pools).

Build
Knative Build added many incremental improvements, including the new ClusterBuildTemplate resource. Operators are now able to install a set of BuildTemplates one time instead of once per-Namespace. Build template parameters can now also apply to build step image names. New features of the Build spec allow users to specify a build-wide timeout, node selectors, and affinity. Last but not least, build status has been extended to report per-step build progress and build pending times.

Knative at KubeCon

Come and talk to us! There are a number of Knative sessions at the upcoming KubeCon conferences, both in Shanghai and Seattle.

Shanghai

Seattle

+
+
diff --git a/blog/releases/Announcing-Knative-v0-3-Release.html b/blog/releases/Announcing-Knative-v0-3-Release.html new file mode 100644 index 000000000..b006e7567 --- /dev/null +++ b/blog/releases/Announcing-Knative-v0-3-Release.html @@ -0,0 +1,15 @@ +--- +title: "Announcing the Knative v0.3 release" +linkTitle: "Version 0.3 release" +date: 2019-01-15 +description: "The Knative v0.3 release announcement" +--- + +
+
+Knative’s momentum continues! Once again, we are excited to announce a new release of Knative. After a series of architectural changes… +
+
+

Announcing Knative v0.3 Release

Knative’s momentum continues! Once again, we are excited to announce a new release of Knative. After a series of architectural changes announced in the previous release, v0.3 implements many of the learnings from the growing number of Knative deployments, increases operational control, and improves stability.

As we move to a more predictable release schedule based on six week cadence, Knative releases will now be smaller and more frequent. We did this to enable a tighter feedback loop with our users and allow for smoother course corrections as we continue to learn from our growing number of users.

Starting with the v0.3 release, Knative now requires Kubernetes 1.11, due to the use of `/status` sub-resource support, which went Beta in Kubernetes 1.11 and fixes a long-standing Kubernetes CRD bug.

The complete set of Knative v0.3 release notes outlining the new features as well as bug fixes and architectural changes are available in the Serving, Build, and Eventing repositories. Here are a few highlights:

Serving API

With the v0.3 release, Knative now exposes a few additional parameters in its API. These include explicit Revision timeouts and the ability to specify the port for incoming traffic to the user container, which Knative previously exposed to the container using the “$PORT” environment variable.

An even bigger addition is support for the Kubernetes resources spec, which allows you to specify reservations and limits on the user container. Besides allowing the service to specify how much CPU and memory (RAM) it needs or limit how much it can use; this also allows developers to request access to hardware accelerators like GPU if their cluster includes nodes configured with that capability.

In v0.3, Knative is also more proactive about rolling out operator changes. Changes to serving ConfigMaps are now immediately reconciled and rolled out.

Autoscaling

Building on the new single shared autoscaler introduced in the previous release, v0.3 introduces a more aggressive scale-to-zero strategy, which will by default scale Revisions down to zero pods after only 30 seconds of inactivity. The default Knative Pod Autoscaler (KPA) now supports revision-level concurrency targets.

As shown in our Kubecon demo, Knative now offers Horizontal Pod Autoscaler (HPA). This is useful for those who need to opt-out of KPA and use CPU instead of request rate as a scaling metric. (Note: HPA-class Revisions will not scale to zero).

Lastly, you can now also mutate `PodAutoscaler` specs in-place to adjust the scale bounds and other parameters.

Networking

A frequently-requested feature is the ability to deploy services which are not exposed externally and can only be accessed by other services in the cluster. In v0.3, Routes configured to use the `svc.cluster.local` domain will only be exposed to the cluster-local Istio gateway. The cluster-local gateway will keep the deployed service inaccessible from outside the cluster. Developers can also use the `serving.knative.dev/visibility=cluster-local` label on their Route or Service to enable this behaviour.

Knative is also deprecating its dedicated Istio gateway. In v0.3 release, Knative will still expose public routes to both the deprecated gateway and the default Istio gateway. Starting with next release however, Knative will remove the deprecated gateway to further reduce overhead and avoid the additional cost of public IP. (Note, you may have to update the gateway IP in your DNS mappings).

Eventing

With the inclusion of Eventing in the previous release, there has been a significant focus on extending the number of and documenting available external event sources which can be installed in Knative as Kubernetes Custom Resource Definitions (CRDs). The complete list of currently supported event sources can be found here.

Build

The Knative Build component can now support both single `source` and multiple input `sources`. If multiple sources are requested, each will be fetched in declared order and placed into a directory under `/workspace` named after the source’s name field. The Build controller is also now subject to the PodSecurityPolicy which enables cluster operators to specify further limitations.

Monitoring

Metric labels should now be consistent across all of the Knative components. Also, in addition to the default Prometheus metric target, Knative control plane metrics (from Reconciler, Autoscaler, and Activator) can now be exported directly to Stackdriver.

Learn more

+
+
diff --git a/blog/releases/_index.md b/blog/releases/_index.md new file mode 100644 index 000000000..f134d14dc --- /dev/null +++ b/blog/releases/_index.md @@ -0,0 +1,5 @@ +--- +title: "Knative releases" +linkTitle: "Releases" +weight: 20 +--- diff --git a/community/_index.md b/community/_index.md new file mode 100644 index 000000000..5b92f247e --- /dev/null +++ b/community/_index.md @@ -0,0 +1,10 @@ +--- +title: Community +menu: + main: + weight: 40 +--- + + + +