blog/docs/articles/from-cloudevent-to-apache-kafka-records-part-two.md|24| The above-mentioned article configures all Knative Brokers to be in shape of the Kafka class, therefore creating a new broker for Apache Kafka is pretty straightforward:
blog/docs/articles/from-cloudevent-to-apache-kafka-records-part-two.md|41| my-demo-kafka-broker http://kafka-broker-ingress.knative-eventing.svc.cluster.local/default/my-demo-kafka-broker 7s True
blog/docs/articles/from-cloudevent-to-apache-kafka-records-part-two.md|50| kubectl get brokers.eventing.knative.dev my-demo-kafka-broker -o yaml
blog/docs/articles/from-cloudevent-to-apache-kafka-records-part-two.md|77| By default the Knative Kafka Broker creates its own internal topic, however this action might be restricted in some environments. For this and any other similar use cases, it is possible to bring your own topic.
blog/docs/articles/getting-started-blog-p0.md|28| learning all about how Knative works and making our first contributions to the project. We understand many of the pain points that new contributors face because
blog/docs/articles/getting-started-blog-p0.md|29| we just faced them ourselves. Our hope is that by creating this blog series we can alleviate some of these pain points for the contibutors who come after
blog/docs/articles/getting-started-blog-p0.md|35| As a new contributor it can be very difficult to know how to navigate the codebase to find where to make your change. There is also a lot of "magic" in the
blog/docs/articles/getting-started-blog-p0.md|36| Knative codebase, where you have to name functions in certain ways and/or there is code generation. This makes it really hard to understand where you should
blog/docs/articles/getting-started-blog-p0.md|46| At this point, you're probably wondering (at least we hope you are) how you can get the most out of these blogs? Well, it's actually pretty simple! All you
blog/docs/articles/getting-started-blog-p1.md|12| environment for working on Knative. But if you're new to open source, interested in learning more, or want a refresher, then we look forward to discussing the what, why, and
blog/docs/articles/getting-started-blog-p1.md|17| So, what is open source? The key concept behind open source is that all of the source code is publicly available: anyone can read it, change it, improve on it, and distribute it
blog/docs/articles/getting-started-blog-p1.md|24| There is a lot of popular open source software which you have probably used before, regardless of if you knew it was open source. For example, chances are most of your browser is
blog/docs/articles/getting-started-blog-p1.md|45| A very common scenario is that you are the user of some software and would like to add a feature or fix a bug which is bothering you. Thus, you might contribute code to the project by
blog/docs/articles/getting-started-blog-p1.md|65| will have different guidelines__ on how to contribute and on what, if any, types of contributions they are accepting. Be sure to check with the community first before starting to
blog/docs/articles/getting-started-blog-p1.md|96| For example, in Knative there are weekly and bi-weekly meetings of the working groups{:target="_blank"}, where
blog/docs/articles/getting-started-blog-p1.md|103| A more technically-oriented contribution is reviewing pull requests (PRs){:target="_blank"}.
blog/docs/articles/getting-started-blog-p1.md|121| approved by the reviewer, your work will be done and your code will be merged! (Merging means combing your changes with the main code for the codebase, so that everyone is able to
blog/docs/articles/getting-started-blog-p1.md|136| by adding the triage/accepted label. Additionally, for large features we require a feature proposal document to be created alongside the issue. However, for very small features like
blog/docs/articles/getting-started-blog-p1.md|137| fixing the developer documentation, you can also skip this step and just make your change by creating a PR.
blog/docs/articles/getting-started-blog-p1.md|139| Before you propose a new feature or report a bug, try searching whatever platform the community uses to keep track of issues for a duplicate. If one already exists and has been
blog/docs/articles/getting-started-blog-p1.md|140| approved, great! You can move on and get started on the next step of the process. If it exists and hasn't been approved yet, you can always comment on the issue to indicate
blog/docs/articles/getting-started-blog-p1.md|170| changes you want. This is different from the main project repository, where you likely don't have permissions to change the code. To create a fork on GitHub, you can follow
blog/docs/articles/getting-started-blog-p1.md|174| which can be installed from here{:target="_blank"}. Alternatively, you can use the git clone{:target="_blank"} and
blog/docs/articles/getting-started-blog-p1.md|176| and that this remote is commonly named "upstream". This remote will be used to keep your fork in sync with any changes to the upstream project. To clone it manually yourself,
blog/docs/articles/getting-started-blog-p1.md|178| cd into the newly cloned repository, and run git remote add upstream <url_of_upstream_repo> && git remote set-url --push upstream no_push. To get the url of your fork and
blog/docs/articles/getting-started-blog-p1.md|182| Once you have a fork, have cloned it locally, and have set up your remotes properly you should checkout a new branch to make your changes on. If you are unsure what a branch is and
blog/docs/articles/getting-started-blog-p1.md|185| share the same history on the main branch. To sync changes your fork's main branch with the upstream main branch, you can use the
blog/docs/articles/getting-started-blog-p1.md|187| and pull those changes to your local main branch, or you can run git checkout main && git pull upstream main (assuming you haven't made any commits to your main branch), and
blog/docs/articles/getting-started-blog-p1.md|216| There are two scenarios where you would likely want to open a PR/MR. The first is that you feel your changes are complete and
blog/docs/articles/getting-started-blog-p1.md|222| When creating your PR/MR it is important to provide the context of why you are making the changes, what you changes, and how people can test your changes. It is good practice to
blog/docs/articles/getting-started-blog-p1.md|226| If your changes are incomplete, you will want to mark the PR/MR as a draft, to indicate to reviewers that your work is not complete. Instructions for GitHub are
blog/docs/articles/getting-started-blog-p1.md|227| here{:target="_blank"},
blog/docs/articles/getting-started-blog-p1.md|229| want to title your PR/MR as "[WIP]: <descriptive title>" (with WIP for "work in progress"). If you have any questions about your changes, this draft PR/MR is a great place
blog/docs/articles/getting-started-blog-p1.md|246| While it may be frustrating when reviewers suggest changes to what you perceive as functioning code, remember their goal is to enhance the overall quality of the project.
blog/docs/articles/getting-started-blog-p1.md|248| opportunity. If there's a reason preventing you from implementing a requested change, don't hesitate to respond to their comment explaining why you believe the
blog/docs/articles/getting-started-blog-p1.md|249| suggestion may not be feasible. However, unless such circumstances exist, make an effort to incorporate all their proposed changes. This approach will foster a productive
blog/docs/articles/getting-started-blog-p1.md|261| As you've hopefully seen in this article, there are many great open source projects out there to contribute to. So, if you're interested, pick one and contribute! There are
blog/docs/articles/getting-started-blog-p1.md|262| loads of ways to contribute, and your contributions will be appreciated so long as the project is taking contributions. While contributing (especially contributing code) can be
blog/docs/articles/getting-started-blog-p1.md|263| a complex process, it is also a very rewarding experience. So, we hope to see you out there contributing to open source and Knative!
blog/docs/articles/improved-ha-configuration.md|29| kubectl get deployments.apps -n knative-eventing
blog/docs/articles/improved-ha-configuration.md|40| For each workload we do see exactly three deployements. Now, take a detailed look at the above shell snippet. You will notice that for the InMemoryChannel we do have 6 deployments: 3 for each, the controller and the dispatcher data-plane. This is not always what you want, since the InMemoryChannel is more often used as a tool during development, while in production scenarios other worksloads, like the Knative Broker or Knative Channel implementations for Apache Kafka are being used.
blog/docs/articles/improved-ha-configuration.md|59| replicas: 1
blog/docs/articles/improved-ha-configuration.md|61| replicas: 1
blog/docs/articles/knative-serving-in-k0s.md|13| * Resource Requirement Analysis
blog/docs/articles/knative-serving-in-k0s.md|20| * Knative in k0s
blog/docs/articles/knative-serving-in-k0s.md|106| MiB Swap: 1942.0 total, 1734.9 free, 207.1 used. 280.4 avail Mem
blog/docs/articles/knative-serving-in-k0s.md|108| PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
blog/docs/articles/knative-serving-in-k0s.md|109| 1222 kube-ap+ 20 0 1203728 261064 30408 S 1.7 26.2 4:12.43 kube-apiserver
blog/docs/articles/knative-serving-in-k0s.md|110| 1213 kube-ap+ 20 0 740108 29256 6032 S 1.0 2.9 2:13.01 kine
blog/docs/articles/knative-serving-in-k0s.md|111| 1376 kube-ap+ 20 0 776892 54388 20112 S 1.0 5.5 1:52.61 kube-controller
blog/docs/articles/knative-serving-in-k0s.md|112| 602 root 20 0 806420 44088 20408 S 0.7 4.4 0:53.60 k0s
blog/docs/articles/knative-serving-in-k0s.md|113| 1283 root 20 0 779664 48132 19672 S 0.7 4.8 2:24.79 kubelet
blog/docs/articles/knative-serving-in-k0s.md|114| 5 root 20 0 0 0 0 I 0.3 0.0 0:00.29 kworker/0:0-events
blog/docs/articles/knative-serving-in-k0s.md|115| 347 root 19 -1 56140 14772 14244 S 0.3 1.5 0:04.18 systemd-journal
blog/docs/articles/knative-serving-in-k0s.md|116| 1282 root 20 0 757300 24652 7024 S 0.3 2.5 0:44.78 containerd
blog/docs/articles/knative-serving-in-k0s.md|117| 1372 kube-sc+ 20 0 765012 24264 13596 S 0.3 2.4 0:16.83 kube-scheduler
blog/docs/articles/knative-serving-in-k0s.md|125| Memory
blog/docs/articles/knative-serving-in-k0s.md|140| MiB Swap: 1942.0 total, 1942.0 free, 0.0 used. 670.7 avail Mem
blog/docs/articles/knative-serving-in-k0s.md|142| PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
blog/docs/articles/knative-serving-in-k0s.md|143| 606 root 20 0 727828 49984 20012 S 1.3 5.0 0:02.68 snapd
blog/docs/articles/knative-serving-in-k0s.md|151| Minimum resources needed for VM by the rough estimate
blog/docs/articles/knative-serving-in-k0s.md|187| vagrant@vagrant:$ sudo k0s kubectl get ksvc
blog/docs/articles/knative-serving-in-k0s.md|189| hello http://hello.default.svc.cluster.local hello-00001 hello-00001 True
blog/docs/articles/knative-serving-in-k0s.md|191| vagrant@vagrant:$ sudo k0s kubectl get pods
blog/docs/articles/knative-serving-in-k0s.md|200| NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
blog/docs/articles/knative-serving-in-k0s.md|201| vagrant 166m 8% 1341Mi 71%
blog/docs/articles/knative-serving-in-k0s.md|206| NAMESPACE NAME CPU(cores) MEMORY(bytes)
blog/docs/articles/knative-serving-in-k0s.md|207| default hello-00001-deployment-66ddff5b59-jbn6x 1m 8Mi
blog/docs/articles/knative-serving-in-k0s.md|208| knative-serving activator-6f78547bf7-xp5jh 2m 21Mi
blog/docs/articles/knative-serving-in-k0s.md|209| knative-serving autoscaler-86796dfc97-2q6b2 5m 19Mi
blog/docs/articles/knative-serving-in-k0s.md|210| knative-serving controller-7cd4659488-sqz5q 5m 27Mi
blog/docs/articles/knative-serving-in-k0s.md|211| knative-serving default-domain-6mknr 1m 7Mi
blog/docs/articles/knative-serving-in-k0s.md|212| knative-serving domain-mapping-856cc965f5-jv4g9 2m 13Mi
blog/docs/articles/knative-serving-in-k0s.md|213| knative-serving domainmapping-webhook-6dc8d86dbf-mg8j8 7m 15Mi
blog/docs/articles/knative-serving-in-k0s.md|214| knative-serving net-kourier-controller-54999fc897-st6tn 6m 37Mi
blog/docs/articles/knative-serving-in-k0s.md|215| knative-serving webhook-d9c8c747d-fwhst 9m 16Mi
blog/docs/articles/knative-serving-in-k0s.md|216| kourier-system 3scale-kourier-gateway-9b477c667-2hdt2 4m 17Mi
blog/docs/articles/knative-serving-in-k0s.md|217| kube-system coredns-7bf57bcbd8-b22j4 3m 16Mi
blog/docs/articles/knative-serving-in-k0s.md|218| kube-system kube-proxy-pm4ht 1m 13Mi
blog/docs/articles/knative-serving-in-k0s.md|219| kube-system kube-router-vdqtv 1m 19Mi
blog/docs/articles/knative-serving-in-k0s.md|220| kube-system metrics-server-7446cc488c-zxdxg 5m 18Mi
blog/docs/articles/knative-serving-in-k0s.md|227| Minimum resources used for VM by the rough estimate
blog/docs/articles/knative-serving-in-k0s.md|238| ## Knative in k0s
blog/docs/articles/knative-serving-in-k0s.md|242| To do this we will use vagrant VM with 1 CPU and 1.5 GB Memory.
blog/docs/articles/knative-serving-in-k0s.md|287| We can already see the effect of running k0s in 1 CPU and 1.5 GB RAM .
blog/docs/articles/knative-serving-in-k0s.md|293| NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
blog/docs/articles/knative-serving-in-k0s.md|294| vagrant 39m 3% 959Mi 71%
blog/docs/articles/knative-serving-in-k0s.md|307| Defining The IPs To Assign To The Load Balancer Services.
blog/docs/articles/knative-serving-in-k0s.md|320| Announce The Service IPs (Layer 2 Configuration)
blog/docs/articles/knative-serving-in-k0s.md|342| Edit deployment files of all knative serving components by reducing resources to 50% of the original value.
blog/docs/articles/knative-serving-in-k0s.md|364| # networking
blog/docs/articles/knative-serving-in-k0s.md|420| hello http://hello.default.192.168.10.0.sslip.io hello-00001 hello-00001 True
blog/docs/articles/new_event_discovery_features.md|45| #### Duck Sources
blog/docs/articles/new_event_discovery_features.md|67| k get eventtypes.eventing.knative.dev -A
blog/docs/articles/new_event_discovery_features.md|69| default 93774a924a741245a94313745d78e69f dev.knative.sources.ping /apis/v1/namespaces/default/pingsources/ping-source-broker2 log-receiver Service True
blog/docs/articles/new_event_discovery_features.md|79| This blog post introduced new features and improvements to EventType discoroverability. The main motivation is to harden the position of developer's insight into the event-driven applications to ease up the discovery and speed up development.
blog/docs/events/fuzzing-audit-2023.md|26| An important component of a robust fuzzing suite is making sure that the fuzzers run continuously. All Knatives fuzzers run continuously on OSS-Fuzz - Googles open source platform for running the fuzzers of critical open source projects continuously with excessive resources. Knatives fuzzing audit started by integrating Knative into OSS-Fuzz, and the auditors then added the fuzzers to that integration. This allowed the fuzzers to run continuously during the audit and will continue to do so after the audit has concluded.
blog/docs/events/fuzzing-audit-2023.md|31| - Scheduler plugings: All of Knative eventings the scheduler plugins are covered.
blog/docs/events/fuzzing-audit-2023.md|43| Knative is open source and accepts community contributions. The community repository is the best place to start if you wish to contribute to the ecosystem.
blog/docs/releases/announcing-knative-v1-11-release.md|85| - This a breaking change of backward compatibility with Eventing release that doesn't suppoert EventTypes API @ v1beta2
blog/docs/releases/announcing-knative-v1-11-release.md|117| - Updated Rust http example. (#1798, @saschagrunert)
code-samples/serving/hello-world/helloworld-java-spark/service.yaml|11| env:
code-samples/serving/hello-world/helloworld-java-spark/service.yaml|12| - name: TARGET
code-samples/serving/multi-container/README.md|39| package main
code-samples/serving/multi-container/README.md|143| RUN apk add --no-cache ca-certificates
code-samples/serving/multi-container/README.md|145| COPY --from=builder /app/sidecarcontainer /sidecarcontainer
contribute-to-docs/style-guide/word-and-phrase-list.md|37| | time-based | time based |
docs/eventing/brokers/broker-types/channel-based-broker/README.md|4| Users should prefer native Broker implementations (like Knative Broker for Apache Kafka or RabbitMQ Broker) over the MTChannelBasedBroker and Channel combination because it is usually more efficient as they reduce network hops for example.
docs/eventing/brokers/broker-types/channel-based-broker/README.md|13|
docs/eventing/brokers/broker-types/channel-based-broker/README.md|46|
docs/eventing/brokers/create-broker.md|17|
docs/eventing/brokers/create-broker.md|19|
docs/eventing/brokers/create-broker.md|22|
docs/eventing/brokers/create-broker.md|25|
docs/eventing/brokers/create-broker.md|55|
docs/eventing/brokers/create-broker.md|70|
docs/eventing/brokers/create-broker.md|72|
docs/eventing/brokers/create-broker.md|77|
docs/eventing/brokers/create-broker.md|82| When a Broker is created without a specified eventing.knative.dev/broker.class annotation, the default MTChannelBasedBroker Broker class is used, as specified by default in the config-br-defaults ConfigMap.
docs/eventing/experimental-features/eventtype-auto-creation.md|29| With this experiemental feature enabled, we get EventTypes on the broker/channel ingress for free, instead of manually creating them as yaml manifests along the application code that talks to the Broker or Channel API.
docs/eventing/experimental-features/eventtype-auto-creation.md|39|
docs/eventing/experimental-features/eventtype-auto-creation.md|55|
docs/eventing/experimental-features/eventtype-auto-creation.md|108| k get eventtypes.eventing.knative.dev -A
docs/eventing/experimental-features/eventtype-auto-creation.md|110| default <...> com.corp.integration.warning kn-event/v1.9.0 my-broker True
docs/eventing/experimental-features/eventtype-auto-creation.md|111| default <...> my.demo.event my/curl/command my-broker True
docs/eventing/experimental-features/transport-encryption.md|289| >
docs/eventing/experimental-features/transport-encryption.md|290| < HTTP/2 202
docs/eventing/experimental-features/transport-encryption.md|294| <
docs/eventing/sources/kafka-source/README.md|174| ### Scaling
docs/eventing/sources/kafka-source/README.md|195| - my-cluster-kafka-bootstrap.kafka:9092
docs/install/scripts/istio-openshift-policies.sh|1| #!/bin/bash
docs/install/scripts/istio-openshift-policies.sh|3| set -e
docs/install/scripts/knative-openshift-policies.sh|1| #!/bin/bash
docs/install/scripts/knative-openshift-policies.sh|3| set -e
docs/serving/architecture.md|4| This page explains the high-level architecture of Knative Serving. Please also refer to the Knative Serving Overview
docs/serving/architecture.md|24| Ingress in this case, does not refer to the Kubernetes Ingress Resource. It refers to the concept of exposing external access to a resource on the cluster.
docs/serving/architecture.md|25|
docs/serving/architecture.md|26| Knative Serving depends on a Networking Layer that fulfils the Knative Networking Specification.
docs/serving/autoscaling/autoscaling-metrics.md|35| autoscaling.knative.dev/target-utilization-percentage: "70"
docs/serving/autoscaling/scale-bounds.md|224| delay period.
docs/serving/autoscaling/scale-bounds.md|225| !!! note
docs/serving/request-flow.md|63|
docs/serving/using-auto-tls.md|297| autoscale-go https://autoscale-go.default.{custom-domain} autoscale-go-6jf85 autoscale-go-6jf85 True
docs/snippets/security-prereqs-binaries.md|35|