Skip to content

Commit 62685e7

Browse files
astoycosastoycos
committed
The beginnings of a website
Signed-off-by: astoycos <[email protected]>
1 parent c0938a6 commit 62685e7

File tree

4 files changed

+198
-0
lines changed

4 files changed

+198
-0
lines changed

‎mkdocs.yml

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
site_name: Kubernetes AdminNetworkPolicy API
2+
repo_url: https://github.com/kubernetes-sigs/network-policy-api
3+
repo_name: kubernetes-sigs/network-policy-api
4+
site_dir: site
5+
docs_dir: site-src
6+
theme:
7+
name: material
8+
icon:
9+
repo: fontawesome/brands/git-alt
10+
logo: images/k8s-favicon.png
11+
favicon: images/k8s-favicon.png
12+
features:
13+
- search.highlight
14+
- navigation.tabs
15+
- navigation.top
16+
edit_uri: edit/main/site-src/
17+
plugins:
18+
- search
19+
- awesome-pages
20+
- macros:
21+
include_dir: examples
22+
j2_line_comment_prefix: "#$"
23+
markdown_extensions:
24+
- admonition
25+
- meta
26+
- pymdownx.emoji:
27+
emoji_index: !!python/name:materialx.emoji.twemoji
28+
emoji_generator: !!python/name:materialx.emoji.to_svg
29+
- pymdownx.highlight
30+
- pymdownx.inlinehilite
31+
- pymdownx.superfences
32+
- pymdownx.snippets
33+
- toc:
34+
permalink: true
35+
nav:
36+
- Overview:
37+
- Introduction: index.md
38+
- Concepts:
39+
API overview: concepts/api-overview.md
40+
Security Model: concepts/security-model.md
41+
Implementation Guidelines: concepts/guidelines.md
42+
Versioning: concepts/versioning.md
43+
- Implementations: implementations.md
44+
- FAQ: faq.md
45+
# - Guides:
46+
# - Getting started: guides/getting-started.md
47+
# - Simple Gateway: guides/simple-gateway.md
48+
# - HTTP routing: guides/http-routing.md
49+
# - HTTP redirects and rewrites: guides/http-redirect-rewrite.md
50+
# - HTTP traffic splitting: guides/traffic-splitting.md
51+
# - Cross-Namespace routing: guides/multiple-ns.md
52+
# - TLS: guides/tls.md
53+
# - TCP routing: guides/tcp.md
54+
# # - Reference:
55+
# - API Types:
56+
# GatewayClass: api-types/gatewayclass.md
57+
# Gateway: api-types/gateway.md
58+
# HTTPRoute: api-types/httproute.md
59+
# ReferenceGrant: api-types/referencegrant.md
60+
# - API specification: references/spec.md
61+
# - Policy Attachment: references/policy-attachment.md
62+
# - Enhancement Proposals:
63+
# - Overview: contributing/gep.md
64+
# - ... | geps/gep-*.md
65+
# - Contributing:
66+
# - Developer guide: contributing/devguide.md
67+
# - Enhancement Tracking and Backlog: contributing/enhancement-requests.md
68+
# - Community: contributing/community.md
69+
# - Blog:
70+
# - Index: blog/index.md
71+
# - 2021:
72+
# - blog/2021/introducing-v1alpha2.md

