You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While what we have also works, labels is a nicer
way to select k8s objects.
```shell
nginx-loadbalancer-kubernetes $ kubectl -n nlk logs -f $(kubectl -n nlk get po -l "app=nlk" --no-headers -o custom-columns=":metadata.name")
time="2024-02-28T20:35:49Z" level=info msg="Settings::Initialize"
time="2024-02-28T20:35:49Z" level=info msg="Certificates::Initialize"
time="2024-02-28T20:35:49Z" level=info msg="Certificates::Run"
I0228 20:35:49.398213 1 shared_informer.go:273] Waiting for caches to sync for nlk-handler
I0228 20:35:49.500005 1 shared_informer.go:280] Caches are synced for nlk-handler
```
@@ -44,7 +44,7 @@ NLK provides a simple, easy-to-manage way to automate load balancing for your Ku
44
44
45
45
NLK installs easily, has a small footprint, and is easy to configure and manage.
46
46
47
-
NLK does not require learning a custom object model, you only have to understand NGINX configuration to get the most out of this solution.
47
+
NLK does not require learning a custom object model, you only have to understand NGINX configuration to get the most out of this solution.
48
48
There is thorough documentation available with the specifics in the `docs/` directory.
49
49
50
50
### What does NLK do?
@@ -53,15 +53,15 @@ tl;dr:
53
53
54
54
_**NLK is a Kubernetes controller that monitors Services and Nodes in your cluster, and then sends API calls to an external NGINX Plus server to manage NGINX Plus Upstream servers automatically.**_
55
55
56
-
That's all well and good, but what does it mean? Kubernetes clusters require some tooling to handling routing traffic from the outside world (e.g.: the Internet, corporate network, etc.) to the cluster.
56
+
That's all well and good, but what does it mean? Kubernetes clusters require some tooling to handling routing traffic from the outside world (e.g.: the Internet, corporate network, etc.) to the cluster.
57
57
This is typically done with a load balancer. The load balancer is responsible for routing traffic to the appropriate worker node which then forwards the traffic to the appropriate Service / Pod.
58
58
59
-
If you are using a hosted Kubernetes solution -- Digital Ocean, AWS, Azure, etc. -- you can use the cloud provider's load balancer service. Those services will create a load balancer for you.
59
+
If you are using a hosted Kubernetes solution -- Digital Ocean, AWS, Azure, etc. -- you can use the cloud provider's load balancer service. Those services will create a load balancer for you.
60
60
You can use the cloud provider's API to manage the load balancer, or you can use the cloud provider's web console.
61
61
62
62
If you are running Kubernetes on-premise and will need to manage your own load balancer, NLK can help.
63
63
64
-
NLK itself does not perform load balancing. Rather, NLK allows you to manage Service resources within your cluster to update your load balancers, with tooling you are most likely already using.
64
+
NLK itself does not perform load balancing. Rather, NLK allows you to manage Service resources within your cluster to update your load balancers, with tooling you are most likely already using.
@@ -70,7 +70,7 @@ NLK itself does not perform load balancing. Rather, NLK allows you to manage Ser
70
70
There are few bits of administrivia to get out of the way before you can start leveraging NLK for your load balancing needs.
71
71
72
72
As noted above, NLK is intended for when you have one or more Kubernetes clusters running on-premise. In addition to this,
73
-
you need to have at least one NGINX Plus host running outside your cluster (Please refer to the [Roadmap](#Roadmap) for information about other load balancer servers).
73
+
you need to have at least one NGINX Plus host running outside your cluster (Please refer to the [Roadmap](#Roadmap) for information about other load balancer servers).
74
74
75
75
### Deployment
76
76
@@ -92,20 +92,20 @@ You will need to update this ConfigMap to reflect the NGINX Plus hosts you wish
92
92
93
93
If you were to deploy the ConfigMap and start NLK without updating the `nginx-hosts` value, don't fear; the ConfigMap resource is monitored for changes and NLK will update the NGINX Plus hosts accordingly when the resource is changed, no restart required.
94
94
95
-
There is an extensive [Installation Reference](docs/README.md) available in the `docs/` directory.
95
+
There is an extensive [Installation Reference](docs/README.md) available in the `docs/` directory.
96
96
Please refer to that for detailed instructions on how to deploy NLK and run a demo application.
97
97
98
98
#### Versioning
99
99
100
-
Versioning is a work in progress. The CI/CD pipeline is being developed and will be used to build and publish NLK images to the Container Registry.
100
+
Versioning is a work in progress. The CI/CD pipeline is being developed and will be used to build and publish NLK images to the Container Registry.
101
101
Once in place, semantic versioning will be used for published images.
102
102
103
103
#### Deployment Steps
104
104
105
-
To get NLK up and running in ten steps or fewer, follow these instructions (NOTE, all the aforementioned prerequisites must be met for this to work).
105
+
To get NLK up and running in ten steps or fewer, follow these instructions (NOTE, all the aforementioned prerequisites must be met for this to work).
106
106
There is a much more detailed [Installation Reference](docs/README.md) available in the `docs/` directory.
107
107
108
-
1. Clone this repo (optional, you can simply copy the `deployments/` directory)
108
+
1. Clone this repo (optional, you can simply copy the `deployments/` directory)
```kubectl -n nlk logs -f $(kubectl -n nlk get po -l "app=nlk" --no-headers -o custom-columns=":metadata.name")```
131
131
132
-
At this point NLK should be up and running. Now would be a great time to go over to the [Installation Reference](docs/README.md)
132
+
At this point NLK should be up and running. Now would be a great time to go over to the [Installation Reference](docs/README.md)
133
133
and follow the instructions to deploy a demo application.
134
134
135
135
### Monitoring
136
136
137
-
Presently NLK includes a fair amount of logging. This is intended to be used for debugging purposes.
137
+
Presently NLK includes a fair amount of logging. This is intended to be used for debugging purposes.
138
138
There are plans to add more robust monitoring and alerting in the future.
139
139
140
140
As a rule, we support the use of [OpenTelemetry](https://opentelemetry.io/) for observability, and we will be adding support in the near future.
141
141
142
142
## Contributing
143
143
144
-
Presently we are not accepting pull requests. However, we welcome your feedback and suggestions.
144
+
Presently we are not accepting pull requests. However, we welcome your feedback and suggestions.
145
145
Please open an issue to let us know what you think!
146
146
147
147
One way to contribute is to help us test NLK. We are looking for people to test NLK in a variety of environments.
148
148
149
-
If you are curious about the implementation, you should certainly browse the code, but first you might wish to refer to the [design document](docs/DESIGN.md).
149
+
If you are curious about the implementation, you should certainly browse the code, but first you might wish to refer to the [design document](docs/DESIGN.md).
150
150
Some of the design decisions are explained there.
151
151
152
152
## Roadmap
153
153
154
154
While NLK was initially written specifically for NGINX Plus, we recognize there are other load-balancers that can be supported.
155
155
156
-
To this end, NLK has been architected to be extensible to support other "Border Servers".
157
-
Border Servers are the term NLK uses to describe load-balancers, reverse proxies, etc. that run outside the cluster and handle
158
-
routing outside traffic to your cluster.
156
+
To this end, NLK has been architected to be extensible to support other "Border Servers".
157
+
Border Servers are the term NLK uses to describe load-balancers, reverse proxies, etc. that run outside the cluster and handle
158
+
routing outside traffic to your cluster.
159
159
160
160
While we have identified a few potential targets, we are open to suggestions. Please open an issue to share your thoughts on potential implementations.
0 commit comments