mirror of
https://github.com/funkypenguin/geek-cookbook/
synced 2025-12-13 01:36:23 +00:00
Update title suffix
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
@@ -22,23 +22,23 @@ Install the FRR package in pfsense, under **System -> Package Manager -> Availab
|
||||
|
||||
Under **Services -> FRR Global/Zebra**, enable FRR, set your router ID (*this will be your router's peer IP in MetalLB config*), and set a master password (*because apparently you have to, even though we don't use it*):
|
||||
|
||||

|
||||

|
||||
|
||||
### Configure FRR BGP
|
||||
|
||||
Under **Services -> FRR BGP**, globally enable BGP, and set your local AS and router ID:
|
||||
|
||||

|
||||

|
||||
|
||||
### Configure FRR BGP Advanced
|
||||
|
||||
Use the tabs at the top of the FRR configuration to navigate to "**Advanced**"...
|
||||
|
||||

|
||||

|
||||
|
||||
... and scroll down to **eBGP**. Check the checkbox titled "**Disable eBGP Require Policy**:
|
||||
|
||||

|
||||

|
||||
|
||||
!!! question "Isn't disabling a policy check a Bad Idea(tm)?"
|
||||
If you're an ISP, sure. If you're only using eBGP to share routes between MetalLB and pfsense, then applying policy is an unnecessary complication.[^1]
|
||||
@@ -58,13 +58,13 @@ It's useful to bundle our configurations within a "peer group" (*a collection of
|
||||
|
||||
Now add each node running MetalLB, as a BGP neighbor. Pick the peer-group you created above, and configure each neighbor's ASN:
|
||||
|
||||

|
||||

|
||||
|
||||
## Serving
|
||||
|
||||
Once you've added your neighbors, you should be able to use the FRR tab navigation (*it's weird, I know!*) to get to Status / BGP, and identify your neighbors, and all the routes learned from them. In the screenshot below, you'll note that **most** routes are learned from all the neighbors - that'll be service backed by a daemonset, running on all nodes. The `192.168.32.3/32` route, however, is only received from `192.168.33.22`, meaning only one node is running the pods backing this service, so only those pods are advertising the route to pfSense:
|
||||
|
||||

|
||||

|
||||
|
||||
### Troubleshooting
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ They're still not very secret though, and you certainly wouldn't want to be stor
|
||||
|
||||
An elegant solution to this problem is Bitnami Labs' Sealed Secrets.
|
||||
|
||||

|
||||

|
||||
|
||||
A "[SealedSecret](https://github.com/bitnami-labs/sealed-secrets)" can only be decrypted (*and turned back into a regular Secret*) by the controller in the target cluster. (*or by a controller in another cluster which has been primed with your own private/public pair)* This means the SealedSecret is safe to store and expose anywhere.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ To interact with your cluster externally, you'll almost certainly be using a web
|
||||
|
||||
Cert Manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.
|
||||
|
||||

|
||||

|
||||
|
||||
It can issue certificates from a variety of supported sources, including Let’s Encrypt, HashiCorp Vault, and Venafi as well as private PKI.
|
||||
|
||||
|
||||
@@ -25,3 +25,14 @@
|
||||
<script src="/js/i-am-groot.js"></script>
|
||||
<script>window.plausible = window.plausible || function() { (window.plausible.q = window.plausible.q || []).push(arguments) }</script>
|
||||
{% endblock %}
|
||||
|
||||
<!-- Add little penguin ascii-art to titles instead of 20-character-long site name -->
|
||||
{% block htmltitle %}
|
||||
{% if page.meta and page.meta.title %}
|
||||
<title>{{ page.meta.title }} |・∀・</title>
|
||||
{% elif page.title and not page.is_homepage %}
|
||||
<title>{{ page.title | striptags }} |・∀・</title>
|
||||
{% else %}
|
||||
<title>{{ config.site_name }}</title>
|
||||
{% endif %}
|
||||
{% endblock %}
|
||||
Reference in New Issue
Block a user