‎site-src/docs/index.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
# Welcome to MkDocs
2+
3+
For full documentation visit [mkdocs.org](https://www.mkdocs.org).
4+
5+
## Commands
6+
7+
* `mkdocs new [dir-name]` - Create a new project.
8+
* `mkdocs serve` - Start the live-reloading docs server.
9+
* `mkdocs build` - Build the documentation site.
10+
* `mkdocs -h` - Print help message and exit.
11+
12+
## Project layout
13+
14+
mkdocs.yml # The configuration file.
15+
docs/
16+
index.md # The documentation homepage.
17+
... # Other markdown pages, images and other files.

‎site-src/images/k8s-favicon.png

24 KB
Loading

‎site-src/index.md

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
## What is the AdminNetworkPolicy API?
2+
3+
The AdminNetworkPolicy API is an open source project managed by the [SIG-NETWORK][sig-network]
4+
community. It is a collection of resources, which aim to make securing Kubernetes
5+
clusters easier for Administrators.
6+
7+
![Gateway API Model](./images/api-model.png)
8+
9+
## Getting started
10+
11+
Whether you are a user interested in using the Gateway API or an implementer
12+
interested in conforming to the API, the following resources will help give
13+
you the necessary background:
14+
15+
- [API overview](/concepts/api-overview)
16+
- [User guides](/guides/getting-started)
17+
- [Gateway controller implementations](/implementations)
18+
- [API reference spec](/references/spec)
19+
- [Community links](/contributing/community) and [developer guide](/contributing/devguide)
20+
21+
22+
## Gateway API concepts
23+
The following design goals drive the concepts of the Gateway API. These
24+
demonstrate how Gateway aims to improve upon current standards like Ingress.
25+
26+
27+
- **Role-oriented** - Gateway is composed of API resources which model
28+
organizational roles that use and configure Kubernetes service networking.
29+
- **Portable** - This isn't an improvement but rather something
30+
that should stay the same. Just as Ingress is a universal specification with
31+
[numerous implementations](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/),
32+
Gateway API is designed to be a portable specification supported by many
33+
implementations.
34+
- **Expressive** - Gateway API resources support core functionality for things
35+
like header-based matching, traffic weighting, and other capabilities that
36+
were only possible in Ingress through custom annotations.
37+
- **Extensible** - Gateway API allows for custom resources to be linked at
38+
various layers of the API. This makes granular customization possible at the
39+
appropriate places within the API structure.
40+
41+
Some other notable capabilities include:
42+
43+
- **GatewayClasses** - GatewayClasses formalize types of load balancing
44+
implementations. These classes make it easy and explicit for users to
45+
understand what kind of capabilities are available via the Kubernetes resource
46+
model.
47+
- **Shared Gateways and cross-Namespace support** - They allow the sharing of
48+
load balancers and VIPs by permitting independent Route resources to attach to
49+
the same Gateway. This allows teams (even across Namespaces) to share
50+
infrastructure safely without direct coordination.
51+
- **Typed Routes and typed backends** - The Gateway API supports typed Route
52+
resources and also different types of backends. This allows the API to be
53+
flexible in supporting various protocols (like HTTP and gRPC) and
54+
various backend targets (like Kubernetes Services, storage buckets, or
55+
functions).
56+
57+
58+
## Why does a role-oriented API matter?
59+
60+
Whether it’s roads, power, data centers, or Kubernetes clusters,
61+
infrastructure is built to be shared. However, shared infrastructure raises a
62+
common challenge - how to provide flexibility to users of the infrastructure
63+
while maintaining control by owners of the infrastructure?
64+
65+
The Gateway API accomplishes this through a role-oriented design for
66+
Kubernetes service networking that strikes a balance between distributed
67+
flexibility and centralized control. It allows shared network infrastructure
68+
(hardware load balancers, cloud networking, cluster-hosted proxies etc) to be
69+
used by many different and non-coordinating teams, all bound by the policies
70+
and constraints set by cluster operators. The following example shows how this
71+
works in practice.
72+
73+
A cluster operator creates a [Gateway](/api-types/gateway) resource derived from a
74+
[GatewayClass](/api-types/gatewayclass). This Gateway deploys or configures the
75+
underlying network resources that it represents. Through the
76+
[Route Attachment Process](/concepts/api-overview#attaching-routes-to-gateways)
77+
between the Gateway and Routes, the cluster operator and specific teams must
78+
agree on what can attach to this Gateway and expose their applications through
79+
it. Centralized policies [such as TLS](/guides/tls#downstream-tls) can
80+
be enforced on the Gateway by the cluster operator. Meanwhile, the store and site
81+
teams run [in their own Namespaces](/guides/multiple-ns), but attach their
82+
Routes to the same shared Gateway, allowing them to independently control
83+
their [routing logic](/guides/http-routing). This separation of concerns
84+
allows the store team to manage their own
85+
[traffic splitting rollout](/guides/traffic-splitting) while
86+
leaving centralized policies and control to the cluster operators.
87+
88+
![Gateway API Roles](./images/gateway-roles.png)
89+
90+
This flexibility allows the API to adapt to vastly different
91+
organizational models and implementations while remaining a portable and
92+
standard API.
93+
94+
95+
## Who is working on Gateway?
96+
97+
The Gateway API is a
98+
[SIG-Network](https://github.com/kubernetes/community/tree/master/sig-network)
99+
project being built to improve and standardize service networking in
100+
Kubernetes. Current and in-progress implementations include Contour,
101+
Emissary-Ingress (Ambassador API Gateway), Google Kubernetes Engine (GKE), Istio,
102+
Kong, and Traefik. Check out the [implementations
103+
reference](implementations.md) to see the latest projects &
104+
products that support Gateway. If you are interested in contributing to or
105+
building an implementation using the Gateway API then don’t hesitate to [get
106+
involved!](/contributing/community)
107+
108+
[sig-network]: https://github.com/kubernetes/community/tree/master/sig-network
109+

0 commit comments

Comments
 (0)